Re: DHCP timeout is too short for this college network
2010/1/22 Daniel Gnoutcheff : > From what I've seen, it looks like dhclient already does something similar. > > If I put "timeout 45;" in dhclient.conf and then run dhclient on a network > where no DHCP servers are present (i.e. no OFFERs are received), then > dhclient does indeed timeout in 45 seconds. > > However, as soon as it gets an OFFER, it seems that the 45 second countdown > stops. dhclient then proceeds to try and get an ACK, and this process seems > to be subject to a separate (hard coded?) timeout. If that fails, then > dhclient returns to the DISCOVER stage and once again waits 45 seconds for > an OFFER. > > So the good news is, dhclient is already setup so that it times out > relatively quickly when DHCP servers are not present, and it's also willing > to wait longer when dealing with lazy servers. > > The bad news is that this behavior is not well documented, and I don't know > if there are any limits on how many times it will "loop" like this. If I > were to hit a broken DHCP server that always sent OFFERs but never sent > ACKs, it's possible that dhclient would never time out. But I'd argue that > this would be a dhclient bug that may be worth fixing anyway. > Maybe this second timeout is defined in the RFCs. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
>> Do Windows and MacOS users actually tolerate waiting for 3 minutes before >> getting online? I can imagine some non-Linux leverage here. > > They probably don't tolerate 3 minutes to get a DHCPOFFER, but they may > tolerate 3 minutes for the *whole* transaction if an OFFER has been > received within some lower timeout. Dan: here I was not talking about software but about people. Let me rephrase: Do HUMAIN BEINGS using Windows and MacOS tolerate waiting for 3 minutes before getting online? I can imagine some non-Linux leverage here. I see little value in "enhancing" NM to support DHCP servers so wrong that they make *everyone's* life miserable (including Windows and MacOS users). ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
Hello Dan, thanks for your reply! 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. Ah, I was afraid it was something like this. That's unfortunate :( 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. From what I've seen, it looks like dhclient already does something similar. If I put "timeout 45;" in dhclient.conf and then run dhclient on a network where no DHCP servers are present (i.e. no OFFERs are received), then dhclient does indeed timeout in 45 seconds. However, as soon as it gets an OFFER, it seems that the 45 second countdown stops. dhclient then proceeds to try and get an ACK, and this process seems to be subject to a separate (hard coded?) timeout. If that fails, then dhclient returns to the DISCOVER stage and once again waits 45 seconds for an OFFER. So the good news is, dhclient is already setup so that it times out relatively quickly when DHCP servers are not present, and it's also willing to wait longer when dealing with lazy servers. The bad news is that this behavior is not well documented, and I don't know if there are any limits on how many times it will "loop" like this. If I were to hit a broken DHCP server that always sent OFFERs but never sent ACKs, it's possible that dhclient would never time out. But I'd argue that this would be a dhclient bug that may be worth fixing anyway. 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? I skimmed the documentation about dhclient's OMAPI interface to see what controls are available. It doesn't look good. :( But I may yet be able to find something (undocumented?) that would help, if we do indeed go this route. Perhaps I'll read the dhclient source code, methinks that'll help :) Have a good one, Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
On Wed, 2010-01-20 at 11:34 +0100, Marc Herbert wrote: > Daniel Gnoutcheff a écrit : > > > OK, the problem I'm having is a college campus network that has really > > slow DHCP severs. As in, up to 3 *minutes* to get a lease. > > > > [...] > > > > It's worth mentioning that the resident IT department has acknowledged > > the problem. Sadly, it also seems like they aren't going to do anything > > about it anytime soon, presumably because Windows and MacOS tolerate the > > slowness. So in the meantime, it'd be great to get n-m to work with > > networks like these -- and I volunteer to help! (This would be my first > > time contributing to a software project, so it might take me a while, > > but I'll give it my best shot.) > > Do Windows and MacOS users actually tolerate waiting for 3 minutes before > getting online? I can imagine some non-Linux leverage here. They probably don't tolerate 3 minutes to get a DHCPOFFER, but they may tolerate 3 minutes for the *whole* transaction if an OFFER has been received within some lower timeout. Which is what I think we should be doing in NM, but which I think will take some work in dhclient first. I'd be happy to be wrong. As much as I hate screenscraping, the absolute fallback to this would be to consume dhclient's stdout/stderr output (making sure never to block the pipe!!) and look for the OFFER. That's a last resort though. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
Daniel Gnoutcheff a écrit : > OK, the problem I'm having is a college campus network that has really > slow DHCP severs. As in, up to 3 *minutes* to get a lease. > > [...] > > It's worth mentioning that the resident IT department has acknowledged > the problem. Sadly, it also seems like they aren't going to do anything > about it anytime soon, presumably because Windows and MacOS tolerate the > slowness. So in the meantime, it'd be great to get n-m to work with > networks like these -- and I volunteer to help! (This would be my first > time contributing to a software project, so it might take me a while, > but I'll give it my best shot.) Do Windows and MacOS users actually tolerate waiting for 3 minutes before getting online? I can imagine some non-Linux leverage here. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
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
Re: DHCP timeout is too short for this college network
On Mon, 2010-01-11 at 15:25 +, Gavin McCullagh wrote: > Hi, > > On Mon, 11 Jan 2010, Benoit Boissinot wrote: > > > I've seen cases (wired network) where the communication actually work > > only about 60 seconds after the the interface it brought up (I think > > it has to do with some interaction with the switches). Maybe that's > > the case here? > > This is often caused by Spanning Tree running on the switch and that port > not being set to use "Portfast" (aka "Edge") mode. Sometimes it takes up to a minute with Gigabit Ethernet to actually ramp up the PHY and get the links trained too. That's usually a thing of the past, but can still happen depending on the hardware. But I'd expect that the kernel driver wouldn't actually set IFF_LOWER_UP on the interface until it has actually successfully negotiated the link... And thus NM wouldn't start DHCP until the device could actually transmit stuff. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
On Tue, Jan 12, 2010 at 1:22 AM, John Mahoney wrote: > > > On Tue, Jan 12, 2010 at 1:02 AM, John Mahoney wrote: > >> Yeah too good to be true. I see two ways to change the timeout. >> >> 1.Change this - /NetworkManager/src/dhcp-manager/nm-dhcp-manager.c:#define >> NM_DHCP_TIMEOUT 45 /* DHCP timeout, in seconds */ >> >> OR >> >> 2. call this function somehere? /NetworkManager/src/nm-device-olpc-mesh.c: >> nm_device_set_dhcp_timeout >> (NM_DEVICE (self), 20); >> >> To compile follow: >> git clone git://anongit.freedesktop.org/NetworkManager/NetworkManager.git >> cd NetworkManager >> ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var >> make >> sudo make install >> >> There are alteast 10 dev packages you will have to install, but keep >> running >> autogen.sh and when it fails go hunt down the dev package. Note some are >> not obvious by the name. >> >> >> > PS grab the code from the network manager ppa if you are using ubuntu. I > do not believe the the git command I specified works out of the box. > Network manager is a tricky package to build because there are so many > package dependencies . At least you are not cross compiling it;) Dan > Williams tends to bang out answers around Friday every week so if you wait > til then you may get a answer from a pro! > > PSS If you do use the git on ubuntu you have to disable apparmor(Disclaimer: this may reduce security on your box.) sudo ln -s /etc/apparmor.d/sbin.dhclient3 /etc/apparmor.d/disable/sbin.dhclient3 sudo apparmor_parser -R /etc/apparmor.d/sbin.dhclient3 Sorry if my notes are confusing,but I did this all a while ago and was trying to step though on a dev box to explain for you how I had done it...Good luck. I forgot to mention the obvious earlier. Youneed to install git and auto-tools before the first two commands I mentioned will work. best of luck, john ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
On Tue, Jan 12, 2010 at 1:02 AM, John Mahoney wrote: > Yeah too good to be true. I see two ways to change the timeout. > > 1.Change this - /NetworkManager/src/dhcp-manager/nm-dhcp-manager.c:#define > NM_DHCP_TIMEOUT 45 /* DHCP timeout, in seconds */ > > OR > > 2. call this function somehere? /NetworkManager/src/nm-device-olpc-mesh.c: > nm_device_set_dhcp_timeout > (NM_DEVICE (self), 20); > > To compile follow: > git clone git://anongit.freedesktop.org/NetworkManager/NetworkManager.git > cd NetworkManager > ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var > make > sudo make install > > There are alteast 10 dev packages you will have to install, but keep > running > autogen.sh and when it fails go hunt down the dev package. Note some are > not obvious by the name. > > > PS grab the code from the network manager ppa if you are using ubuntu. I do not believe the the git command I specified works out of the box. Network manager is a tricky package to build because there are so many package dependencies . At least you are not cross compiling it;) Dan Williams tends to bang out answers around Friday every week so if you wait til then you may get a answer from a pro! ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
Yeah too good to be true. I see two ways to change the timeout. 1.Change this - /NetworkManager/src/dhcp-manager/nm-dhcp-manager.c:#define NM_DHCP_TIMEOUT 45 /* DHCP timeout, in seconds */ OR 2. call this function somehere? /NetworkManager/src/nm-device-olpc-mesh.c: nm_device_set_dhcp_timeout (NM_DEVICE (self), 20); To compile follow: git clone git://anongit.freedesktop.org/NetworkManager/NetworkManager.git cd NetworkManager ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var make sudo make install There are alteast 10 dev packages you will have to install, but keep running autogen.sh and when it fails go hunt down the dev package. Note some are not obvious by the name. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
John Mahoney wrote: On Ubuntu 9.10 it appears you can edit the file /etc/dhcp3/dhclient.conf and uncomment the line timeout in the file and increase it to say 180 seconds. Thanks for the suggestion! Sadly, it didn't work. I'm running Ubuntu 9.10 too, and I do indeed see that the config file gets copied as you indicate. I tried replacing #timeout 60; with timeout 360; But N-M continues to impose its 45-second timeout: Jan 11 21:20:00 dan-lap NetworkManager: Activation (eth0) Beginning DHCP transaction (timeout in 45 seconds) ... Jan 11 21:20:46 dan-lap NetworkManager: (eth0): DHCP transaction took too long, stopping it. I suspect that /etc/dhcp3/dhclient.conf only controls dhclient's timeouts. The dhclient timeouts are already OK for me. The thing I need to change seems to be the additional 45-second timeout that N-M imposes; if dhclient takes longer than 45 seconds, N-M kills it. When I run dhclient manually, I avoid this additional timeout. Once that's out of the picture, dhclient is allowed to run its course, and it usually succeeds. As far I can tell, N-M's timeout is hard-coded, but I'd be delighted to be proven wrong on that. ;) I also investigated the possibility that the slowness was caused by tree-spanning (with help from Gavin). However, I'm pretty convinced that's not it. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
Sven Nielsen wrote: Ask the dhcp team on your campus why they are giving away DHCP leases for 3! days (286274 seconds): I've heard that 3 days is the Microsoft default. The IT department is a Microsoft shop, so that probably explains it. ;) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
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. 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
Re: DHCP timeout is too short for this college network
Am Montag, den 11.01.2010, 17:02 -0200 schrieb José Queiroz: > I understand that, if the address pool is exausted, the DHCP server > should respond immediatelly with a DHCPNACK, and not start a ping > sweep to find free addresses. > from dhcpd.conf (http://www.daemon-systems.org/man/dhcpd.conf.5.html): "... If no addresses are found that can be assigned to the client, no response is sent to the client." DHCPNACK only happens when there is an active deny condition for the specific client to use a specific IP. I was wrong about the ping though. I thought the server would do this periodically in "crowded" situations. However, it is only true for abandoned ip addresses: "The DHCP server checks IP addresses to see if they are in use before allocating them to clients. It does this by sending an ICMP Echo request message to the IP address being allocated. ..." (read on to get the detailled process.) There surely is some issue with the DHCP server. Badly configured network, too much load on the DHCP server computer through other processes and daemons, badly configured failover DHCP servers etc. etc. could be dozen causes. I know, it is extremly tricky to resolve network problems once you have them ;) But, reducing the lease time might as well help, at least admins might give it a try for a few days. Although, exhausted address pool should have showed up in the logs which the admins most probably checked already. > The only way I can think of to implement this division without > separating "known" and "unknown" clients in independent broadcast > domains (by means of physical separated switches, or even VLANs), is > pre-registering the known clients in dhcp configuration. I'm afraid, yes. VLANs however, are one option which should really be considered, especially for security reasons. Chances are there already is a VLAN infrastructure or even multiple physically separate networks, because having critical research and accounting PCs on the same net with freely accessible lan ports or wlan access points is not a very wise thing to do, obviously. Well, back to your questions. Surely it is now bug in nm. However it still is frustrating to have all Windows and Macs connect when linux won't. That should not happen. Even when it is the other ends fault. So, I hope the response mailed earlier by John Mahoney was of some help ;) Regards, Sven ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
On Ubuntu 9.10 it appears you can edit the file /etc/dhcp3/dhclient.conf and
uncomment the line timeout in the file and increase it to say 180 seconds.
These values then get copied into /var/run/nm-dhclient-{interface-name}.conf
and that is the config file used by nm. This would be a hack and probablly
not a good long term solution, but it may work.
--
John
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
2010/1/11 Sven Nielsen : > Ask the dhcp team on your campus why they are giving away DHCP leases > for 3! days (286274 seconds): > >> >> Jan 10 21:40:12 DHCPACK of 149.106.215.247 from 149.106.192.253 >> >> Jan 10 21:40:13 bound to 149.106.215.247 -- renewal in 286274 > seconds. > > Maybe the DHCP server is continously short on free IP addresses because > many addresses that are actually free, are still bound to clients that > connected e.g. 2 days ago. (It surely gets hundreds of requests every > day.) Might be that every time it tries to process a DHCP requests, it > has no addresses left and then has to go through all addresses manually > by way of pinging them to find out which ones are not in use anymore > before it finds a free address. This might easily be one of the causes > for the long delays. I understand that, if the address pool is exausted, the DHCP server should respond immediatelly with a DHCPNACK, and not start a ping sweep to find free addresses. > > Also, perhaps the DHCP configuration should be divided into two address > pools (it it isn't already), one address pool for resident computers > (Destkop PCs and laptops of university staff), and another pool for > student laptops (unknown DHCP clients). The only way I can think of to implement this division without separating "known" and "unknown" clients in independent broadcast domains (by means of physical separated switches, or even VLANs), is pre-registering the known clients in dhcp configuration. Is there a better way to do that? o_O ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
Ask the dhcp team on your campus why they are giving away DHCP leases for 3! days (286274 seconds): > >> Jan 10 21:40:12 DHCPACK of 149.106.215.247 from 149.106.192.253 > >> Jan 10 21:40:13 bound to 149.106.215.247 -- renewal in 286274 seconds. Maybe the DHCP server is continously short on free IP addresses because many addresses that are actually free, are still bound to clients that connected e.g. 2 days ago. (It surely gets hundreds of requests every day.) Might be that every time it tries to process a DHCP requests, it has no addresses left and then has to go through all addresses manually by way of pinging them to find out which ones are not in use anymore before it finds a free address. This might easily be one of the causes for the long delays. Also, perhaps the DHCP configuration should be divided into two address pools (it it isn't already), one address pool for resident computers (Destkop PCs and laptops of university staff), and another pool for student laptops (unknown DHCP clients). Then the resident address pool can keep the policy of 3-day-lease time while short-lived clients like students laptops and WLAN mobiles could be shortened to a dhcp lease of 1 hour or even less. cheers, sven ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
Hi, On Mon, 11 Jan 2010, Benoit Boissinot wrote: > I've seen cases (wired network) where the communication actually work > only about 60 seconds after the the interface it brought up (I think > it has to do with some interaction with the switches). Maybe that's > the case here? This is often caused by Spanning Tree running on the switch and that port not being set to use "Portfast" (aka "Edge") mode. Gavin ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
2010/1/11 José Queiroz : > Hi Daniel, > > 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. > > 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 seen cases (wired network) where the communication actually work only about 60 seconds after the the interface it brought up (I think it has to do with some interaction with the switches). Maybe that's the case here? regards, Benoit ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
Hi Daniel, 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. 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. 2010/1/11 Daniel Gnoutcheff : > Hello all, > > First off, let me take this opportunity to thank you all for this really > cool piece of software. Networking with n-m is great fun. :) > > OK, the problem I'm having is a college campus network that has really slow > DHCP severs. As in, up to 3 *minutes* to get a lease. Here's a typical > dhclient run, with timestamps: > >> Jan 10 21:38:26 Listening on LPF/eth0/00:15:58:c6:29:b6 >> Jan 10 21:38:26 Sending on LPF/eth0/00:15:58:c6:29:b6 >> Jan 10 21:38:26 Sending on Socket/fallback >> Jan 10 21:38:30 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 >> Jan 10 21:38:38 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval >> 12 >> Jan 10 21:38:50 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval >> 20 >> Jan 10 21:38:50 DHCPOFFER of 149.106.215.247 from 149.106.192.253 >> Jan 10 21:38:50 DHCPREQUEST of 149.106.215.247 on eth0 to 255.255.255.255 >> port 67 >> Jan 10 21:38:54 DHCPREQUEST of 149.106.215.247 on eth0 to 255.255.255.255 >> port 67 >> Jan 10 21:39:02 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 >> Jan 10 21:39:06 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 >> Jan 10 21:39:15 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval >> 12 >> Jan 10 21:39:21 DHCPOFFER of 149.106.215.247 from 149.106.192.253 >> Jan 10 21:39:21 DHCPREQUEST of 149.106.215.247 on eth0 to 255.255.255.255 >> port 67 >> Jan 10 21:39:25 DHCPREQUEST of 149.106.215.247 on eth0 to 255.255.255.255 >> port 67 >> Jan 10 21:39:32 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 >> Jan 10 21:39:39 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval >> 14 >> Jan 10 21:39:53 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval >> 18 >> Jan 10 21:40:02 DHCPOFFER of 149.106.215.247 from 149.106.192.253 >> Jan 10 21:40:02 DHCPREQUEST of 149.106.215.247 on eth0 to 255.255.255.255 >> port 67 >> Jan 10 21:40:08 DHCPREQUEST of 149.106.215.247 on eth0 to 255.255.255.255 >> port 67 >> Jan 10 21:40:12 DHCPACK of 149.106.215.247 from 149.106.192.253 >> Jan 10 21:40:13 bound to 149.106.215.247 -- renewal in 286274 seconds. > > As you can see, dhclient does have the patience needed to drag a lease out > of these servers. But it took over 100 seconds and thus would have been > prematurely killed by n-m. Thus, I usually have to manually tell n-m to > retry, multiple times. This often gets quite annoying, and on bad days I > often end up killing n-m and using dhclient manually. > > It's worth mentioning that the resident IT department has acknowledged the > problem. Sadly, it also seems like they aren't going to do anything about it > anytime soon, presumably because Windows and MacOS tolerate the slowness. So > in the meantime, it'd be great to get n-m to work with networks like these > -- and I volunteer to help! (This would be my first time contributing to a > software project, so it might take me a while, but I'll give it my best > shot.) > > dhclient has its own set of timeouts, which seem to be setup quite > intelligently. So it seems to me that, from the perspective of my network at > least, we would do well to let dhclient decide when DHCP is hopeless. Is > there anything getting in the way that? Is the link-local thing going to be > a problem? > > Have a good one, > Daniel > > ___ > 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
