[ECOS] DHCP shuts down Ethernet device?

[ECOS] DHCP shuts down Ethernet device?

[Grant Edwards]

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.

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...

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] DHCP shuts down Ethernet device?

[Hugo Tyson]

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

Re: [ECOS] DHCP shuts down Ethernet device?

[Jonathan Larmour]

Hugo Tyson wrote:
> 
> 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.

I'm wondering: isn't the problem just that configuring the interface down
calls the _stop() method? Why not just not do that? The common eth driver
already just has eth_drv_recv() return immediately if the interface is
down. Of course it depends where any non-TCP/IP stack is plugging in...

It probably shouldn't be the default behaviour admittedly, otherwise we're
just doing a bunch of interrupt processing for no reason in the most common
case.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] DHCP shuts down Ethernet device?

[Grant Edwards]

On Mon, Apr 23, 2001 at 08:27:38PM +0100, Jonathan Larmour wrote:

> > 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.
> 
> I'm wondering: isn't the problem just that configuring the
> interface down calls the _stop() method? Why not just not do
> that? The common eth driver already just has eth_drv_recv()
> return immediately if the interface is down. Of course it
> depends where any non-TCP/IP stack is plugging in...

In my case, The non-IP stack hooks into the Ethernet driver at
the same level that the TCP/IP stack does. I decided to change
my _stop() method so that it doesn't shut off the interface, it
just sets a flag so that packets normally passed to the TCP/IP
stack are discarded (this should result in the behvior expected
by the TCP/IP stack).

> It probably shouldn't be the default behaviour admittedly,
> otherwise we're just doing a bunch of interrupt processing for
> no reason in the most common case.

Right.

-- 
Grant Edwards
grante@visi.com