NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
DHCP reservations not working
Yesterday I added a raspberry pi to my network (running Nagios/NEMS). Every time it rebooted it took the next IP in sequence. That shouldn't happen... Instead of fighting with it, I created a reserva...
I likewise had this issue, and a reboot of the router corrected it. I reported the issue to NG support, and they claimed the system firmware is "glitching" causing this. They admit that the firmware is still a bit buggy with v2.5.1.8 on the RBR50, but have no ETA on when they will have a stable and reliable mesh network.
When I modify the LAN reservation table:
- Clicking Add, Modify, or Delete takes place immediately.
(Whether the table is actually updated is another question. My guess is "maybe". I suspect that the memory table is updated, but the permanent table on "disk" (Ha) is not updated until "Apply". If no "Apply", then a reboot will reload the previous entries and the revision will be lost. - Clicking "Apply" causes that "Please wait a moment" message to appear for about 1min 45 seconds.
(I would love to know what the heck the Orbi is doing during these agonizing "Please wait..." episodes.) - Many of my devices appear to renew IP adddresses immediately after the Apply, but not all of them.
- The Orbi definitely does not "reboot". (Log file clears as part of a reboot, and my log does not clear or show any reboot message.)
One of the techniques commonly used to manage revising DHCP tables is not possible on the Orbi. At my work, we would set the DHCP lease time to five minutes before reallocating IP blocks to different buildings/user groups. Since our regular DHCP lease was 24 hours, that meant that every device on the network would begin renewing at 2:30 intervals within 12 hours. So, we would wait 12 hours (middle of the night), then change all the block IP allocations, wait about 20 minutes for it to "take", and then change the lease time back to 24 hours. Since Orbi does not have a (user accessible) way to change the DHCP lease time, this method is not open to ordinary users. (There is probably a telnet hack such as changing dhcpc_lease_time=86400 to a different value.)
Even though the IP reservation on the Orbi has taken effect, some devices may need to be rebooted so that there IP address tables can release and renew and be updated. Some devices don't change IPs automatically when the router changes it. They need to be rebooted. I've seen this with some of my devices. Mostly my ATT Microcell. I wish I could set a static on it. :smileyfrustrated:
What OrbiPhilip and I are saying is that simply rebooting the device does not make it change IP settings. One of the interesting features of DHCP is that the DHCP server cannot detect that a device has "gone offline." It simply might not be sending any packets right now. The lease, however, is still good. Reboot, and the Orbi just gives it the same lease it had.
Perhaps waiting 24 hours before powering up the device would result in a change of IP, but I lack the patience to experiment with it.
There are lots of ways Netgear could provide the tools to remedy this situation. However, on a scale of 1-100, this probably ranks -99 onthe priority list.
I would make contact with NG support and have them look into this. Not the first time DHCP problems have been seen. :smileywink:
IM sure there is room for improvements.
FURRYe38 wrote:I would make contact with NG support and have them look into this. Not the first time DHCP problems have been seen. :smileywink:
IM sure there is room for improvements.
Bravo! Every time I think you can't possibly post more vacuous and trite comments you lower the bar.
FURRYe38 wrote:I notice that when I do any IP address reservations, Add then save then Apply, the RBR reboots by default. So this should take effect and should clear out any unused IPs.
That is not normal behavior, nor should it be.
And what can we do about it here in the forums? This needs to be addressed at NG, not here. Duh.
Talk to NG about it. Let them know so they can fix it so it works for you.
We know it's bad behavior. However talking till we are blue in the face won't fix it. The more we contact NG about, the more they should or will fix the problem.
CrimpOn wrote:
What OrbiPhilip and I are saying is that simply rebooting the device does not make it change IP settings. One of the interesting features of DHCP is that the DHCP server cannot detect that a device has "gone offline." It simply might not be sending any packets right now. The lease, however, is still good. Reboot, and the Orbi just gives it the same lease it had.
Correct, and that is a byproduct of an ORBI bug. Creating a reservation for a given MAC should purge the DHCP table of any entry associated with that MAC. Then when the device reboots (or renews) it will be assigned the new IP.
Orbi appears to be populating the reservation table without updating the DHCP lease table. Then, for reasons unknown, they consult the lease table BEFORE the reservations table. Fixing this order might fix the problem as the table mgmt object should allow the table to contain duplicate entries.There are lots of ways Netgear could provide the tools to remedy this situation. However, on a scale of 1-100, this probably ranks -99 onthe priority list.
They could do what Microsoft does and display the table and allow manual deletes. That could simply be added as a button on "Attached devices". Probably a hours coding, max.
The lack of priority for basic network functionaly is a seriouos problem with netgear products. Unfortunately, they are far more concerned with inserting code to detect and prevent manually splitting the SSIDs. {PALM}FURRYe38 wrote:
And what can we do about it here in the forums? This needs to be addressed at NG, not here. Duh. Talk to NG about it. Let them know so they can fix it so it works for you.
Please stop crapping up the forum with you vacuous (and prolific) tripe. We're here to discuss problems, not attend a taping of "The Furrye38" show.
Discuss away. Just saying, contact NG support. Get them involved. They need to know about this. Not here to argue.
Who talks like that. LOL
I'll be posted as I see fit.Good Luck.
FURRYe38 wrote:Discuss away. Just saying, contact NG support. Get them involved. They need to know about this. I'll be posted as I see fit. Good Luck.
If they are not following this forum their executive leadership is clueless.
And yes, we are all aware that you will post your inane nonsense as you see fit. Anyone who's been here any length of time has observed you littering the forum with it since your very first day, when you spammed the exact same post dozens (if not hundreds) of times.If you think that. Thats fine. My record shows other wise.
Been long time known that NG engineering doesn't follow forums. Moderators maybe. Again, users need to let NG know is all i'm saying.
Good Luck in your endeavours.
FURRYe38 wrote:If you think that. Thats fine. My record shows other wise.
Your record shows spamming and useless drivel. Maybe 5% useful content, if I'm being very generous.And we see your history is nothing but complaining and badgering other users. Thats very helpful. 100% and i'm being generous.
BoilerPlate wrote:And we see your history is nothing but complaining and badgering other users. Thats very helpful. 100% and i'm being generous.
Oh really?
OrbiPhilip post stats
--------------------------
Total Messages Posted - 96
Total Kudos Received - 69 (71.9%)
And for comparison:
BoilerPlate - 20.8%
Furrye38 - 9.5%Apparently Orbi makes very little effort to maintain lease history and/or attempt to reissue the same addresses. Since employing Nagios a week ago I've watched two devices change IP addresses without explanation. This should not be happening since we aren't even remotely close to the number of addresses allocated.
Note: If you are running TiVo, you will need to create reservations for all source (i.e. DVR) devices on your network. If a source device changes addresses it screws up the TiVo beacon process (Bonjour/zeroconf) and you will need to repeat guided setup on all remote (i.e. mini) devices.
