DHCP timeout is too short for this college network

[Daniel Gnoutcheff <daniel gnoutcheff name>]

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