Re: DHCP timeout is too short for this college network

[Dan Williams <dcbw redhat com>]

On Mon, 2010-01-11 at 22:59 -0500, Daniel Gnoutcheff wrote:
> José Queiroz wrote:
> > NM needs a lot of fixes and improvements, but I think that in this
> > case, it is completely innocent.
> > 
> > Your dhcp server is too lazy, as you can see: it only answered for the
> > initial DHCPDISCOVER on the third attempt, the same for the other
> > messages of the DHCP sequence.
> 
> I know that getting N-M to work with lazy DHCP servers is a low 
> priority. So I hereby volunteer to take on the job myself. :)
> 
> dhclient has its own timeout logic, which seems to work nicely with slow 
> DHCP servers; the 'timeout' value seems to specify the timeout on the 
> DHCPDISCOVER stage, and once a server is found, different rules apply.

NM's DHCP timeout is a balance between how fast most networks respond to
DHCP, and timing out a failed connection attempt to move on to the next
applicable connection.  There are various cases where the DHCP timeout
is the amount of latency between NM timing out a legitimate failure and
falling back to a working network.

But the better fix would be for dhclient to indicate that *something*
replied even if lease acquisition isn't complete.  The cases where the
DHCP latency is a problem are cases where we don't expect to get *any*
OFFERs.

So if we could figure out that some server sent an OFFER then we could
extend the internal DHCP timeout in NetworkManager and hopefully handle
your problem.  I'm just not sure how to do that, since i don't think
dhclient has logic to execute the callout script on pre-lease events?

Fixing this might be a combination of additions to dhclient and to
NetworkManager.  But that's the right way to fix it.  Any chance you'd
like to poke around dhclient (including perhaps it's socket-based
control interface?) and see if there's a way to get more information out
of it?

Dan


> So I suppose that one way to address this would be to nuke the DHCP 
> timeout logic that resides in N-M, i.e. let dhclient decide when it's 
> hopeless. Is there anything preventing me from doing that? Is there 
> anything I'm missing, anything that makes it really necessary to have a 
> second timeout in N-M?
> 
> I was going to dive in and make a patch, but I wanted to ping this list 
> before that adventure. :)
> 
> 
> > Maybe you should ask for the support team to analyze the traffic
> > exchanged between your station and the dhcp server, to understand why
> > the messages are being lost.
> 
> I've already approached the IT department and offered my help with 
> fixing their DHCP issues. They have not been receptive. It doesn't seem 
> like they care about this problem much. :(
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list