DHCP Static reservations are no longer working
Recently I noticed that some of my IP camera's and servers stopped responding.
Upon investigation, it turns out that they suddenly received a different IP address. However, I have set static DHCP reservations for all of these devices but ever since the latest firmware these devices are handed out different IP addresses.
For example:
My backyard camera:
And frontyard camera:
They've had these fixed IP address since forever, but they recently received a totally different IP:
This obviously causes issues for my NVR and Home Assistant which use IP addresses rather than hostnames. From the DHCP Log for my backyard camera:
For the device that should recieve IP .14, I'm also seeing this in the logs. The DHCP server rejects the .16 request, but then hands it out anyway:
So on the 18th of October it stopped giving the proper DHCP static and instead gave the next free address in the DHCP scope. I'm running the Omada Controller in Docker, so it could be that there was a firmware update that day. I'm currently running Controller version 5.14.32.2 (Stable). I can not downgrade to 5.14.26.1 to test.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
@Clive_A No firmware updates or reboots at that time.
It's resolved now anyway. I'm going to keep an eye on it, and if it happens again I'll contact support with a debug log.
- Copy Link
- Report Inappropriate Content
Note that I also have IP-MAC Binding enabled for all my DHCP Static reservations. The MAC addresses are correct (obviously, they haven´t changed.)
The reservations are also not in use. Rebooting or reconnecting the devices still does not give them the correct IP address.
And it's not just my cameras either. Every single device on my network that has a DHCP Static address is hapily ignoring it and getting an entirely different address. My home PC should have 192.168.10.30, but instead receives 192.168.10.13. Same for my printer, same for my AV receiver,... Everything. Which makes managing my network almost impossible if everything keeps changing.
So it looks like the latest firmware has downright broken DHCP reservations.
- Copy Link
- Report Inappropriate Content
Looking at the CLI configuration:
(config)#show dhcp server
---------------------------------------------------------------------
client name:TXXXX
bind:0
interface:lan
macaddr:10-2C-B1-XX-XX-XX
ipaddr:192.168.50.17
leasetime:Permanent
---------------------------------------------------------------------
It's showing a Permanent leastime for the wrong IP address. It should be .15 but it's permanently leased .17 for some reason. This is probably why a reboot doesn´t fix the issue.
- Copy Link
- Report Inappropriate Content
Hi @Matva
Thanks for posting in our business forum.
Matva wrote
Looking at the CLI configuration:
(config)#show dhcp server
---------------------------------------------------------------------
client name:TXXXX
bind:0
interface:lan
macaddr:10-2C-B1-XX-XX-XX
ipaddr:192.168.50.17
leasetime:Permanent
---------------------------------------------------------------------
It's showing a Permanent leastime for the wrong IP address. It should be .15 but it's permanently leased .17 for some reason. This is probably why a reboot doesn´t fix the issue.
Have you tried to reboot the system?
Also, can you show all the DHCP binding, Has anything been added or changed lately? New device added to the network?
Did you upgrade the controller? Upgrade anything? Docker is not an official system and we don't have any support for it. Cannot determine if this is a controller problem or the router.
- Copy Link
- Report Inappropriate Content
I had rebooted the devices themselves, the controller, and the access points to no avail.
Rebooting the router seems to have resolved the issue for now.
I can't be 100% certain what could be the trigger for this, but I can pinpoint the exact moment it started going wrong:
The DHCP server suddenly rejected the .14 address that the devices had always had and started handing out .16. From this point onwards, all other DHCP Reservations were ignored and everything that had a DHCP Reservation received a different IP address. This particular device does seem to be pretty agressive with the DHCP requests though... Once every 10 minutes. Could it have caused a memory leak or something?
The hardware is set to auto-update on Sundays, and none of my other systems are set to auto-update or reboot around that time.
- Copy Link
- Report Inappropriate Content
Hi @Matva
Thanks for posting in our business forum.
Matva wrote
I had rebooted the devices themselves, the controller, and the access points to no avail.
Rebooting the router seems to have resolved the issue for now.
I can't be 100% certain what could be the trigger for this, but I can pinpoint the exact moment it started going wrong:
The DHCP server suddenly rejected the .14 address that the devices had always had and started handing out .16. From this point onwards, all other DHCP Reservations were ignored and everything that had a DHCP Reservation received a different IP address. This particular device does seem to be pretty agressive with the DHCP requests though... Once every 10 minutes. Could it have caused a memory leak or something?
The hardware is set to auto-update on Sundays, and none of my other systems are set to auto-update or reboot around that time.
With the information provided, it is hard to tell what was wrong. Might need a syslog or debug log.
Was there a firmware upgrade?
- Copy Link
- Report Inappropriate Content
@Clive_A No firmware updates or reboots at that time.
It's resolved now anyway. I'm going to keep an eye on it, and if it happens again I'll contact support with a debug log.
- Copy Link
- Report Inappropriate Content
I have the same issue as the above.
I have ER707 with firmware 1.2.3 with Omada controller version 5.14.32.3.
All wired reservations are being completely ignored. Rebooting the ER707 does nothing. Rebooting Omada Controller does nothing. Rebooting the devices does nothing.
At a broader macro level, there seems to be ongoing problems with Omada DHCP servers doing this for several years now across different versions of gateways etc. Is there a systemic bug that is not being addressed properly?
As a note, I'm only seeing this to be an issue on wired devices, not wireless devices.
Edit: I just downgraded to 1.2.2 in the hope it fixes the problem.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 163
Replies: 7
Voters 0
No one has voted for it yet.