[Cu-wireless] dhcp bug needs fixing

[Tim Yardley]

I added basic DHCP packet building to the rewrite of libnet
(http://packetfactory.net) quite a while back.  You could easily write an
app (or modify the included dhcp example code) to send periodic dhcp
requests using a specified id (that way you know the response is meant for
you).  That could be used as a trigger to restart dhclient if needed.

Scenario would be something like:

Dhclient runs like normal, if it exits with code -2 then fire off this app
to run in the background.  If it gets a response back from the gateway,
restart dhclient to re-establish the link and shut down the dhcp server.

You could make this even more elaborate if you wanted.  Looking at the
example code, you will see more about how it can be applied.

/tmy

-----Original Message-----
From: cu-wireless-admin at lists.groogroo.com
[mailto:cu-wireless-admin at lists.groogroo.com] On Behalf Of David Young
Sent: Wednesday, January 15, 2003 12:19 PM
To: wireless at ucimc.org
Subject: [Cu-wireless] dhcp bug needs fixing


I need some help solving a bug in our node software.

While a C-U Wireless node boots, it tries to discover an Internet
gateway on each ethernet by running the DHCP client, dhclient, on each
ethernet interface. A node gives the -1 option to dhclient, which
means to try a few times to get a lease, and if no lease is acquired,
exit with code -2.

If dhclient quits with code -2, a node takes it to mean that there is
no gateway on that ethernet---or, at least, there is no DHCP server. So
the node starts a DHCP server on that interface.

There are a few things wrong with this approach.

  1 if a subscriber has not yet plugged his node into his Internet gateway
  before it boots, then his node will choose to run a DHCP server on
  every interface.

  2 if a subscriber's node gets a DHCP lease at boot, but at some time his
  gateway does not renew the node's DHCP lease, then dhclient will quit.
  Once dhclient quits, it does not start up again.

  3 once a node starts the DHCP server on a port, it will not use an
  Internet gateway on that port until it reboots.

Scenario #2 occurred the other day at the IMC, because IMC's router
crashed. Even after it was restored, the wireless network did not
re-establish a route to the Internet, because dhclient had quit.

The upshot is this: a node is inflexible about the time that its Internet
gateway is connected, and it will not tolerate a temporary failure of its
gateway. Also, once an ethernet port is assigned the "subscriber port"
role, it will not change from that role, even if after a gateway w/
DHCP server has been attached.

This problem affects the reliability and usability of nodes.  Can somebody
come up with a solution?

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933

_______________________________________________
Cu-wireless mailing list
Cu-wireless at lists.groogroo.com
http://lists.cu.groogroo.com/cgi-bin/listinfo/cu-wireless