From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugo Tyson To: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] DHCP shuts down Ethernet device? Date: Mon, 23 Apr 2001 11:30:00 -0000 Message-id: References: <20010423123926.A2035@visi.com> X-SW-Source: 2001-04/msg00329.html Grant Edwards 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