Re: [ECOS] DHCP shuts down Ethernet device?

[Hugo Tyson <hmt@redhat.com>]

Grant Edwards <grante@visi.com> writes:
> I just discovered that when the DHCP task fails to find a
> server, it then shuts down the Ethernet driver using the code:
> 
>     // Shut down interface so it can be reinitialized
>     ifr.ifr_flags &= ~(IFF_UP | IFF_RUNNING);
>     if (ioctl(s, SIOCSIFFLAGS, &ifr)) { /* set ifnet flags */
>         perror("SIOCSIFFLAGS down");   
>         return false;
>         }
> 
> This generates a call to the _stop() method in the Ethernet
> driver.
> 
> I realise that if DHCP fails, the IP stack needs to be shut
> down, but stopping the ethernet device entirely keeps non-IP
> stuff from working.  Does the DHCP code assume that there are
> no non-IP network protocols, or is the above supposed to shut
> down only IP networking on the device?  The other drivers I've
> looked at all seem to shut off the interface completely.

It shuts down everything, deliberately.
 
> I think I'm going to have to either comment out the above call,
> or make my Ethernet driver's _stop() method into a noop...

Either of those would do.

Here's a cleaner suggestion: the DHCP system is separated into two parts.
The protocol and the thread that runs it.  The protocol is in dhcp_prot.c;
the thread in dhcp_support.c.  You can configure out the automatic start of
that management thread and use your own.  It can trivially detect an
interface going down, and bring it back up again in whatever fashion you
like, if you want it to remain up despite having no IP address.

BTW, a little background: the interface(s) are torn right down in order to
make it possible to direct the initial broadcast to a particular interface.
Using normal sockets for the broadcast *before you have an IP address at
all* only works if you ensure there is only one interface up at one time
and a naive route installed.  A re-write using raw sockets would solve
this, AIUI, but we have not had the resource available to do this.
Contributions welcome!  [We all knew that was coming, right? ;-) ]

OTOH you could add a config opt to control how vigorously we close down the
interface - thats probably a much shorter task, and all would still be well
if you only have one interface present.  Contributions welcome again.


Like much of the stuff in the lib part of the network source tree, it is
intended that implementors are free to mess with it - requirements about
booting networks being as diverse as they are.

HTH,
	- Huge