New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#506 - BT Home Hub 5: 5g WiFi jumps to channel 36 and stops working if stopped and restarted #5524
Comments
ezplanet: This happens also on a WNDR3700v4: Configure Atheros AR9580 802.11an (radio1) to a Band B Channel (100-140) Use a WiFi scanner like Android WiFi Analyzer to scan WiFi channels. The router will be initially on the configured channel. After a few minutes it will jump to Channel 36 (Band A). /etc/config/wireless remains untouched to the original channel only the radio will be on channel 36. On reboot it will take the configured channel on Band B (eg Ch 104) correctly, but it will jump to Ch 36 again after a few minutes. The router will take the configuration for any Band B Channel, but it will not appear at all. Only if configured on a Band A (ch 36-64) it will appear on the radio waves. Also in this case if I disable and re-enable the device it will not work. A reboot is required to restore service. |
arjendekorte: This could be due to radar activity and DFS backing out. Check out if /sys/kernel/debug/ieee80211/phy1/ath9k/dfs_stats shows any hints of what could be going on. Note that Ch 104 works fine on a WNDR4300 I have here (r3426-4c09f99605). |
ezplanet: DFS can be OK if a bit too quick to change channel, the main issue here is that when this happens, if I disable/re-enable the interface, it will no longer work and it will require a reboot to get it back on line. |
arjendekorte: That is not the idea behind DFS. If interference is detected, it is mandatory to back-off from a channel and not retry again for a certain amount of time (half an hour, if memory serves).
should show how long channels will not be available for further scanning. Restarting the interface should not make a difference, as the timer must not be reset in that case. You should really ask yourself, if frequent dropping out of the selected channel doesn't mean there actually is interference preventing your routers from using them. This whole DFS thing is there for a reason. |
ezplanet: Arjen, I understand DFS, however when the channel jumps to 36:
|
arjendekorte:
cat /sys/kernel/debug/ieee80211/phy1/ath9k/dfs_statsDFS support for macVersion = 0x1c0, macRev = 0x4: enabled
|
ezplanet: Here is what I get after a jump to ch36 from ch120 on BT Home Hub 5:
DFS support for macVersion = 0x180, macRev = 0x2: disabled
Pulse detector statistics:
pulse events reported : 0
invalid pulse events : 0
DFS pulses detected : 0
Datalen discards : 0
RSSI discards : 0
BW info discards : 0
Primary channel pulses : 0
Secondary channel pulses : 0
Dual channel pulses : 0
Radar detector statistics (current DFS region: 2)
Pulse events processed : 0
Radars detected : 0
Global Pool statistics:
Pool references : 7
Pulses allocated : 46
Pulses alloc error : 0
Pulses in use : 10
Seqs. allocated : 41
Seqs. alloc error : 0
Seqs. in use : 0
After this, if I disable, then re-enable the interface on BT Home Hub 5, the interface fails to work. A reboot is required to get it back working. |
arjendekorte: The line
tells DFS is not available on your hardware with the current driver. I'm actually a bit surprised this is working at all. This should work on the WNDR3700v4 however, as that one is using a supported chip (AR9580). |
ezplanet: I have just seen it jump from 56 to 36 and then lock. |
arjendekorte: DFS support is required on Ch56. If this is on your BT Home Hub 5 which doesn't support DFS with the existing ath10k driver (see above), you're trying to do something that is not supported and it is not a bug. |
mavcin: I think this is a luci issue, already fixed |
dlang: jumping from a DFS channel to channel 36 happens when the radar detection in the chipset detects what it thinks is radar on the channel you are on. It is then required to switch off of that channel, and OpenWRT/LEDE switch to channel 36 |
ezplanet: I am not trying anything at all this is the default, I do not even know if there is a parameter for DFS. Is there a way to turn it off? If I turn the country code to 00 - World does it turn it off? |
mavcin: From my BT Home Hub 5 |
ezplanet: I found the following documentation on line that summarizes DFS specifications: DFS-enabled radios monitor the operating frequency for radar signals. If radar signals are detected on the channel, the wireless device takes these steps:
From my observations the implementation of LEDE DFS: a) assume (4) as ch 36 only whilst it could be any other permitted frequency And finally it crashes the WiFi device if I try to change the channel manually or disable re-enable the device, requiring a reboot to resume operations. Also on BT Home Hub 5 DFS is reported as disabled but it appears to be taking place anyway. |
arjendekorte: You probably need to look at phy0
to look for the DFS statistics. If not zero, the number of radars detected is really of no interest and means that the channel you configured is not usable in your location. Note that if radar is detected, although allowed to retry after some time (5), it is pointless to do so. Most of the (weather) radars are ground based systems, so if you're in range of such an installation, you'll invariably detect them again. Most (if not all) of the DFS stuff is built into the kernel and not LEDE specific. You're barking up the wrong tree here. |
sumpfralle: If I understand the submitter correctly, we are discussing different issues here. The submitter described:
I do not think, that the channel switch (due to DFS) is the problem of the submitter. The real problem seems to be that he needs to reboot his router in order to get the wifi working again. As a sidenote: Or do I misunderstand something? |
pietia: I do confirm on archer c7 v2 17.01.4 it went back to channel 36 from channel 104 even tho there was a device that was on channel 36 and there wasn't on channel 104. |
mkresin:
No it isn't as already discussed here:
In most countries Channel 104 is a DFS channel and as soon as a radar is detected (or what the chipset thinks is radar) it must be switch to a different channel. Finally, this ticket is about a wireless hang after DFS related channel switch. @mauro, do you still see this error? Till now I wasn't able to reproduce the issue on my HH5a. |
pietia: Sure it is DFS but it shouldn't go to channel 36 which can be occupied by other routers and in my case it was. ". The access points automatically select frequency channels with low interference levels" https://en.wikipedia.org/wiki/Channel_allocation_schemes#DFS Mauro Mozzarelli explained preceisly wrong behaviour. |
samoz83: I'm getting the same thing, my non LEDE home hub doesn't change off of DFS channels, in my case channel 120 but the LEDE router does and goes back to 36? I seem to also get the hang if you try and switch it back to any channel that's not 36 once it's changed itself back. |
pietia: @sam same hang here as well... |
ezplanet:
Supply the following if possible:
It can be after a few hours, if WiFi 5g radio0 Qualcomm Atheros QCA9880 802.11nac (radio0) is configured to a Band B channel, it jumps to Channel 36 even though there is no apparent interference.
This appears to happen more frequently overnight during long periods of inactivity. Whilst the device is being used it does not happen.
After it does make the jump, if I stop and restart the device (using luci disable/enable) the device stops, but it fails to restart. Attempts to change the channel and re-enable the device also do not help.
It requires a reboot to restore service.
The text was updated successfully, but these errors were encountered: