NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Orbi RB50 assigning IPs out of range, wrong connect types
Anybody have any ideas? I've had years of no-hassle use from my Orbi system, but I'm at wit's end with current troubles. I have an RBR50 with satelites RBS50 and RBW30, connected to Comcast upstream...
jimslade wrote:i'll give the test a go. Now I'm super curious what else could be handing out IP addresses?? Cannot imagine what else has a DHCP server?!?
It is 99.999% certain that the Orbi is not assigning IP addresses that begin with anything besides 192.168.1.
So, either:
- devices are configured with static IP's that begin with 172, or
- some other DHCP server is giving out these addresses
You would probably remember assigning static IP's, so my money is on another DHCP server. Likely culprits include NAS servers and media devices. Some smart speaker systems attempt to network themselves.
I positively love capturing packets and looking at them with Wireshark, which puts me squarely in the uber nerd category.
Another simplistic question is, "what has been added to the network since things were fine?"
good catch, yes was so frustrated i didn't even notice i dropped the '1'. indeed... orbi is at 192.168.1.1, and my reserved range is 192.168.1.2 to 192.168.1.9. Dynamic starts at x.x.x.10.
i'll give the test a go. Now I'm super curious what else could be handing out IP addresses?? Cannot imagine what else has a DHCP server?!?
jimslade wrote:i'll give the test a go. Now I'm super curious what else could be handing out IP addresses?? Cannot imagine what else has a DHCP server?!?
It is 99.999% certain that the Orbi is not assigning IP addresses that begin with anything besides 192.168.1.
So, either:
- devices are configured with static IP's that begin with 172, or
- some other DHCP server is giving out these addresses
You would probably remember assigning static IP's, so my money is on another DHCP server. Likely culprits include NAS servers and media devices. Some smart speaker systems attempt to network themselves.
I positively love capturing packets and looking at them with Wireshark, which puts me squarely in the uber nerd category.
Another simplistic question is, "what has been added to the network since things were fine?"
CrimpOn.....THANK YOU. You helped me solve the issue.
TL/DR: It was my new Ooma Telo which we installed a couple months ago. It has a DHCP service, which can be switched off if you connect to the unit directly.
So, I tried Wireshark but couldn't get it installed.... had issues with Visual C++ Redistrib and was pointing me to some Win7 KBs. Tried doing some updates but couldn't get it to install. Geekery for another day...
Giving up on wireshark, I turned off DHCP on Orbi anyway and all devices came back with the 172.x.x.x cancer. :smileysad: I then realized that 172.27.35.1 was the Ooma. After years of trying to get wifey to give up our landline I finally succeeded a couple months ago and installed Ooma. Since then Ooma has been handing out IP addresses when things bounced.
(As an aside, I should have done a client-side static IP on my main desktop prior to turning off DHCP on Orbi.... when I switched off Orbi's DHCP I lost locat access to Orbi and had to use remote to get back in and turn it back on. Was a scary couple minutes thinking I'd blocked myself out of my network.)
Anyway, so by leaving Ooma unplugged and bouncing Orbi, everything was back on 192.x.x.x . I then did a direct-connect to Ooma to turn off DHCP. I think this solves the problem. :smileyvery-happy:And in retrospect it totally makes sense... when someone's device was unlucky enough to get a 172 Ooma address, it was essentially being routed through Ooma, which explains why family members would complain of intermitent slow devices. Ooma is slow and adds a hop compared to Orbi. I was forgetting/re-adding devices to my network, which was really just re-entering them into the IP lottery to see if they got a 192 or a 172 address.
I'm now trying to set up a static route per this configuration: https://forums.ooma.com/viewtopic.php?f=6&t=1355&p=8647#p8647... so I can get to the Ooma admin pages. I have a static 192 IP set for Ooma, and am trying to forward to 172.27.35.1 but Orbi saves the 172.27.35.1 address as 172.27.35.0; not sure why . This is just bonus round.... the problem is solved and I don't expect to have disappearing/malfunctioning devices due to Ooma's IPs again.
Thank you CrimpOn !!! Netgear should have a tip jar... I would have not solved this without your help.
jimslade wrote:
I'm now trying to set up a static route per this configuration: https://forums.ooma.com/viewtopic.php?f=6&t=1355&p=8647#p8647... so I can get to the Ooma admin pages. I have a static 192 IP set for Ooma, and am trying to forward to 172.27.35.1 but Orbi saves the 172.27.35.1 address as 172.27.35.0; not sure why . This is just bonus round.... the problem is solved and I don't expect to have disappearing/malfunctioning devices due to Ooma's IPs again.That link gives the impression that the Ooma web page is available through both the WAN and LAN ports.
Have you tried pointing a web browser at the 192.168 IP address?
CrimpOn wrote:That link gives the impression that the Ooma web page is available through both the WAN and LAN ports.
Have you tried pointing a web browser at the 192.168 IP address?
Yes, tried but it isn't assigning that way.
Ooma still shows at 172.27.35.1 in the Orbi device list. I'm guessing that IP is set on the device side (I'll have to go connect to it again to see how that's set). Assuming that's true, I don't know what happens to the service if I try to change that or even if that is possible.
Orbi's static route won't save as 192.168.1.8 -> 172.27.35.1..... it saves as 192.168.1.8 -> 172.27.35.0... but of course 172.27.35.0 doesn't exist. I tried setting up the rule with Ooma disconnected (thinking maybe Orbi didn't like setting up static routes with existing devices connected) but Orbi still didn't like the rule and saved as 192.168.1.8 -> 172.27.35.0.
I can't ping neither 192.168.1.8 nor 172.27.35.1
