What's new

Maximum DHCP Lease Time?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

gatorback

Regular Contributor
I have been having a problem with wireless home automation devices staying on the network as described here:

http://forums.smallnetbuilder.com/t...requently-dropped-from-lan.30568/#post-245463

The wifi MAC addresses are pinned / reserved to LAN IP addresses, but as I understand it they leased for a finite amount of time by the DHCP server. The default DHCP lease is for 86400s (1 day). I am hoping that by changing it to many weeks or months, that this would resolve the wifi devices dropping off the network.

My questions is: what is the maximum number of seconds? If the default is 86400, then it must be greater than a 16-bit integer (max would be 2^16 or 65536). Is it reasonable to expect it to be a 32-bit unsigned integer? Hopefully, the assumption that the units are seconds of an unsigned integer is correct.
 
Last edited:
I put in a large number and it replied not valid enter between x and 26400 or some such and max I got was 30 days.
 
You can do IP reservation, per device, on router,
But it still gets a lease which it needs to periodically renew.

I have mine set to 604800 which is 7 days. That is the maximum the GUI will allow (I'm using John's fork).
 
You will have to switch to static IPs if you don't want to involve any lease into the equation, as a lease will have to be set to expire after a certain time (and many clients will try to renew their lease once they reach half of the lease's time).
 
Excellent discourse gentlemen. If I could configure these devices as static IPs, that would be great: I did not see that as a configuration option for these IOT-HOA devices. I suspect that what is happening is that when the lease is up, then the devices are failing to renew due to some unknown reason (unclear if it is problem with router or devices).

I can confirm that 2678400 is the maximum accepted value allowed (arbitrary limit?). If that is seconds then that translates to 30 days: the default setting is 86400 (1-day) I am contemplating an experiment where:

1) Leases are configured for 30 days
2) When all wifi devices are assign and IP address then start a timer (t=0)
3) Perform daily checks to ensure that MAC address are assigned to an IP and ping to verify

If daily checks are successful to day 29, then conclude the problem is renegotiating a daily lease. Comments? Maybe change seconds to hours per mstombs if lease renegotiation is the culprit

It is interesting to note there are 3 wifi devices (2.4 GHz) that are to always be connected to the router: the Ubiquiti device is consistently connected to the router, where as the other two seem to drop out frequently: it is automatically rebooted by a ping watchdog. Rebooting the router puts the two wifi devices back on the LAN so maybe this indicates a problem with the router?
 
Last edited:
You could also check the dnsmasq documentation to see if it's possible to specify a different lease time for a specific MAC through dnsmasq.conf. If it is, then you could configure your problematic devices through a dnsmasq.postconf or dnsmasq.conf.add script.
 
Whilst this discussion about DHCP leases might be interesting, looking at your other post you linked to in post#1 there is nothing to suggest that your problem is anything to do with DHCP.

The <incomplete> response from your arp command tells you that you are trying to contact a device that is not connected to the network. The router will have broadcast another arp request but the device hasn't responded.
 
Last edited:
The problem lies in the device not the router or dhcp.

This is an interesting comment. I am interested in understanding the line of reasoning that the problem lies with the wifi devices and not the router / DHCP. Can you walk me through it? Thanks
 
You suggested it might be a problem with the routers DHCP "or other services" but you gave no explanation why you thought that.

1) DHCP does not have the ability to disconnect devices from the network. All it does is issue IP addresses when asked for them.
2) Your arp output shows that it has successfully issued that device an IP address in the past.
3) The fact that your arp command shows <incomplete> strongly suggests that the device is not connected to the network, but that has nothing to do with DHCP.

What would be helpful would be if you could issue the "wl -i eth1 assoclist" and "wl -i eth2 assoclist" commands next time this happens to see if the device is still connected to the access point. I suspect it is not.
 
I'm at a small ISP and have been wondering what the longest is that devices will accept.

Because of IP address depletion and that this is an ISP, I use a subnet of the CGN (Carrier Grade Network) space of 100.64.0.0/10. The routable addresses we have are set up as pools to be shared by the CGN addresses. Consequently, I'm not worried about using up my available address space.

I found out some time ago that SonicWall devices won't work if you assign them a lease time of a year. 90 days seems okay, though.

One thing that we do is provide free wifi to the city park to encourage kids to get out in the park and for mothers to take their kids to the park so that they can surf the internet. Currently I have the lease time at 90 days for this.

Previously, the lease was set to two years (I've experimented with far more than this). I saw something rather curious -- some iphones would accept the two year lease the first time, but after that, they asked for and got 90 day leases. That's why I set it back to 90 days. Has anyone ever seen anything like this before?

Thanks.
 
I found out some time ago that SonicWall devices won't work if you assign them a lease time of a year. 90 days seems okay, though.

I'd say having excessively long lease time is not a good idea. The lease will change whenever someone changes MAC address. A potential malicious customer might therefore easily deplete your lease pool by sending requests with different MACs, and filling up the pool within the span of a few days.
 
I'd say having excessively long lease time is not a good idea. The lease will change whenever someone changes MAC address. A potential malicious customer might therefore easily deplete your lease pool by sending requests with different MACs, and filling up the pool within the span of a few days.

That would be pretty tough to do. A lot of work changing spoofing MAC addresses with no reward. That is an interesting idea that I hadn't thought of, though.

It kind of reminds me of a problem we saw when I was in grad school in the 1970s. The school had an IBM mainframe and a couple of very bright undergrads I knew took note of the fact that the job numbers were all four digits long. Every time someone loaded another deck of cards, it would increment the number until it got until 9999 and then it would restart at 0100, skipping job numbers that were still in use. So their idea was to submit 10,000 jobs to the mainframe with each job waiting for a procedure before they could continue. They wanted to see if they could lock the machine down so that nobody could load another deck of cards until something was able to run.

Each job card at the start of the deck had a unique identifier. They started by duplicating the job cards but I pointed out to them that if it is possible for the computer operator to delete all jobs with that identifier then he could delete all their jobs with just one command. Each job was about four cards long and the other two cards were identical. So we wrote a FORTRAN program (of course) to generate the 10,000 card decks they needed.

On the appointed day, April 1 of 1979 or 1980 (I forget which year), they took their boxes of cards over to the computer center and started loading them about 7 pm. I wasn't back from out of town until about 10 pm so I missed it. Although the card reader could read the cards quite fast (normally a 1,000 cards just took a minute or so to read), there was a pause between each job and so it took them quite a while per box of 1,000 cards. After they got about 3,000 jobs read in, everything shut off for about 15 minutes and then started back up with all their jobs gone.

So for their weeks of planning and an evening of being a minor nuisance to other students waiting to do their homework, it ended up being somewhat anticlimatic.

Anyway, I have two reasons for using such long addresses:

1) Minor curiosity about how many individual connections we will see over the course of a few months. With a sufficiently long lease, I just have to count the number of entries in the lease file.

2) More importantly, if the DHCP daemon should crash and I don't notice it, the customers wouldn't need to renew their IP address leases. Being a small ISP, if I'm out of town and something goes down, it doesn't get fixed until I get back to town.

But it may be a good idea, just in case, to expand my subnet of 100.64/10 from a /16 to maybe a /14, just in case.

By the way, I'm getting ready to add three more NAT devices for the CGN. Each will handle a portion of the address space and have its own routable pool of about 50 IP addresses. Then if the server itself should crash, most everything could automatically switch to another NAT device. The customer units do a ping every 5 minutes to our gateway and if they miss 3 pings in a row, the devices reboot. When they reboot, then they will pick up an IP address from one of the devices aailable.
 
That would be pretty tough to do. A lot of work changing spoofing MAC addresses with no reward.

With any Asus router it's as simple as changing one nvram, issuing a DHCP lease renew. Rince, repeat, can be done with 5-7 lines of scripting.

Some people do it just because they can. See people who were DDoSing this forum a few years ago - I could never understand why someone would want to do that to a forum devoted to providing technical support. Probably someone doing it just because they could, and it felt good to their personal ego. So, probably best to keep that in mind as a potential problem :)

My recommendations for your points:

1) Keep track of unique MACs that request leases in a database. You could also log them, and parse the log on a regular basis to count the number of unique MACs found in the log.

2) If you don't trust your DHCP server, I'd recommend implementing some form of watchdog then (or maybe a failover server that might come online if the primary stops responding).
 
With any Asus router it's as simple as changing one nvram, issuing a DHCP lease renew. Rince, repeat, can be done with 5-7 lines of scripting.

Some people do it just because they can. See people who were DDoSing this forum a few years ago - I could never understand why someone would want to do that to a forum devoted to providing technical support. Probably someone doing it just because they could, and it felt good to their personal ego. So, probably best to keep that in mind as a potential problem :)

My recommendations for your points:

1) Keep track of unique MACs that request leases in a database. You could also log them, and parse the log on a regular basis to count the number of unique MACs found in the log.

2) If you don't trust your DHCP server, I'd recommend implementing some form of watchdog then (or maybe a failover server that might come online if the primary stops responding).

Suppose it takes about 10 seconds per MAC address. That works out to 8.640 per day. In the current block, that would take more than 7 days of around the clock spoofing to cover a /16 block of addresses.

Also, if someone does try spoofing addresses, with the long lease times for the customers, the customers will continue to be able to connect without a problem since the DHCP software maintains a copy of all current addresses that have been assigned, the MAC addresses, and the lease times.

In addition, the equipment (fixed wireless radios) at the customers house is nearly always acting as a NAT device itself. There are a few exceptions, but not many and most are either businesses or people who work from home and have better things to do. If someone were to try spoofing from home, all they would be doing is affecting their own connection and nobody else's.

I do trust the DHCP server -- I've run DHCP servers on OpenBSD for at least 15 years and only once has the server software crashed. My primary goal is for it to keep things going for a while with minimal help if I should happen to be hospitalized for a while. My goal is for everything to work for at least six months if I can't be around.

You do make some good points. I will probably expand the block of addresses I'm using to make it far more difficult to spoof them all. Another approach would be to drop the length of the lease time for the free users in the park to less than 5 days. I won't be able to take a quick look at any time and see how many have connected in the last three months, but I can live with that. Then in the unlikely possibility that someone tries to spoof enormous numbers of addresses, the addresses will be expiring long before they can use them all.

I could easily have each server e-mail me a daily report of the number of address leases they have, but I know through experience that I probably wouldn't look at it. Perhaps if I set it up to send me an e-mail if more than some percentage is in use would do it. That way, it would be unusual enough that I would take notice.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top