Re: [ECOS] Second ethernet port?

[Hugo Tyson <hmt at redhat dot com>]

> From: Colin Ford <colin.ford@pipinghotnetworks.com>

> I've included my output below. The odd thing is,
> is that I can ping from my Linux box both:
> 
> 1.1.2.239 & 1.1.2.187

Yep, looks like both interfaces are up and working OK.  That eth1 was left
up following the error is probably a "feature" - or it might be talking
through eth0.  Not important.
 
> after eCos has run and aquired thoes addresses.
> Everthing seems to work apart from eCos thinking 
> that eth1 failed when it did not?
>
> I think the "SIOCIFADDR 2" origanates from:
> packages/net/tcpip/current/src/lib/bootp_support.c
> 
> // Must do this again so that [sub]netmask (and so default route)
> // is taken notice of.
> addrp->sin_addr = bp->bp_yiaddr;  // The address BOOTP gave us
> if (ioctl(s, SIOCSIFADDR, &ifr)) {
>      perror("SIOCIFADDR 2");
>      return false;
> }

Right, that's setting the address with the correct netmask.  But the system
already has a route to that very address with the same netmask set up via
the default routing for eth0.

> I'm not sure what your saying about the network segment?

...snipped to keep the important details...

> BOOTP[eth0] op: REPLY
>      client IP: 0.0.0.0
>          my IP: 1.1.2.239
>      server IP: 1.1.1.1
>     gateway IP: 0.0.0.0
>        subnet mask: 255.255.0.0
> BOOTP[eth1] op: REPLY
>      client IP: 0.0.0.0
>          my IP: 1.1.2.187
>      server IP: 1.1.1.1
>     gateway IP: 0.0.0.0
>        subnet mask: 255.255.0.0
> SIOCIFADDR 2: File exists
> Network initialization failed for eth1
> Starting Interfaces
> Running Ping Test on eth0

You have connected your board up thus, with both interfaces on the same
network segment == the same logical IP address space, with netmasks of
255.255.0.0:

        1.1.2.239 eth0 ---------+-------network 1.1.x.x
  BOARD                         |
        1.1.2.187 eth1 ---------+

So the code sets up a route to all nodes called 1.1.x.x via eth0.  This is
the correct thing to do.  It then tries to set up an implicit route to
1.1.2.187 via eth1 as well.  This is also (usually) the correct thing to
do.  But this causes an error because the system already knows a route for
1.1.x.x, which includes 1.1.2.187, via eth0.  Bringing up 1.1.2.187 locally
would conflict with that so it is rejected.

OK, I probably have the details wrong of what's happening internally to the
stack, but I hope you understand the issue... the system expects 1.1.2.187
to be outside on the net because of the way eth0 was already set up, not
right here in the same box.

The initialization code that we provide assumes that different interfaces
will be on different network segments, for example:

        1.1.2.239 eth0 ----------------network 1.1.2.x
  BOARD                         
        1.2.2.187 eth1 ----------------network 1.2.2.x

That way, the route to 1.1.2.x via eth0 does not conflict with a new route
to 1.2.2.x via eth1.

The reason we assume this is that connecting both interfaces to the same
network is kinda pointless, it doesn't let you do anything that you can't
do with a single interface.  (Except testing your code, but it's a poor
test, it could be going wrong in lots of ways that you wouldn't know)

The linux box on my desk, which I use to test many targets with multiple
interfaces, itself has two interfaces, one onto our house network
(191.17.17.x), and one onto a private net all of my own (10.17.17.x)

The target board has one interface connected to the house network, and one
to my private net.  I run my own DHCP server to serve the private net, of
course.  So my two interfaces have IP addresses like 191.17.17.99 and
10.17.17.99 (deliberately picking the same last part as an aide memoire,
nothing more).

To use multiple interfaces meaningfully, you need multiple networks.

(Or set up the netmasks and routes &c yourself, with care...)

	- Huge