Bill Sommerfeld wrote:
On Mon, 2006-08-14 at 16:46 -0400, Dave Miner wrote:
Unless I'm missing something, it should be falling back either to INIT
state and starting from scratch, which will of course work on a new
network, or going to INIT-REBOOT if there's a /etc/dhcp/<if>.dhc file,
and sending that request as a broadcast, in which case servers should
NAK the client if they know it's on the wrong network.
Unfortunately, it appears that many networks set up to host visiting
laptops are set up with dhcp servers which ignore (rather than NAK) a
DHCPREQUEST for an off-link address -- the net result was that, after I
started running solaris on my laptop, I often ran into an extended
period of futzing around on first contact with the new network until I
started doing a "dhcp release" as part of the scripts I hope to throw
away once NWAM integrates..
Yes, that's a good point. I've tended not to see this because I usually
run my mobile clients with RELEASE_ON_SIGTERM in /etc/default/dhcpagent
set to "yes". A practice which I'd highly recommend to others, and
perhaps argues that we should be looking at a different default.
I suspect that this is because of a conservative default configuration
setting -- if you have two uncoordinated DHCP servers on the same link
they can peaceably coexist if neither sends NAKs, whereas if one or both
send NAKs in response to clients requesting the other's addresses, you
can provoke high levels of traffic and otherwise make the link an
unpleasant place to be.
Yeah, I wouldn't be surprised if most consumer-grade
firewall/router/dhcp server/access point combo boxes are set up this
way; I don't run one so I don't have any data. It probably would cut
down on their support calls.
So I think that, regardless of lease length, after an event which might
signify a change in connectivity, we need to move somewhat more quickly
to sending DHCPDISCOVER if there are no responses to a broadcast
DHCPREQUEST.
I think that's reasonable; this may be where the DNA heuristics could be
useful (he says knowing Jim will start screaming ;-)
Dave
_______________________________________________
networking-discuss mailing list
[email protected]
