DHCP lease stuck on 2 hours 43minutes 29 seconds

[Capt.Nemo]

I have set up a network A and a guest network B and everything works fine, except the dhcp leases. Both networks should have 24 hour leases, but everything except the last device to get a lease has a lease time of 2 hours 43 minutes and 29 seconds which does not decrease. If a new device joins network A it gets a lease of 24 hours which decreases as normal, until another device joins later; the later device then gets a lease of 24 hours and the earlier device suddenly drops to 2 hours etc. This behaviour also happens if the separate networks have different lease settings.

The guest network has only a wireless interface, it has no ports allocated. The main network has a wireless and all ports allocated, port one of which is used as a link to the wan port of an Edimax BR6475N router which has a fixed ip address. All other wired connections are through the Edimax. The Edimax and the Billion 8800NL are configured as wireless access points (not bridges not repeaters), but only the Billion offers a dhcp server.


Any ideas what could be going wrong?

[billion_fan]

I have set up a network A and a guest network B and everything works fine, except the dhcp leases. Both networks should have 24 hour leases, but everything except the last device to get a lease has a lease time of 2 hours 43 minutes and 29 seconds which does not decrease. If a new device joins network A it gets a lease of 24 hours which decreases as normal, until another device joins later; the later device then gets a lease of 24 hours and the earlier device suddenly drops to 2 hours etc. This behaviour also happens if the separate networks have different lease settings.

The guest network has only a wireless interface, it has no ports allocated. The main network has a wireless and all ports allocated, port one of which is used as a link to the wan port of an Edimax BR6475N router which has a fixed ip address. All other wired connections are through the Edimax. The Edimax and the Billion 8800NL are configured as wireless access points (not bridges not repeaters), but only the Billion offers a dhcp server.


Any ideas what could be going wrong?

Try restarting the devices that are stuck with 2 hour lease time (a full shut down is best)

[Capt.Nemo]

Thanks for the suggestion, but I should have been more explicit in my earlier post. It is possible to get the devices already issued with a lease to reset to the desired lease period by switching each device off and switching back on. However as soon as a new device (which has not already been issued a lease) joins the network then ALL the existing leases immediately default to 2 hours 43 minutes and 29 seconds and will not move again until they are power-cycled.

I should point out that power-cycling the devices results in ip address conflicts as the dchp server reallocates an address with a 24 hour lease which already exists in the dhcp table with a 2 hour etc lease.

In the light of all the devices reverting to 2 hours 43 minutes 29 seconds each time a new device joins the network power-cycling is not a real solution.

[billion_fan]

Thanks for the suggestion, but I should have been more explicit in my earlier post. It is possible to get the devices already issued with a lease to reset to the desired lease period by switching each device off and switching back on. However as soon as a new device (which has not already been issued a lease) joins the network then ALL the existing leases immediately default to 2 hours 43 minutes and 29 seconds and will not move again until they are power-cycled.

I should point out that power-cycling the devices results in ip address conflicts as the dchp server reallocates an address with a 24 hour lease which already exists in the dhcp table with a 2 hour etc lease.

In the light of all the devices reverting to 2 hours 43 minutes 29 seconds each time a new device joins the network power-cycling is not a real solution.

Have you tried using the attached firmware??

When restarting the device/s all the device should do is request a new lease (8800 will send a offer command and ack command) , the router will issue the same IP, so there shouldn't be any conflicts

[Capt.Nemo]

The firmware version I have is 2.32d.dh14, which I thought was the latest version. I'll try the new version and post again.

Many thanks

[billion_fan]

The firmware version I have is 2.32d.dh14, which I thought was the latest version. I'll try the new version and post again.

Many thanks

Keep me posted, when I tested a older version of this firmware I found the devices that normally get stuck with 2 hour lease time, will not be shown on the DHCP until they are restarted, once restart they should be fine, as long as no changes are made to the DHCP range, or static IP lease list.

Let me know if you experience the same results

[Capt.Nemo]

Variations on a theme I'm afraid. The devices do not get stuck on a 2 hour lease anymore; they simply disappear from the dhcp table.

I switched off all devices except one and used that to update the firmware, then rebooted that device. I switched on each device and checked the dhcp table after each switch on. Everthing was going fine until about the sixth device then everything except that device vanished from the dhcp table leaving only the last device. I am running a mixed bag of windows, linux, android and apple devices, but that should make no difference

I should stress that the devices do appear under their MAC address in station info, but they do not now appear in the dhcp table. I attach a pdf with screenshots of both tables. My understanding is that a device cannot appear as associated and authorised unless it has a dhcp lease.

I do not see this problem when the interface grouping is not set up, even though the two wireless networks are set up and enabled, probably because the ip addresses are being issued from the same pool.

Once again thanks for your help

[Edit] I should point out that wireless connectivity is not as good with the new firmware as the old.

[Capt.Nemo]

I think I may have found the cause of the problems.

The Billion router uses a default ip address of 192.168.?.254. When the new network is set up it uses a default address of 192.168.something else.254. The router then appears to be programmed to offer ip addresses from 192.168.?.1. In my case the NAS was already set up as 192.168.2.254 so the Billion router was set up as 192.168.2.1; unfortunately this meant that it was offering its own address (discovered by poring through the event logs) as a dhcp lease,even though the dhcp pool was set to exclude 192.168.2.1; this led to address collisions.

After changing the Billion to its default address and changing the gateway addresses on the NAS and linux server the dhcp table now seems to be populating properly as each device renews its lease. Whether it was the default ip address or a combination of this and the new firmware that billion-fan so kindly gave me I cannot yet say, and will only find out when (if) I revert to the earlier version.

I'll let you know of any developments.

[Capt.Nemo]

Well, over the last few days I've tried the old firmware and the new firmware in various configurationsand I've come to the conclusion that the dhcp handling is seriously awry.

When a guest network is enabled the router is just unable to keep track of what leases it has issued as these lines taken from the log show.

Apr 9 14:23:35 daemon info syslog: sending OFFER to IP:192.168.2.2, MAC:4c:b1:99:13:7a:26
Apr 9 14:23:35 daemon info syslog: sending OFFER to IP:192.168.2.2, MAC:4c:b1:99:13:7a:26
Apr 9 14:23:36 daemon info syslog: sending ACK to IP:192.168.2.2, MAC:4c:b1:99:13:7a:26
Apr 9 14:23:39 daemon info syslog: sending OFFER to IP:192.168.2.3, MAC:b8:ff:61:97:7b:e1
Apr 9 14:23:39 daemon info syslog: sending OFFER to IP:192.168.2.3, MAC:b8:ff:61:97:7b:e1
Apr 9 14:23:40 daemon info syslog: sending ACK to IP:192.168.2.3, MAC:b8:ff:61:97:7b:e1
Apr 9 14:32:02 daemon info syslog: sending OFFER to IP:192.168.2.4, MAC:b4:52:7e:16:31:cb
Apr 9 14:32:02 daemon info syslog: sending ACK to IP:192.168.2.4, MAC:b4:52:7e:16:31:cb
Apr 9 14:46:27 daemon info syslog: 192.168.2.1 belongs to someone, reserving it for 3600 seconds
Apr 9 14:46:30 daemon info syslog: sending OFFER to IP:192.168.2.2, MAC:5c:f9:38:8b:b6:c6
Apr 9 14:46:30 daemon info syslog: sending OFFER to IP:192.168.2.2, MAC:5c:f9:38:8b:b6:c6
Apr 9 14:46:31 daemon info syslog: sending ACK to IP:192.168.2.2, MAC:5c:f9:38:8b:b6:c6

There is no way that the only active dhcp server should hand out a lease (192.168.2.2) at 14:23:36 to one machine (MAC 4c:b1:99:13:7a:26) and then at 14:46:31 (23 minutes later) hand it out to a different machine (MAC 5c:f9:38:8b:b6:c6). The server's own default should have caused it to reserve 192.168.2.2 for 3600 seconds as can be seen for ip address 192.168.2.1.

I am still using the new firmware, but Billion really needs to sort out the dhcp server, one of the points that attracted me to this router was the ability to set up a guest network, but in fact it does not work. Having a guest network is simply leading to ip address conflicts.

Any comments gratefully received.

[billion_fan]

Well, over the last few days I've tried the old firmware and the new firmware in various configurationsand I've come to the conclusion that the dhcp handling is seriously awry.

When a guest network is enabled the router is just unable to keep track of what leases it has issued as these lines taken from the log show.

Apr 9 14:23:35 daemon info syslog: sending OFFER to IP:192.168.2.2, MAC:4c:b1:99:13:7a:26
Apr 9 14:23:35 daemon info syslog: sending OFFER to IP:192.168.2.2, MAC:4c:b1:99:13:7a:26
Apr 9 14:23:36 daemon info syslog: sending ACK to IP:192.168.2.2, MAC:4c:b1:99:13:7a:26
Apr 9 14:23:39 daemon info syslog: sending OFFER to IP:192.168.2.3, MAC:b8:ff:61:97:7b:e1
Apr 9 14:23:39 daemon info syslog: sending OFFER to IP:192.168.2.3, MAC:b8:ff:61:97:7b:e1
Apr 9 14:23:40 daemon info syslog: sending ACK to IP:192.168.2.3, MAC:b8:ff:61:97:7b:e1
Apr 9 14:32:02 daemon info syslog: sending OFFER to IP:192.168.2.4, MAC:b4:52:7e:16:31:cb
Apr 9 14:32:02 daemon info syslog: sending ACK to IP:192.168.2.4, MAC:b4:52:7e:16:31:cb
Apr 9 14:46:27 daemon info syslog: 192.168.2.1 belongs to someone, reserving it for 3600 seconds
Apr 9 14:46:30 daemon info syslog: sending OFFER to IP:192.168.2.2, MAC:5c:f9:38:8b:b6:c6
Apr 9 14:46:30 daemon info syslog: sending OFFER to IP:192.168.2.2, MAC:5c:f9:38:8b:b6:c6
Apr 9 14:46:31 daemon info syslog: sending ACK to IP:192.168.2.2, MAC:5c:f9:38:8b:b6:c6

There is no way that the only active dhcp server should hand out a lease (192.168.2.2) at 14:23:36 to one machine (MAC 4c:b1:99:13:7a:26) and then at 14:46:31 (23 minutes later) hand it out to a different machine (MAC 5c:f9:38:8b:b6:c6). The server's own default should have caused it to reserve 192.168.2.2 for 3600 seconds as can be seen for ip address 192.168.2.1.

I am still using the new firmware, but Billion really needs to sort out the dhcp server, one of the points that attracted me to this router was the ability to set up a guest network, but in fact it does not work. Having a guest network is simply leading to ip address conflicts.

Any comments gratefully received.

I've sent this forum thread link to our engineers, with also my findings, when I get reply I will drop it here