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).
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).
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:0
Here 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:0
In 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:0
So, 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).
- Excellent! This would (for the first time) explain why some Orbi owners see a massive performance impact, in fact way below of what a plain 2.4 GHz AP connection (on a normally workable 5 GHz backhaul) - and therefore requesting the "need" to split the SSIDs of the two AP bands.
I could imagine some special conditions for a 2.4 GHz backhaul - as it's the same radio it's of course extender style. But this must never happen unless the signal level and quality is no longer allowing 5 GHz (and if there is no wired backhaul).
Clearly an indication of a fat bug or a design error!
TarjeiB wrote:
...
And therefore, my original request stands: Please provide a way to disable 2.4Ghz backhaul (or fix the bugs in the firmware)....
While I was digging for other stuff, I thought I saw hidden options in debug where there are two separate check boxes, each of which controls separate backhaul, can't recall the exact name. If unticking one of that check box works wonder, it would be easier than doing it via telnet?
