I have a SXR80 modem as well as a SXS80 satellite mesh system. Everything was working fine until a slight power outage happened and all of my IoT devices restarted. Of my 30 light switches, 3 connected back without a problem. I had the same problem in the past, and it was suggested I assign static IPs to everyone on my IoT VLAN, which I did. Looking at my connected devices, I can see a bunch of the devices connecting with correct IP addresses (192.168.30.xxx). But I have around 35 different IoT devices that show as being connected to the modem and satellite with the IP of 192.168.1.80. I don't have an IP range set for 192.168.1.xxx at all. I have no other DHCP servers besides the Orbi. Any idea how I could force those devices to connect on the correct VLAN? I am on firmware version V4.2.3.102.
I've already rebooted the modem, satellite, and a few of the devices, but they still show as being connected with the IP of 192.168.1.80.
You can see the static IPs are set for these devices:
I have a SXR80 modemrouter as well as a SXS80 satellite mesh system.
Just a tiny correction: The SRX80 router is connected to an Internet Service Provider (ISP) cable modem or Optical Network Terminator (ONT). It is itself a combination router/WiFi unit.
I had the same problem in the past, and it was suggested I assign static IPs to everyone on my IoT VLAN, which I did. Looking at my connected devices, I can see a bunch of the devices connecting with correct IP addresses (192.168.30.xxx)
Reserving (assigning) IP addresses is a common practice. (I assign IPs to every device that is more or less permanent on the network: desktops, televisions, printers, cameras, light switches, etc. Only truly transient devices are assigned IPs from the DHCP 'pool'.) Any memory of how this problem was resolved the last time?
I would want to confirm that these devices are receiving DHCP assignments from the router, but this is not trivial with WiFi devices. It would mean capturing WiFi on the IoT network as a device is powered up and examining the DHCP packets.
One tactic might be:
disable the IoT network
power the router and satellite off
boot up only the router.
let the network stabilize and verify that none of the IoT devices have connected.
Yes, the router sits behind a modem that has had its DHCP turned off, and its WIFI turned off.
The different LAN settings are such:
LAN1 is 192.168.0.xxx. DHCP Range of 192.168.0.21 - 253
LAN2 is 192.168.20.xxx. DHCP Range of 192.168.20.2 - 254
LAN3 is 192.168.30.xxx. DHCP Range of 192.168.30.120 - 254
LAN4 is 192.168.40.xxx. DHCP Range of 192.168.40.2 - 254
Last time the problem I had was nothing was being picked up at all. All of my devices refused to connect to the network. I shut everything down for an hour (it was like little house on the prairie around here!). After the hour I turned on the modem and waited 10 minutes. Then the router/satellite, waited 10 minutes. Then each computer, waited 10 minutes. Then one by one turning on or restarting each IoT device until everything was online. Took about 3 - 4 hours in total. That's when the suggestion of setting static IPs for everything came up.
This time, things are being seen, but a lot of the IoT devices are being picked up on that 192.168.1.80 IP address. I will try your suggestion tonight after everyone has gone to bed since the computers and TVs are connecting without a problem.
Yes, the router sits behind a modem that has had its DHCP turned off, and its WIFI turned off.
One thing to keep in mind is that a device which features DHCP and WiFi is a combination modem/router/wifi (the sort of device that ISPs almost always want to install because that leaves the customer with a fully functioning connection without requiring any equipment from the customer.
This can create a "Double NAT" situation which can result in specific applications not working correctly. Things like forwarding internet ports to internal servers, providing VPN access to the LAN from the internet, and certain types of internet gaming. The net is rife with explanations of Double NAT, including this one from Netgear:
My guess is that the LAN1 setting was changed was:
You just like this setting?
because the ISP router assigned an IP address beginning with 192.168.1.x to the Orbi WAN port and the Orbi changed the default setting to this, rather than 192.168.1.x? If this is indeed the case, then the ISP router may actually be assigning DHCP addresses in the 192.168.1.x range
I changed the default IP range of LAN1. My fingers are use to typing 192.168.0.xxx for so many things, just made life easier for me (until now).
Even if the AT&T modem was sending DHCP addresses out, that wouldn't explain why there are 30+ devices with a 192.168.1.80 IP address. All devices have different MAC addresses so the DHCP server wouldn't be able to set another device with the same IP. I double checked the AT&T modem for DHCP leases. Currently 0 DHCP leases.
As a side note, is there anyway to force removal/DHCP lease renewal? I see a way to block devices once connected, but no way to force them to renew their lease.
What does not make sense, of course, is how this could have happened in the first place. There is no DHCP server assigning IPs in the 192.168.1.x subnet, yet all these devices are connected to the Orbi and claiming to be 192.168.1.80. The Orbi process which populates the Attached Devices table may be a bit "brain dead." i.e. "This device says it is 192.168.1.1, so that's what I put into the table."
Being a bit of a computer nerd, I would probably set up Wireshark to capture the Ethernet port on a computer attached to the Orbi, open a command window, and attempt to ping 192.168.1.80. This should cause the computer to issue an ARP command to discover which MAC address has 192.168.1.80 and Wireshark should capture all of those devices responding, "This is my IP address"
As a side note, is there anyway to force removal/DHCP lease renewal? I see a way to block devices once connected, but no way to force them to renew their lease.
Really good question. I see that this question has come up before:
https://serverfault.com/questions/285048/dhcp-server-tell-clients-to-renew-lease That would almost certainly work with devices connected directly via Ethernet. WiFi is a bit different. My guess is that disabling the WiFi SSID would cause devices which are connected to sense that the connection has 'gone away' and go into discovery mode. When the SSID reappears, the device might go through the typical sequence:
Probe Request.
Prove Response.
Authentication Request.
Authenticaion Response.
Association Request.
Association Response.
DHCP Request.
DHCP Response.
The only way to validate this hypothesis would be to disable, then re-enable the IoT network (SSID).
In case many devices on a known working VLAN are getting this single faux IP address (complete in the dark to me), I suggest to head out for Netgear assistance. Be ready to enable the remote diagnostics port.... @MrJoshW please
let the network stabilize and verify that none of the IoT devices have connected.
enable the IoT network
My goodness, what a mess!
I tried this last night. No luck. After turning everything back on and getting the IoT network back up, the 192.168.1.80 devices came back. I've tried every different combination of disabling network, disabling DHCP, removing IP addresses from the pool...you name it, no luck. For fun I decided to try to add my cell phone to this network. It tried for a little bit and then failed with the error "unable to get an IP from the server". I tried to add my laptop as well, it got an IPv6 address, but no actual IPv4 (169.254.89.58 with a subnet of 255.255.0.0). Not sure if that helps anything.
In case many devices on a known working VLAN are getting this single faux IP address (complete in the dark to me), I suggest to head out for Netgear assistance. Be ready to enable the remote diagnostics port.... @MrJoshW please
I feel this is my only choice at this point, but since I've had the setup for more than 90 days, I no longer have a support contract. I'm not going to be spending another $150.00 to buy a one year contract for something that their software has broken. I'd rather buy a whole new setup or setup a Raspberry Pi to do my DHCP and to hell with VLANs.
In case many devices on a known working VLAN are getting this single faux IP address (complete in the dark to me), I suggest to head out for Netgear assistance. Be ready to enable the remote diagnostics port.... @MrJoshW please
What a hoot! According to the User Manual, the SXR80 includes the Remote Management capability that Netgear removed from the residential Orbi products. As I had assumed all along, that was not a "security improvement", but simply a way to make customers more dependent on Anywhere Access.
I'd rather buy a whole new setup or setup a Raspberry Pi to do my DHCP and to hell with VLANs.
The customer is not required to separate devices into VLANs. All devices can be placed in the default LAN1 and the other LANs disabled. Those of us who bought the original Orbi in 2016 have only one LAN and get along fine.
I tried to add my laptop as well, it got an IPv6 address, but no actual IPv4 (169.254.89.58 with a subnet of 255.255.0.0). Not sure if that helps anything.
This indicates that the laptop failed to get an IP address from the network. 169.254 IP addresses are known as Link Local addresses, created by the laptop itself. (both the IPv4 and IPv6 addresses) Nothing came from a DHCP server.
I tried to add my laptop as well, it got an IPv6 address, but no actual IPv4 (169.254.89.58 with a subnet of 255.255.0.0). Not sure if that helps anything.
This indicates that the laptop failed to get an IP address from the network. 169.254 IP addresses are known as Link Local addresses, created by the laptop itself. (both the IPv4 and IPv6 addresses) Nothing came from a DHCP server.
The laptop was Wireless, as was the phone. Only the IOT LAN (LAN3 - 192.168.30.xxx) is having this problem. I can connect to the LAN1 wifi without a problem. It gets an IP address and connects to the network. I can also connect to the Guest LAN (LAN4 192.168.40.xxx) without a problem.
Reviewing the comments it sounds like the issue is only happening on VLAN 30 correct? When connecting your phone to the SSID it did not receive an IP address when connecting to it. Try this for me:
-Can you disable the DHCP on VLAN 30/LAN 3 and re-enable? I want to see if restarting the DHCP on the this VLAN has any change. -Also looking at your screenshot I see a starting IP range of 120-254. Are you able to change it to 1-254 and then connect with your phone? Does it now obtain an IP address from the DHCP?
-Can you disable the DHCP on VLAN 30/LAN 3 and re-enable? I want to see if restarting the DHCP on the this VLAN has any change.
I tried this yesterday...or day before yesterday. I can't even remember at this point. "I've tried every different combination of disabling network, disabling DHCP, removing IP addresses from the pool...you name it, no luck."
@MrJoshW wrote: -Also looking at your screenshot I see a starting IP range of 120-254. Are you able to change it to 1-254 and then connect with your phone? Does it now obtain an IP address from the DHCP?
Yes, I reset it back to 1-254 with the same results. No DHCP being handed out. My phone and laptop failed to get IP addresses. If i join LAN1 or LAN2, or LAN4 they join without a problem.
I have an LCD info screen that has been trying to connect to this VLAN for two hours. The MAC address is set to a static IP, so it shouldn't even be trying to DHCP. This is just one device. Many other IoT items are trying to connect and fail.
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:10:39
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:09:17
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:08:40
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:08:23
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:08:21
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:07:30
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:06:07
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:05:29
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:04:15
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:03:38
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:01:50
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:01:42
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 14:01:33
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:59:33
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:58:55
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:57:12
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:56:27
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:56:21
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:56:17
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:56:16
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:55:39
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:55:23
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:54:16
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:53:39
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:52:24
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:51:01
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:50:25
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:49:02
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:48:24
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:47:01
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:46:01
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:45:37
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:45:33
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:45:31
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:44:38
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:44:01
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:42:00
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:41:23
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:40:00
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:39:23
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:38:45
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:38:01
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:37:23
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:36:01
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:35:23
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:34:12
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:33:44
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:33:36
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:33:30
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:32:57
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:32:20
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:31:43
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:31:06
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:29:39
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:29:01
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:28:59
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:26:58
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:25:34
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:24:57
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:24:19
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:24:04
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:23:24
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:23:23
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:23:07
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:21:33
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:21:25
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:21:21
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:21:20
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:21:10
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:19:48
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:19:11
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:18:34
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:17:11
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:16:32
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:15:59
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:14:36
[DHCP IP: 192.168.30.101] to MAC address xx:xx:xx:xx:xx:xx
Monday
6/5/2023
2023 13:14:35
I removed the static reservation and reboot the router again. The same item tried to connect a few times and failed. This time there was no date/time in the logs. But I can assure you, it was about 2 minutes after the reboot I grabbed the logs.
I have an LCD info screen that has been trying to connect to this VLAN for two hours. The MAC address is set to a static IP, so it shouldn't even be trying to DHCP. This is just one device. Many other IoT items are trying to connect and fail.
Would it be correct to assume that all of those log entries display the MAC address of the LCD screen? (I understand the paranoia about revealing private information, although the MAC address of some IoT device would seem to be on the low end of the security scale.)
My understanding matches yours: When a device is set with a static IP on the device itself, it is not supposed to issue a DHCP request.
This is not one of those devices that randomize the hardware MAC address when connecting to WiFi networks?
When everything else fails, the last resort is the horrid Factory Reset. The theory being that flushing the system will eliminate whatever garbage has crept in. We all hate doing this. (In my case, a full setup from scratch takes over two hours of tedious - and error prone - data entry.)
An alternative that has actually worked for me is a soft Factory Reset:
Save a copy of the configuration
Power off the satellites
Get out the paperclip and reset to factory.
Using a computer connected to the router, begin the setup.
Ignore all attempts to get you to do anything:
Ignore the advice to use the Orbi 'app' Select that tiny note at the bottom of the screen, "I do not have a smart phone." i.e. Lie. What I do is mutter, "I Do have a f***&( smartphone and I'm not going to use it."
Do not enable Parental Controls
Do not enable Armor
When it jumps off to Netgear to register the product, go back to the Orbi web interface.
Definitely to not change the WiFi credentials from the default.
You may have to change the web admin password because it won't let you past that step unless you do.
Finally, reach a page that offers the choice:
Continue manual set up, or
Load a saved configuration.
Load the saved configuration
The router will reboot
In two minutes, power on the satellites
Everything comes back (except maybe the garbage).
I have done this entire process (including the swearing) in less than 15 minutes. On at least one occasion, the issue disappeared.
Would it be correct to assume that all of those log entries display the MAC address of the LCD screen? (I understand the paranoia about revealing private information, although the MAC address of some IoT device would seem to be on the low end of the security scale.)
Yes, you are correct. It does show the MAC address, I did remove them.
This is not one of those devices that randomize the hardware MAC address when connecting to WiFi networks?
No, its the same MAC address. As with other devices who are having the same problem. Trying over and over and over again to connect, only to fail even though the GUI shows it being connected with an IP address.
When everything else fails, the last resort is the horrid Factory Reset. The theory being that flushing the system will eliminate whatever garbage has crept in. We all hate doing this. (In my case, a full setup from scratch takes over two hours of tedious - and error prone - data entry.)
An alternative that has actually worked for me is a soft Factory Reset:
This might be my last resort and will need to happen over a weekend. Thank you for all of your help up to this point.
No, its the same MAC address. As with other devices who are having the same problem. Trying over and over and over again to connect, only to fail even though the GUI shows it being connected with an IP address.
Not random in the sense of changing every DHCP attempt, but random in the sense that it is not the same as the physical hardware MAC address.
I am still grappling with the issue of what would cause a device set to a static IP (plus subnet mask, gateway IP, DNS IP) to issue dhcp requests and then persist in ignoring them.
