Hacker News Reader

Comment by ploxiln | Hacker News Reader

Here's a theory based on a bunch of un-substantiated and un-researched facts:

Some routers do not allow traffic from IPs which are not active DHCP leases. When DHCP lease expires, they block traffic. But many routers don't enforce this.

Some routers give out super short DHCP leases - as short as 30 seconds. But the typical length is 12 or 24 hours.

A public or semi-shared wifi router is more likely to use these policies to prevent exhausting the local subnet address pool, which is typically around 254 addresses.

Mac OS X doesn't believe that renewing a DHCP lease in 30 seconds is ever really necessary, limits the renewal frequency to once per minute.

I'd check the dhcp lease time.

View on HN

An intriguing and plausible theory! In my case though it seems that the lease is 86400 seconds (24 hours), or at least that's what the router is claiming to give out. So I don't think this is it. My guess is that renewing the DHCP lease has some side effect of resetting the session, rather than it being the actual DHCP lease renewal that is important.

Are you serious? A 30 second lease is insane.

I've seen DHCP servers that TAKE 60 seconds to give a lease.

Was that the server, or the client waiting that long? THe DHCP spec requires the client to broadcast a request, then wait for a while (unspecified) and collect answers, then choose the best answer (metric unspecified).

Sometimes when I write DHCP clients I choose the metric as "fastest", then just choose the first answer and don't wait for any more. And it takes on average a few milliseconds to get a lease.

It wasn't the client, but beyond that honestly I don't know, I didn't get into the nitty gritty of it. Could have been a terrible or overloaded piece of server hardware, or maybe a network loop or something else misbehaving between the client and server.

We built a portable device that starts a DHCP client and tries to get a lease on an Ethernet plug event, and if no lease is acquired after a certain amount of time, the device assumes it has been plugged directly to a PC (or an "ad-hoc", isolated network with a switch and no router) and will kill the client and start a DHCP server itself, so you can access the device's webserver directly. I wasn't onsite, but the solution was simple - we just increased the timeout to wait for a lease before starting the server.

Not sure how it works on Linux, but on Windows, if the acquired DHCP IP has a lease time of 60 minutes, then Windows will try to renew that IP anytime after 1/2 the lease time (i.e. 30 minutes). This is why in Corporate environments good practice is to keep lease time 1 hour or more.

Depending on what switch you're plugging into, this could easily be Cisco Portfast or similar catching you out.

When the port goes active (layer 2 link) the switch inspects but doesn't forward packets to try and ensure you've not just added a loop into your ethernet network. After a minute or so, if everything looks normal, the switch then starts letting the device talk to the rest of the network.

If you don't know about it then this can be annoying at best as you seem to have a layer2 link but DHCP can seem to take an age to start working :)

I'd note that DHCP broadcasts are unreliable and could simply be dropped. Then the client is responsible for retrying them.

Except that packets don't really get dropped for wire errors at all anymore. Not unless the bandwidth is oversubscribed and there's a collision (really a buffer overflow on a router).

Definitely unsubstantiated: If this is just at an AirBnB, it's probably not going to be a commercial wifi system.

On your topic, though, Princeton noticed something similar with regards to iOS and DHCP, although it is several years old now: https://www.net.princeton.edu/apple-ios/ios41-allows-lease-t... (last tested version was iOS 6.1)

Reply on news.ycombinator.com