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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list