Firmware V1.12.0.18 Discussion

Pulled this from a debug log on one of the sats

1173 root 244 S /usr/bin/detcable 2 RBS50
1393 root 256 S udhcpc -b -i br0 -h RBS50 -r 192.168.1.250 -N 0.0.0.0
1438 root 296 S /usr/sbin/net-scan
1452 root 268 S /usr/sbin/lld2d br0
1575 root 376 S /usr/sbin/uhttpd -h /www.satellite -r RBS50 -x /cgi-bin -t 60 -p 0.0.0.0:80 -C /etc/uhttpd.crt -K /etc/uhttpd.key -s 0.0.0.0:443

---

Traz_13 wrote:

IP conflicts are not ok behaviour no matter how you look at it. But here is the basic debug log from the Orbi router showing that it is storing conflicting IP/mac addresses for an Orbi Sat after the factory reset.

192.168.128.251 0x1 0x2 b0:b9:8a:64:f7:08 * br0
192.168.128.1 0x1 0x0 00:00:00:00:00:00 * eth0
192.168.128.18 0x1 0x2 08:66:98:ef:bc:27 * br0
192.168.128.67 0x1 0x2 38:aa:3c:d8:ce:42 * br0
192.168.128.37 0x1 0x2 dc:a9:04:88:45:18 * br0
192.168.128.83 0x1 0x2 70:f0:87:a8:54:63 * br0
192.168.128.53 0x1 0x2 34:d2:70:c4:43:e0 * br0
192.168.128.8 0x1 0x2 14:b3:1f:0a:50:d2 * br0
192.168.128.76 0x1 0x2 a0:99:9b:2f:a2:7d * br0
192.168.128.31 0x1 0x2 20:ab:37:57:80:72 * br0
192.168.128.5 0x1 0x2 14:b3:1f:0a:40:da * br0
192.168.128.24 0x1 0x2 8c:f5:a3:2d:83:b2 * br0
192.168.128.73 0x1 0x2 00:3e:e1:bd:fa:90 * br0
192.168.128.43 0x1 0x2 d4:61:9d:00:93:70 * br0
192.168.128.21 0x1 0x2 00:04:4b:79:71:59 * br0
192.168.128.14 0x1 0x2 ac:1f:6b:05:56:7e * br0
192.168.128.33 0x1 0x2 08:66:98:d9:0b:ed * br0
192.168.128.82 0x1 0x2 74:c6:3b:ed:9f:7f * br0
192.168.128.52 0x1 0x2 34:d2:70:a8:90:35 * br0
192.168.128.11 0x1 0x2 14:b3:1f:10:76:2f * br0
192.168.128.30 0x1 0x2 a0:8c:fd:53:98:ab * br0
192.168.128.79 0x1 0x2 d0:e1:40:92:22:b6 * br0
192.168.1.250 0x1 0x2 b0:b9:8a:64:f7:08 * br0

---

What conflict do you see here? I see two IP addresses listed for one MAC address. That is perfectly valid. What you cannot have is one IP address used by two MACS, but I don't see that here. 

Check my first post here for the IP conflicts... IP Conflicts are the default 192.168.1.250 even though the sats are statically assigned from the DHCP server to 192.168.128.251 to 192.168.128.253
https://community.netgear.com/t5/Orbi/Firmware-V1-12-0-18-Discussion/m-p/1338289#M11452

Hello hobbnet

Have you tried to enable beamforming and mumimo? Also have you tried to factory reset your device since the latest update?

DarrenM

Yes, DarrenM.  I called netgear customer support last night and they instructed me to do both of those things.  I'm still having frequent disconnects today however.

---

hobbnet wrote:

Yes, DarrenM.  I call netgear customer support last night and they instructed me to do both of those things.  I'm still having frequent disconnects today however.

---

Wow, widely varying results being reported here! After I gave up on getting the Orbi going in AP mode on the v1.11.x firmware, it is working fine in AP mode with the v1.12.x firmware. Nice and stable.

However, one thing that makes me unhappy is that not only can I not turn off 2.4GHz. wireless, it insists on operating with a 40MHz. wide channel on 2.4GHz. in my crowded neighborhood. So my unused 2.4GHz. signal is taking up more than half of the available 2.4GHz. band. That isn't a big problem since the signal isn't being used, but makes me unhappy that I'm forced to do that at all. And yes, "20/40 MHz. Coexistence" is enabled *smile*.

RogerSCOrbi will switch to 20 MHz if 20/40 coexistence is enabled and interference is detected. I tested it by putting another AP in the same room on overlapping channels.  I don't know what the threshold is though, or whether it continuously checks or only checks at start-up.

---

st_shaw wrote:

RogerSCOrbi will switch to 20 MHz if 20/40 coexistence is enabled and interference is detected. I tested it by putting another AP in the same room on overlapping channels.  I don't know what the threshold is though, or whether it continuously checks or only checks at start-up.

---

Yes, I agree that it's supposed to work that way *smile*. Unless it's checking like once a week for band crowding, that's not working for me. It was working in router mode, though. Interesting.

I tested it a couple days ago, AP mode, latest firmware. I'm using a set channel, not Auto, and that could make a difference. If that's not it, try disabling the feature, then re-enabling the feature after Orbi reboots.  Perhaps your neighboring APs are not strong enough to trigger the switch. Orbi is probably hammering your neighbors though!

---

st_shaw wrote:

I tested it a couple days ago, AP mode, latest firmware. I'm using a set channel, not Auto, and that could make a difference. If that's not it, try disabling the feature, then re-enabling the feature after Orbi reboots.  Perhaps your neighboring APs are not strong enough to trigger the switch. Orbi is probably hammering your neighbors though!

---

Thanks, I always use a set channel, learned early on not to use "Auto". And I did mention that it was working in router mode, so yes, my neighbor's networks are strong enough to cause 20MHz. channel width to be triggered if it was working.

Not about to reboot the Orbi at this point, I'm still establishing basic stability in AP mode, want to get a little uptime on it...Anyways, I can't remember the "turn if off and turn it back on" dodge ever working for me. I did try that when I first got the Orbi and had the same problem in router mode. Then Netgear fixed it for router mode after a few firmware releases. I don't know why it works for you and not for me in AP mode...one of those "wildly varying results" I was talking about before. I can live with it for a while, since I'm not using 2.4GHz. But I'm glad that it works for you.

Just for the record, I did try the "disable 20/40MHz. Coexistence, and re-enable" thing without rebooting, though, and no effect. Still have 40MHz. channel width.

So it goes.

On the plus side, have a about a day of stability of AP mode with the latest firmware release for the Orbi. A hopeful start. A long way to a month of uptime *smile*. That's my acid test for stability. A week is nice, a month is conclusive for me.

Just to be completely clear, I was suggesting changing the setting, then hitting Apply which restarts the radio and makes the change take effect.  Not just clicking the box.

In my experience, Orbi has been operating with complete stablity in AP mode since I bought it in January, through all software updates. The only time I have had issues is when I created the isssues.  Like when I moved the Orbis to a bad location (a basement corner underground) or when I have had other RF devices too close or operating on conflicting channels (Sonos speakers and ISP routers with WiFi).  Any issues I've had were explainable and fixable with proper channel management, and a little thought and consideration of how Orbi works and how nearby radio systems work.

I have experienced random disconnects with another manufacturer's WiFi router which was 2X more expensive than Orbi, so I understand the frustration of people who do have issues.

---

st_shaw wrote:

Just to be completely clear, I was suggesting changing the setting, then hitting Apply which restarts the radio and makes the change take effect.  Not just clicking the box.

 

In my experience, Orbi has been operating with complete stablity in AP mode since I bought it in January, through all software updates. The only time I have had issues is when I created the isssues.  Like when I moved the Orbis to a bad location (a basement corner underground) or when I have had other RF devices too close or operating on conflicting channels (Sonos speakers and ISP routers with WiFi).  Any issues I've had were explainable and fixable with proper channel management, and a little thought and consideration of how Orbi works and how nearby radio systems work.

 

I have experienced random disconnects with another manufacturer's WiFi router which was 2X more expensive than Orbi, so I understand the frustration of people who do have issues.

 

---

Not sure why you would assume that I don't know about or use "Apply" to commit changes, so here's what I did:

1. Deselected 20/40 MHz Coexistence.

2. Clicked on "Apply".

3. Selected 20/40 MHz Coexistence.

4. Clicked "Apply" again.

See, I know that I need to "Apply"...

Did not help, as I expected. But I'm willing to try things, and often do. Sometimes changes help, sometimes they don't.

Just to to help you out, I've been playing with routers and firmware including dd-wrt, tomato, OpenWRT, LEDE, asuswrt, not to mention Linksys, Netgear, Asus, D-Link, etc. for about 10-15 years. I don't pretend to know everything, but I'm thorough and usually get things to work if they can work. While I'm happy to hear about your experiences, I also know what I'm seeing here.

Thanks for your help, I appreciate it. Right at the moment the only issues I'm having aren't major but are still issues. They apparently differ from your issues. That happens.

I didn't assume anything about what you did.  I only clarified what I was suggesting so there was no ambiguity about what I meant.