NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Request: GUI option to turn off 2.4G backhaul
So I posted a somewhat long and detailed instruction on how to disable the 2.4G backhaul, that fixed the problem of satellites falling back to 2.4G backhaul and the issue of devices intermittently dis...
CrimpOn You're mostly right, the issue here is the falling back to 2.4Ghz backhaul.
The problem is that it does so even while the 5Ghz connection is strong - so there is a problem somewhere which ignores RSSI setting, or doesn't move back to 5Ghz after one fallback has been done even if connection improves.
I'll post my findings here anyway and hope it doesn't get deleted (Picking a random satellite and showing the config):
iwconfig for the first radio (ath0, 2.4Ghz).
This is the 2.4Ghz backhaul AP. It shares the radio with the other 2.4Ghz networks, seen by that they all start with ath0.
ath01 IEEE 802.11ng ESSID:"NETGEAR_ORBI_hidden33" Mode:Master Frequency:2.472 GHz Access Point: 42:94:ED:35:89:AD Bit Rate:400 Mb/s Tx-Power:18 dBm RTS thr:off Fragment thr:off Encryption key*** Security mode:restricted Power Management:off Link Quality=94/94 Signal level=-97 dBm Noise level=-95 dBm Rx invalid nwid:1543 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0Here is the next one - this is the 2.4Ghz backhaul client (that connects to another satellite on their 2.4Ghz backhaul). Pure repeater setup.
ath02 IEEE 802.11ng ESSID:"NETGEAR_ORBI_hidden33" Mode:Managed Frequency:2.472 GHz Access Point: 42:94:ED:35:8A:07 Bit Rate:400 Mb/s Tx-Power:18 dBm RTS thr:off Fragment thr:off Power Management:off Link Quality=86/94 Signal level=-64 dBm Noise level=-95 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0Here's the main network, on the same radio.
ath0 IEEE 802.11ng ESSID:"toodles" Mode:Master Frequency:2.472 GHz Access Point: 3E:94:ED:35:89:AD Bit Rate:400 Mb/s Tx-Power:18 dBm RTS thr:off Fragment thr:off Encryption key:**** Security mode:restricted Power Management:off Link Quality=94/94 Signal level=-97 dBm Noise level=-95 dBm Rx invalid nwid:2996 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0In addition there's ath03 with the guest network, omitted for the sake of post lenght.
So for the 5Ghz radio. Dedicated band, no sharing with backhaul, great stuff.
ath1 IEEE 802.11ac ESSID:"toodles" Mode:Master Frequency:5.22 GHz Access Point: 38:94:ED:35:89:AF Bit Rate:866.7 Mb/s Tx-Power:21 dBm RTS thr:off Fragment thr:off Encryption key:*** Security mode:restricted Power Management:off Link Quality=94/94 Signal level=-97 dBm Noise level=-95 dBm Rx invalid nwid:640 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0In addition there is the ath11 network, which is the guest network. Omitted.
Lastly the 5Ghz backhaul:
ath2 IEEE 802.11ac ESSID:"NETGEAR_ORBI_hidden33" Mode:Master Frequency:5.54 GHz Access Point: 38:94:ED:35:89:B0 Bit Rate:1.7333 Gb/s Tx-Power:27 dBm RTS thr:off Fragment thr:off Encryption key:*** Security mode:restricted Power Management:off Link Quality=94/94 Signal level=-97 dBm Noise level=-95 dBm Rx invalid nwid:316 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0And the 5Ghz client to connect to other satellites (again pure repeater setup):
ath21 IEEE 802.11ac ESSID:"NETGEAR_ORBI_hidden33" Mode:Managed Frequency:5.54 GHz Access Point: 38:94:ED:35:8A:0A Bit Rate:1.7333 Gb/s Tx-Power:27 dBm RTS thr:off Fragment thr:off Power Management:off Link Quality=91/94 Signal level=-57 dBm Noise level=-95 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0So, proven 2.4Ghz backhaul for those who need to see it.
I did dig a good bit further into the setup.
There seems to be two types of setup on the Orbi (and other NG OpenWRT based devices):
"config" (NG specific) and "uci" (OpenWRT specific).
Both work the same way, you can "config get <parameter>" or "uci get <parameter>" and "config set <parameter='<value>'" or "uci set <parameter='<value>'". Finish with "config commit" or "uci commit" to write to nvram for reboot persistence (unsure if the uci commands are written to nvram, haven't tested).
If you do a configuration backup, it seems like it's just backing up the equivalent of "config show" command, encrypted (because the command will show EVERYTHING in plaintext, WPA keys, secret questions, passwords, etc).
Here are some relevant backhaul "config show" parameters:
wla_hidden_channel=44 wl_hidden_channel=13 hidden_wlan_ca= wla_2nd_sta_ssid=NETGEAR_ORBI_hidden33 wla_2nd_ap_bh_ssid=NETGEAR_ORBI_hidden33 wlg_ap_bh_ssid=NETGEAR_ORBI_hidden33 wlg_sta_ssid=NETGEAR_ORBI_hidden33 hidden_channel_flag=1 wla_2nd_hidden_channel=108
Everything that starts with "wl_" or "wlg_" is 2.4Ghz. So just an echo of the above really.
My original post (that was deleted) described how to change these so the satellites couldn't connect on 2.4Ghz backhaul anymore, and therefore fixing the falling back to 2.4Ghz issue.
The really interesting stuff is easier to see using the command "uci", in this case "uci show repacd.WiFiLink":
repacd.WiFiLink=WiFiLink repacd.WiFiLink.MinAssocCheckAutoMode='5' repacd.WiFiLink.MinAssocCheckPostWPS='5' repacd.WiFiLink.MinAssocCheckPostBSSIDConfig='5' repacd.WiFiLink.WPSTimeout='180' repacd.WiFiLink.AssociationTimeout='170' repacd.WiFiLink.RSSINumMeasurements='5' repacd.WiFiLink.RSSIThresholdFar='-75' repacd.WiFiLink.RSSIThresholdFar5g='-82' repacd.WiFiLink.RSSIThresholdFar24g='-76' repacd.WiFiLink.RSSIThresholdNear='-60' repacd.WiFiLink.RSSIThresholdMin='-75' repacd.WiFiLink.RSSIThresholdPrefer2GBackhaul='-82' repacd.WiFiLink.2GBackhaulSwitchDownTime='10' repacd.WiFiLink.MaxMeasuringStateAttempts='30' repacd.WiFiLink.DaisyChain='1' repacd.WiFiLink.RateNumMeasurements='5' repacd.WiFiLink.RateThresholdMin5GInPercent='25' repacd.WiFiLink.RateThresholdMax5GInPercent='95' repacd.WiFiLink.RateThresholdPrefer2GBackhaulInPercent='5' repacd.WiFiLink.5GBackhaulBadlinkTimeout='60' repacd.WiFiLink.BSSIDAssociationTimeout='170' repacd.WiFiLink.RateScalingFactor='85' repacd.WiFiLink.5GBackhaulEvalTimeShort='330' repacd.WiFiLink.5GBackhaulEvalTimeLong='1800' repacd.WiFiLink.2GBackhaulEvalTime='1800' repacd.WiFiLink.PreferCAPSNRThreshold5G='20' repacd.WiFiLink.MoveFromCAPSNRHysteresis5G='7' repacd.WiFiLink.2GIndependentChannelSelectionEnable='0' repacd.WiFiLink.2GIndependentChannelSelectionRssiLevel='-70' repacd.WiFiLink.2GIndependentChannelSelectionTotalRssiCounter='10' repacd.WiFiLink.2GIndependentChannelSelectionRssiDebug='0' repacd.WiFiLink.2GIndependentChannelSelectionStartRssiCheckTime='60' repacd.WiFiLink.ManageVAPInd='1' repacd.WiFiLink.PreferCAPSNRThreshold='20' repacd.WiFiLink.BSSIDResolveState='resolved'
There are loads of interesting parameters here, but I'll focus on a few - first:
repacd.WiFiLink.RSSIThresholdPrefer2GBackhaul='-82'
So when 5Ghz strength falls below -82 (which is horrible) it will switch to 2.4Ghz backhaul.
This would be fine. However, my 5Ghz strength has never been below -45, but it STILL switches to 2.4Ghz and stays there.
I have played around with this parameter and a few others related, but it makes no difference - there is clearly a bug that will switch you over to 2.4Ghz too early (for some, I guess). Maybe the satellite is broken? But it works fine with my "disable 2.4Ghz backhaul" hack.
This parameter is also somewhat interesting:
repacd.WiFiLink.5GBackhaulBadlinkTimeout='60'
Maybe there are fluctuations that make this come into effect, but 60 (I assume seconds) is a long time. Also, you'd expect it to come back after a while. But it doesn't, and again it works perfectly if you just disable 2.4Ghz.
There are many hundreds if not thousands of lines of config in "config show" and "uci show" so there's plenty to write about, but these are some of the most important related to the 2.4Ghz backhaul.
And therefore, my original request stands: Please provide a way to disable 2.4Ghz backhaul (or fix the bugs in the firmware).
TarjeiB wrote:
So I posted a somewhat long and detailed instruction on how to disable the 2.4G backhaul, that fixed the problem of satellites falling back to 2.4G backhaul and the issue of devices intermittently disconnecting.The Tri-Band Orbi like the tagged RKB53, the Orbi WiFi 6 RBK852, and the Orbi Pro devices have a dedicated 5 GHz interface for the wireless backhaul used connecting the router with the satellites. Both the router and the satellites use dedicated 2.4 GHz and 5 GHz radios for the access point functionality.
Yet, there is a common problem that the satellites will fall back to 2.4Ghz "backhaul" that is not at all dedicated, but shared on the regular AP 2.4Ghz. The 5Ghz backhaul has a strong connection, yet it falls back to 2.4Ghz after a while. So, when I disabled it using telnet, config and uci, it started working like it should; sticking to the 5Ghz backhaul. Therefore, the request.
TarjeiB wrote:
The post was deleted by NG, but the problem remains - so, could we please have an option to disable the 2.4G backhaul in the GUI? Just like you can on the normal repeaters (EX8000 for example). The satellites are just repeaters configured as mesh devices anyway.At no point are Tri-Band Orbi radios shared for backhaul and client access as on an el-cheepo basic wireless extender two-radio wireless extender where the same radios is used for the connection to the primary router, on the the same channels, are also offering the wireless access point capability.
The EX8000 is not a basic repeater, it's a Tri-Band extender, which does ideally connect using a dedicated 5 GHz radio to the root device, and does run both a 2.4 and a 5 GHz radio as dedicated access points. It's indeed similar to the Orbi satellite design.
Not sure what problem you are behind.
The EX8000 is still a repeater/extender, not a mesh. Advanced, sure, but not a mesh. I never mentioned anything about single or dual band extenders that share radio for backhaul, but ironically the problem here is exactly that; The Orbi falls back to using the shared 2.4Ghz.
Just for clarity, a mesh would typically be equal devices (but not neccessarily) operating on the 802.11s standard. I have actually not checked if the Orbi uses 802.11s, but the config I have dug through tells me it's not. If so, I'll retract my "not a mesh" statement.
Oh, the problem is described in several posts, I'll link some:
https://community.netgear.com/t5/Orbi/Is-Backhaul-also-using-2-4GHz/m-p/1202230
https://community.netgear.com/t5/Orbi/Satellite-only-connects-with-2-4Ghz/m-p/1633828
All consumer class vendors define Mesh as a single SSID with IEEE 802.11r-2008 fast BSS transition (FT), aka. Fast Roaming. All these systems were designed long before 802.11s came up - and no vendor does currently approach 802.11s interoperability. It's market protection... this applies to Orbi mesh as well as the so called Mesh extenders - and all other vendors in this market: There is no true Mesh technology in place - so for now you can skip this idea.
TarjeiB wrote:
Yet, there is a common problem that the satellites will fall back to 2.4Ghz "backhaul" that is not at all dedicated, but shared on the regular AP 2.4Ghz.
Again, there is no 2.4 GHz backhaul - even if you insist, nothing "shared".
TarjeiB wrote:The 5Ghz backhaul has a strong connection, yet it falls back to 2.4Ghz after a while. So, when I disabled it using telnet, config and uci, it started working like it should; sticking to the 5Ghz backhaul. Therefore, the request.
Your mod (I guess) does apply to the wireless access point on the router and the satellite based access points only. No relation to the backhaul which is either dedicated 5 GHz or wired only.
What you experience is that dual-band client does connect to the Orbi system (router or one of the satellites), either on 2.4 or on 5 GHz. For whatever reason, some clients fall back to the 2.4 GHz. This can have two reasons:
A) A "dumb" or classic client will stick on the same AP radio and band until the connection does is lost. This can cause an issue that some IoT will "see" the primary router 2.4 GHz first, before the better 2.4 or 5 GHz on the satellites come up.
B) A modern client will get a list of neighbouring AP radios and evaluate better connection options for the same SSID. 802.11r, remember?
What is the band steering Orbi does? I think this is not officially documented.Typical approach is to not accept the first sync or connection attempt on 5 GHz, awaiting the client will also attempt to sync or connect to 2.4 GHz. If the signal level is high enough, the next attempt to the 5 GHz radio will be allowed. That's how the AP does learn if the same client can handle both 2.4 and 5 GHz so it can become a subject of the band steering. Starting from here the AP can play with the client at whatever algorithm. If using more bandwidth on the 2.4 GHz it can de-assign it, thanks to the 802.11r capability, the client will re-connect to 5 GHz - permitting signal level et all is sufficient. And the same can happen the other way: And here there might be some flaw for some clients.
And again, I have no idea of the steering can cover these dumb clients which initially connected to the router AP on 2.4 GHz. Probably not - because the other AP don't know that this client would be near....
PS: I won't comment on the other two threads - because already the subjects choosen are basically wrong. The clients are connecting to the AP....the router or satellites don't connect to the clients.
I have no intention of arguing about this, it's a reasonable request to a known problem - and the 2.4Ghz backhaul exists and it's prone to take over in unwanted conditions.
https://community.netgear.com/t5/Orbi/Backhaul-2-4-vs-5-usage/td-p/1277970
Enable telnet, do "iwconfig list", "config show" and "uci show repacd" and it's all there in plain text.
Well, believe what you want - post the output and try to provide proof. I'm happy to see and learn.
The approach is - in my opinion - completely wrong. We're operating small, medium, and large scale WiFi infrastructures with one SSID connecting to the same VLAN, regardless of the radio and can't see any reasonable problem and no need to split the two band SSIDs or disable one of the two bands.
I don't want to provoke anyone, but this appears to me similar to in Cool Hand Luke: "What we have here, is a failure to communicate."
Yes, there is a raging discussion about separating 2.4G and 5G SSID's and turning 2.4G and 5G radios on and off. And, there are strong opinions about whether this is necessary or advisable. But, that's not what I saw the original proposal to be. The way I read the original statement was this:
Orbi is designed to communicate between nodes ("backhaul") using either ethernet (preferred if available) or 5G WiFi. However, if ethernet is not available and the 5G connection is terrible, Orbi will fall back to a 2.4G backhaul connection rather than have no backhaul connection at all. We just recently had a discussion about an Orbi system displaying "2.4G" on the satellite connection status. I do not think the poster imagined his Orbi saying that. https://community.netgear.com/t5/Orbi/Does-an-ethernet-connection-prevent-daisychaining/m-p/1836524#M78188
Maybe my memory of reading about 2.4G as the "last resort" backhaul is incorrect, and maybe this poster was not reading his Attached Devices display correctly.
I understood the original proposal to be "Provide users an option to FORBID the Orbi from ever using a 2.4G backhaul." The augument being that somehow this would force the Orbi to stay on 5G and not impact the 2.4G channel. (1) I can imagine that Netgear engineers would say, "pound sand. we're not going to f**k with the internals of our system." (2) I can also imagine that if the 5G backhaul is SO BAD that Orbi thinks it won't work, that forbidding 2.4G backhaul means NO BACKHAUL AT ALL. i.e. it no long works at all.
I'm sorry if I have not followed the conversation correctly. And, I do not want to wind up like Paul Newman (shot in the head).
