Satellites (RBS50) Slow Connectivity to Router (RBK50) after V9.2.5.2.27.1SF Firmware Upgrade

[Vipz]

I just upgraded my RBS50/RBK50 to the latest available Voxel firmware V9.2.5.2.27.1SF. Prior to that, I was running the much older V9.2.1.5.1.34 firmware which has been rock solid and I've had zero issues with it since I'd last installed it.

Since the upgrade, I'm seeing that for any clients connected to either of the satellites, regardless of whether the connection is wired or wireless, I'm not getting the expected speeds as I get from the main router. On the RBK50, Speedtest typically produces results in the 550/20 range for download/upload bandwidth. On the satellites, the max I get is around 120/20.

To troubleshoot further, I've tried moving one of the satellites just shy of ten feet from the RBK50. The backhaul status on the GUI (in Basic->Attached devices page) shows to be "good" and connection type icon just shows the 2.4 Ghz. What would cause it to be stuck on 2.4 Ghz and not select 5Ghz? Any way to force this?

Is there any way to confirm what the actual allocated backhaul bandwidth is between the RBK50 and the satellites? I'm wondering if perhaps this is somehow getting throttled to be lower than the expected value.

[Edit - some additional info]

As part of troubleshooting, I also just tried connecting one of the satellites directly to the RBK50 to create a wired backhaul connection. Once this was done, clients connecting to that satellite performed as expecting, reaching speeds of the roughly 550/20 range for download/upload.

 

[Vipz]

Hi Folks,

Any suggestions at all?

I tried following directions from this article (https://xunnanxu.github.io/2020/04/04/Make-Wireless-BackHaul-Great-Again-Disable-Orbi-2-4G-Backhaul/) that talked about disabling the 2.4 Ghz backhaul. I followed the steps but it made the situation worse after I performed the step : nvram set wlg_sta_ssid=NETGEAR_ORBI_hidden03_disabled . After committing the change and rebooting, the RBS50 just got stuck in phase trying to acquire IP from the router. I was able to force it out and revert the above change by switching to wired backhaul.

My next step is to try and restore stock firmware (currently thinking RBR50-V2.5.2.4) and then doing a factory reset, followed by steps to delete the satellites from the RBK50 and manually re-adding them in hopes for the config to be resync'd. This procedure was suggested in a post from 2019 here - https://community.netgear.com/t5/Or...-RBR-RBS50-dropouts-my-experience/m-p/1745653.

Not finding any other steps so far that could help.

 

[harb]

I had a similar issue and my solution was to disable 2.4Ghz backhaul by shawn's instructions as posted over here

Getting it work was not a problem for my environment and clearly improved performance over backhaul. However the issue I have is that sometimes weather conditions detoriate and cause backhaul to fail and I haven't found out reliable way to recover from this situation other than reboot of satellite devices. Overall this is still better than default unreliable backhaul connectivity.

You can use wlanconfig to analyze the link quality and see whether 5Ghz should work even in theory and if it is e.g. possible to improve the situation by re-positioing the devices.

My next plan is to move over to OpenWRT, hoping that it will make the behavior more consistent as it is clearly issue with automation logic of Netgear implementation.

 

[Vipz]

I had a similar issue and my solution was to disable 2.4Ghz backhaul by shawn's instructions as posted over here

Getting it work was not a problem for my environment and clearly improved performance over backhaul. However the issue I have is that sometimes weather conditions detoriate and cause backhaul to fail and I haven't found out reliable way to recover from this situation other than reboot of satellite devices. Overall this is still better than default unreliable backhaul connectivity.

You can use wlanconfig to analyze the link quality and see whether 5Ghz should work even in theory and if it is e.g. possible to improve the situation by re-positioing the devices.

My next plan is to move over to OpenWRT, hoping that it will make the behavior more consistent as it is clearly issue with automation logic of Netgear implementation.

Thanks so much for your reply. I don't know whether I did something wrong when I was following the instructions from Shawn. I basically executed this to show the available SSID's:


admin@RBS50:/$ config show | grep hidden
wla_hidden_channel=48
wl_hidden_channel=11
hidden_wlan_ca=
wla_2nd_sta_ssid=NETGEAR_ORBI_hidden03
wla_2nd_ap_bh_ssid=NETGEAR_ORBI_hidden03
wlg_ap_bh_ssid=NETGEAR_ORBI_hidden03
wlg_sta_ssid=NETGEAR_ORBI_hidden03
hidden_channel_flag=1
wla_2nd_hidden_channel=157
hidden_schedule_end_block_time=24:00
ntp_hidden_select=9

Next, I executed the following and rebooted the Satellite:

admin@RBS50:/$ nvram set wlg_sta_ssid=NETGEAR_ORBI_hidden03_disabled
admin@RBS50:/$ nvram commit
Manually rebooted the Satellite

Once the Satellite came back on, it. refused to connect to the router and the light remained a solid-magenta. I managed to setup a wired backhaul connection to the router and then SSH back into it. Running the "config show" command this time around showed that in addition to the wlg_sta_ssid being changed, the wlg_ap_bh_ssid had also been changed to "NETGEAR_ORBI_hidden03_disabled".

I had to manually revert both these values back in order to allow the satellite to connect to the router wirelessly again.

Am I missing some step here? Does something also need to be done on the RBK50?

 

[harb]

Thanks so much for your reply. I don't know whether I did something wrong when I was following the instructions from Shawn. I basically executed this to show the available SSID's:


admin@RBS50:/$ config show | grep hidden
wla_hidden_channel=48
wl_hidden_channel=11
hidden_wlan_ca=
wla_2nd_sta_ssid=NETGEAR_ORBI_hidden03
wla_2nd_ap_bh_ssid=NETGEAR_ORBI_hidden03
wlg_ap_bh_ssid=NETGEAR_ORBI_hidden03
wlg_sta_ssid=NETGEAR_ORBI_hidden03
hidden_channel_flag=1
wla_2nd_hidden_channel=157
hidden_schedule_end_block_time=24:00
ntp_hidden_select=9

Next, I executed the following and rebooted the Satellite:

admin@RBS50:/$ nvram set wlg_sta_ssid=NETGEAR_ORBI_hidden03_disabled
admin@RBS50:/$ nvram commit
Manually rebooted the Satellite

Once the Satellite came back on, it. refused to connect to the router and the light remained a solid-magenta. I managed to setup a wired backhaul connection to the router and then SSH back into it. Running the "config show" command this time around showed that in addition to the wlg_sta_ssid being changed, the wlg_ap_bh_ssid had also been changed to "NETGEAR_ORBI_hidden03_disabled".

I had to manually revert both these values back in order to allow the satellite to connect to the router wirelessly again.

Am I missing some step here? Does something also need to be done on the RBK50?

This should do it.

wlg_ap_bh_ssid will get disabled by itself and there is no need to reconfigure RBR. Main point is that wlg_sta_ssid is different from any other satellite or the router.

I think you have something wrong with 5Ghz backhaul as it doesn't take over if you disable 2.4Ghz.

Problem I had troubleshooting connectivity was that it is not obvious what physical interface corresponds to network interface / subinterface and for what purpose / function it is used. Also, this seems to be revision / version specific.

I propose of going through the interfaces one by one on router and satellite side and noting down expected use of interface.

Then you can see if there is another router/satellite present on the interface or client, if the interface is operational or not and what is the connection quality.

It can be done with:
iwconfig
vi /etc/config/wireless
wlanconfig

iwconfig to check wireless interfaces and parameters, wireless config file to see correspondence to physical interfaces and wlanconfig to see different statistics.

Unfortunately I cannot provide you example / details as I don't have remote access to mine.

 

[Vipz]

You mentioned above -- "Main point is that wlg_sta_ssid is different from any other satellite or the router.". Does this mean that if I have two satellites, then when I run the commands on each, I have to set the name to something different on each?

When I was testing the scenario above, I'd run the same commands on both the satellites so they both had the "NETGEAR_ORBI_hidden03_Disabled" value for wlg_sta_ssid and wlg_ap_bh_ssid. Could this be the root cause of the problem that caused it to not work?

Is the correct procedure then to change it to say NETGEAR_ORBI_hidden03_Disabled1 on one satellite and perhaps NETGEAR_ORBI_hidden03_Disabled2 on the other so they're unique on each of the satellites?

 

[harb]

You mentioned above -- "Main point is that wlg_sta_ssid is different from any other satellite or the router.". Does this mean that if I have two satellites, then when I run the commands on each, I have to set the name to something different on each?

When I was testing the scenario above, I'd run the same commands on both the satellites so they both had the "NETGEAR_ORBI_hidden03_Disabled" value for wlg_sta_ssid and wlg_ap_bh_ssid. Could this be the root cause of the problem that caused it to not work?

Is the correct procedure then to change it to say NETGEAR_ORBI_hidden03_Disabled1 on one satellite and perhaps NETGEAR_ORBI_hidden03_Disabled2 on the other so they're unique on each of the satellites?

Exactly. If two satellites have same SSID then the interface will come up in between the satellites and connectivity to router will fail.

So, you need to rename those with different names. I ended up using premises reference over there as it was easier to manage. E.g. _disabledsauna

 

[Vipz]

I've made the updates as discussed above to the satellites and then powered them down. Following this, I rebooted the router first and let it fully come up. Once it was up and running, I powered on the first satellite only to see that it never gets past the phase where it's trying to connect to the router - its stuck showing the solid magenta light at top.

Is there anything I can check on the RBK50 itself to see whether it's somehow not setting up the 5Ghz backhaul ?

 

[Vipz]

Trying yet more things to try and isolate the problem - I installed the latest stock Orbi firmware (2.7.5.4) to try and factory-reset the satellites.

Followed the steps mentioned in this post to do the factory reset and reconnect the satellite to the router

1) Switch satellite off.
2) Wait until the router gui shows disconnected and then hit remove.
3) Switch satellite on and immediately factory reset it via the button.
4) Wait until it finishes booting up
5) Add new satellite via the gui.

Sadly, this too has had zero impact and the satellites still appear to only be connecting to the router via a slower backhaul connection. The GUI page on the satellite side shows this, which I'm reading as just connecting to the 2.4Ghz and not the 5Ghz backhaul.

Are there other things I can do to try and localize the problem?

Edit>>

One interesting thing I recall is that during the first time I'd tried changing the wlg_sta_ssid on one of the satellites (satellite1), when it came up following a reboot, it actually connected to the satellite2 instead of the router almost as-if I had enabled daisy-chain config (which I had not). When I'd logged in to the satellite1's GUI, it actually showed both the top and bottom portion of the graphic between router & satellite as blue, indicating that both the 2.4Ghz and 5Ghz backhaul connections were in use. However in this case what it was representing as the Router was actually the Satellite2. In the graphic above, the 5Ghz portion is grayed out so either not being enabled by the router, or not being used by the satellite.

 

[Vipz]

I had a chance to check the setup on a friend's Orbi and for the topology picture showing the router connecting to the satellite, in his case, the colors are flipped showing only the 5Ghz connected and nothing for the 2.4Ghz.

I have performed a factory reset on the router. Even after the factory reset and reconfiguring everything from scratch, adding the satellites only showed them connecting via 2.4Ghz backhaul, same as before.

Any way to check whether the router has even enabled the 5Ghz backhaul? I can revert it back to the latest Voxel firmware and run whatever diagnostics on it to investigate this further.

Would the more drastic step of restoring the router via TFTP help?

 

[gssjshark]

I had a chance to check the setup on a friend's Orbi and for the topology picture showing the router connecting to the satellite, in his case, the colors are flipped showing only the 5Ghz connected and nothing for the 2.4Ghz.

I have performed a factory reset on the router. Even after the factory reset and reconfiguring everything from scratch, adding the satellites only showed them connecting via 2.4Ghz backhaul, same as before.

Any way to check whether the router has even enabled the 5Ghz backhaul? I can revert it back to the latest Voxel firmware and run whatever diagnostics on it to investigate this further.

Would the more drastic step of restoring the router via TFTP help?

I would try restoring firmware via TFTP on all satellites and the router then performing a factory reset on all satellites and router and rerun the setup. See if that fixes everything.

 

[Vipz]

I would try restoring firmware via TFTP on all satellites and the router then performing a factory reset on all satellites and router and rerun the setup. See if that fixes everything.

Following the instructions here and using steps provided by Voxel in this thread for how to put the Satellite/Router into the mode ready to receive the firmware via TFTP, I've managed to upgrade the satellites so far. Will try the router next at end of day once the family is OK to to be without internet for a bit and see how it goes!

Thanks @harb and @gssjshark for the help so far! It's truly appreciated.

 

[Vipz]

Have come full circle on this. I managed to flash the router with the stock firmware (v2.5.2.4) via tftp and reconfigured it from scratch including adding the satellites. The satellites still just connected via 2.4 Ghz and remain as such regardless of what I try to do.

At this point, I'm out of further ideas and am guessing it's time to replace the router.

 

[gssjshark]

Have come full circle on this. I managed to flash the router with the stock firmware (v2.5.2.4) via tftp and reconfigured it from scratch including adding the satellites. The satellites still just connected via 2.4 Ghz and remain as such regardless of what I try to do.

At this point, I'm out of further ideas and am guessing it's time to replace the router.

Did you factory reset each unit after the TFTP flash?

 

[Vipz]

Did you factory reset each unit after the TFTP flash?

No did not perform a factory reset again after the tftp flash. Though can definitely try going through the process again for the router and one satellite to see if it changes anything.

I did end up picking up a replacement system (the AX4200) so now can tinker with the RBK50 system without interrupting the rest of the family’s internet access.

 

[gssjshark]

Yes, please perform a factory reset after every TFTP flash for all satellites and the router and then setup everything again.

Please report back after. Otherwise might just be a hardware failure.

 

[Vipz]

Yes, please perform a factory reset after every TFTP flash for all satellites and the router and then setup everything again.

Please report back after. Otherwise might just be a hardware failure.

I went through the process of restoring the stock v2.5.2.4 firmware via tftp and then factory resetting each device and going through the setup process from scratch. After the router itself was setup, I manually added the satellites. I added both satellites at the same time and in hind-sight I feel like perhaps I should've waited and done them one after another.

What I observed was that by default, the setting for using daisy-chain topology is enabled. This in turn caused the first satellite to connect to the router via 2.4 Ghz and then the second satellite connected to the first satellite via a 5 Ghz backhaul connection (granted they were closer to each other than to the router).

After identifying which satellite was connected via the 2.4 Ghz, I powered it down to enable the second satellite to go direct to the router. It appeared to do this and temporarily showed that it was using the 5Ghz backhaul - I don't know if this was a false positive or whether in reality it was actually using the 5Ghz backhaul or not. Following a reboot of all the devices again, they seem to have reverted back to just using the 2.4 Ghz backhaul no matter what I do.

I'm tempted to go through the process one more time and do it in steps rather than the way I did the first time to see if the behavior is any different before giving up on it entirely. I'm hoping that if I decide to do this, then it is sufficient to just go from the step of doing a factory reset on each device vs. also restoring the firmware via tftp first before doing the factory reset. Will give this a shot again sometime today and report back how it turns out.