ORBI not properly associating static IP

---

6old3nra1n wrote:

How effing annoying...

---

There could be some strange mismatch between the PC's DHCP request and the Orbi.

I know what we want to happen.  The PC does a DHCP request, the Orbi first looks at the LAN reservation table, finds the IP, checks that it is not in use already, and then offers it to the PC.

This appears not to be what actually happens.  I have verified situations where a device *somehow* got an IP that I did not want it to have, and no matter how many times I restarted the device, the Orbi would say, "you already have this one, so keep it."  My (tedious) workaround was to turn off the device, configure my laptop with a static IP that matches the bad one, and then when I powered up the device, the Orbi said, "You are asking for an IP that is already in use.  Oh, look, the LAN reservation table says I should give you this one that is not in use."

This new wrinkle that seems to be happening to you is the device asks for an IP and the Orbi says, "that one is already taken, but the next one in the DHCP pool is available.  Here."

The only way I can see to investigate this is to capture the Orbi LAN traffic (an option on the debug screen) and use Wireshark to look at the DHCP conversations.

I LOVE doing this kind of stuff, and I don't have any work that needs to get done or people hassling me about "Why isn't the internet working."

I would take the easy way out.

• Give the device a static IP (on the device)
• Create a LAN reservation on the Orbi that is outside the DHCP pool
• After this works for a couple of days, experiment with changing the PC back to DHCP

The other alternative is to put the Orbi in AP mode and have the ISP device handle IP assignments.  It probably has the same basic structure for assigning IP's to be given out with DHCP.  Maybe the PC will "play nice" with the ISP router.

So you guys won't believe this -- I decided to change the range of the DHCP-assigned LAN IP addresses from [192.168.1.2 to 192.168.1.254] to [192.168.1.2 to 192.168.1.100].

In my previous address reservation attempts, I set the reserved IP to 192.168.1.25 ...26, 27, etc. Then I set it to something really far out within the IP range, namely 192.168.1.100. Still within the original range, and still within the new range.

So technically nothing should change, right? But wait, there's more! When I changed the range, clearly the router did "something" and reset all connections. I noticed that even my router page was no longer accessible (for the time being). So when I simply typed "ipconfig" (without releasing or renewing anything) into my PC, it showed 192.168.1.100!

It's almost as if changing the DHCP-assigned IP range caused the system to start from scratch (perhaps the DHCP table itself got rebuilt) and therefore assigned my PC the correct reserved IP address of 192.168.1.100.

The question now is -- if I change the address reservation to another IP or if I reserve another IP for another device, will it work? Or will I have to "reset" the DHCP by changing the IP range again... I'm scared to try.. haha..

---

6old3nra1n wrote:

So you guys won't believe this -- I decided to change the range of the DHCP-assigned LAN IP addresses from [192.168.1.2 to 192.168.1.254] to [192.168.1.2 to 192.168.1.100].

 

In my previous address reservation attempts, I set the reserved IP to 192.168.1.25 ...26, 27, etc. Then I set it to something really far out within the IP range, namely 192.168.1.100. Still within the original range, and still within the new range.

 

So technically nothing should change, right? But wait, there's more! When I changed the range, clearly the router did "something" and reset all connections. I noticed that even my router page was no longer accessible (for the time being). So when I simply typed "ipconfig" (without releasing or renewing anything) into my PC, it showed 192.168.1.100!

 

It's almost as if changing the DHCP-assigned IP range caused the system to start from scratch (perhaps the DHCP table itself got rebuilt) and therefore assigned my PC the correct reserved IP address of 192.168.1.100.

 

The question now is -- if I change the address reservation to another IP or if I reserve another IP for another device, will it work? Or will I have to "reset" the DHCP by changing the IP range again... I'm scared to try.. haha..

---

That really didn't do anything but reassign any IP addresses over 100 to 100 or below. Then it refreshed the IP table which could have corrected some issue. If it is working properly, changing a statically assigned IP address won't cause an issue, as the DHCP server will reserve the IP address and change the IP address of another device that previously had the reserved IP assigned to it.

This was my thought as well. Since I didn't have any devices using IPs greater than 100, then nothing really changed about them. I think the refresh of the DHCP table is what did the trick and allowed the address reservation to properly be applied. Thanks again for your help!

---

6old3nra1n wrote:

It's almost as if changing the DHCP-assigned IP range caused the system to start from scratch (perhaps the DHCP table itself got rebuilt) and therefore assigned my PC the correct reserved IP address of 192.168.1.100.

That's becuase you clicked apply at the top of the page which saves the changes you made and the table of DHCP reservations.

---

6old3nra1n wrote:

The question now is -- if I change the address reservation to another IP or if I reserve another IP for another device, will it work? Or will I have to "reset" the DHCP by changing the IP range again... I'm scared to try.. haha..

---

No, not unless you apply the changes once done.

Using 6old3nra1n's solution worked for me. I reduced the size of the dynamic DHCP pool to not include the IP's that I was statically assigning to individual devices. Like they experienced, I also observed the router seeming to reboot. So, my guess is that one of two things is happening:

1. The DHCP daemon in the router ignores any static IP assignment which falls within the dynamic pool, or
2. Changes to the DHCP configuration require that the DHCP daemon be restarted, and the web UI fails to do this when you just add static assignments, but it does do it when you change the dynamic IP range.

I guess the way to test this would be to either:

1. Change the dynamic IP range back to include the static assignments and reboot some of those statically-assigned devices. (if the devices lose their static IP's, then we have case #1 from above. If they don't, we have case #2)
2. Add a new static assignment outside of the dynamic range (if it works, then we have case #1 from above. If it doesn't, then we have case #2).

Lets remember that for "Static" IP addresses, these are configured and placed ON devcies themselves. So if static IP addressed devcies are being used and connected, then these static IP addressses need to be outside of the default DCHP IP address pool. For NG routers, NG defaults to max pool size, so users need to reduce the pool size to allow for static IP addresses to be used OUTSIDE of the IP address pool.

For IP Address "Revervations", these are set ON the Router for devices and these are always with in the DHCP IP address pool. 

Let's remember that the word "static" just means "not changing". Whether an IP is not changing because it is configured at the host or because the IP is reserverd for a specific MAC at the DHCP server, it would still be a "static IP". However, that leads to confusion, so I've tried to avoid that phraseology. In my post, I tried to be carefull to use the phrase "statically assigned" to refer to IP reservations on the DHCP server. If there's an accepted standard terminology to discriminate between those two, I'd love to hear it.

Cisco uses the term static DHCP.

I also see DHCP reservation used by vendors.

Your term of statically assigned seems equally fine.

I agree with FURRYe38 that static IP without any qualifier generally implies "set on the device itself".

It's not clear to me if the "problem is solved" and the discussion has moved on to semantics, or.....