DHCP reservations not working

---

OrbiPhilip wrote:

One problem that the Orbi system seems to have is the lack of ability to manually drop a DHCP entry from the table. As such, any device getting a DHCP address will continue leasing that address until the router is rebooted. 

This is especially problematic when you give a device (including the Satellites) a DHCP reservation for an address other than the one auto-assigned. Anytime a given MAC is added to the reservations list, it should be dropped from the database if the IP changes.

---

I concur that this appears to be what happens.  I do not know if it is a coding issue or if Netgear is following some "industry standard behavior" that I have yet to find.  To MY mind, when the administrator creates an IP reservation for a MAC address, the system should immediately force the device to that IP address by sending  A brief search for DHCP standards documents reveals:

RFC 1541 (1993) https://tools.ietf.org/html/rfc1541 

RFC 2131 (1997) https://tools.ietf.org/html/rfc2131 

RFC 3203 (2001) https://www.ietf.org/rfc/rfc3203.txt 

This document defines extensions to DHCP (Dynamic Host Configuration
   Protocol) to allow dynamic reconfiguration of a single host triggered
   by the DHCP server (e.g., a new IP address and/or local configuration
   parameters).  This is achieved by introducing a unicast FORCERENEW
   message which forces the client to the RENEW state.  

In the "Linux world" once modules are coded, there is little interest in reworking them.  My GUESS is that the DHCP code in OpenWRT (the basis for Orbi) simply does not incorporate this RFC.

Every time this phenomenon "bites me", it is a real chore to restore order.  I keep an old cell phone for this purpose.

• Turn off the offending device that has picked up the wrong IP.
• Go into the LAN web page and assign that wrong IP to the cell phone.
• Power up the cell phone and connect.  Now the cell phone is on that IP because when Orbi ARP'd, nobody said, "Hey, that's me."
• Now, power up the offending device.  It asks for an IP.  Orbi sees that it doesn't have one.  Orbi gives it the IP out of the table.
• Cell phone goes back in drawer until next time.

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. 

My RBR50 does not reboot when I add or remove DHCP Address Reservations (using v2.5.1.8 firmware) unless I also click Apply.  The Address Reservation table is populated with the Add/Edit buttons even without clicking Apply.  I have seen where sometimes the reservation does not work though until the router is rebooted.  Perhaps this is because I forgot to click "Apply".

---

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. 

---

Yes after you ADD the reservation, you have to click Apply. :smileywink: This is when the RBR will reboot itself to make the change. 

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.

Blanca_O 

Christian_R 

---

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.