Closed kubrickfr closed 5 years ago
kubrickfr
commented
5 years ago Also, it's not just from one client, it doesn't work from my phone or my laptop.
In case it helps, I've got tow SSIDS, one of which is hidden, connection is impossible to either.
ValCher1961
commented
5 years ago I encountered a similar phenomenon on WRT3200ACM when using HOSTAPD-2.7. What version of HOSTAPD do you use?
davidc502
commented
5 years ago Does it behave the same way if the width is set to 40Mhz?
ValCher1961
commented
5 years ago In my case, Debian, hostapd-2.7, recommended settings hostapd.conf for Mwlwifi width 80 mHz. After detecting radar and switching AP to 36 channel, clients on Intel AC7260 cannot connect to the AP. After the allotted time to release the channel and the absence of new radar signals, the AP does not return to the previous channel. If you use hostapd-2.6, you do not have this problem. It is difficult to say whether my problem is similar to the author's problem.
davidc502
commented
5 years ago The issue I see is when a device can't connect to a specific DFS channel this is in the kernel log. This usually only happens after radar is detected and goes to another DFS channel.
[196922.640147] marvell-cesa f1090000.crypto: dma_pool_free cesa_cache, dma 0x125fb000 already free
ValCher1961
commented
5 years ago Unfortunately I have not kept the logs and I can not quickly introduce new, because the detection of work radar I happen very rarely, two-three times a week. Is there any method of emulation of DFS activation?
davidc502
commented
5 years ago If you introduce another wifi SSID, from another device, on that same channel, it will probably vacate that channel and produce the log when clients try to re-connect.
ValCher1961
commented
5 years ago Today I configured two routers WRT3200ACM on 132 channel with different SSID names, but they did not react to each other, they worked in parallel.
davidc502
commented
5 years ago Thanks for testing.... Yeah, that hasn't been my experience. I have a neighbor's remote TV box that roams around DFS, and consistently bumps me off. So, I'm surprised it has not happened to you.
If it can't be induced, then there is no option but to wait.
lantis1008
commented
5 years ago I believe you can
echo 1 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/dfs_test
yuhhaurlin
commented
5 years ago Yes. This is the way to fake radar detection. I did not find reconnection problem.
kubrickfr
commented
5 years ago @yuhhaurlin have you tried with the European version? Because the problem is definitely happening, at least for two people here.
yuhhaurlin
commented
5 years ago Can you use above way to generate radar detection and check what happens?
kubrickfr
commented
5 years ago @yuhhaurlin just tested
echo 1 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/dfs_testNothing happens at all. Nothing in the system or kernel log, channel stays on 116.
FYI:
root@lede:~# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info
driver name: mwlwifi
chip type: 88W8964
hw version: 7
driver version: 10.3.8.0-20181210
firmware version: 0x09030206
power table loaded from dts: no
firmware region code: 0x30
mac address: 60:38:e0:b6:97:ca
2g: disable
5g: enable
antenna: 4 4
irq number: 49
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000003
radio: enable
iobase0: e0e80000
iobase1: e1100000
tx limit: 1024
rx limit: 16384This is still happening, at least once a week...
When the firmware detects a radar and reverts to channel 36, it's impossible to connect to 5GHz any more, I have to restart the wireless interface.
The is the kernel log output:
For each
staid 1 deleted, I get the following system log:On the client side, association is performed but the dhcp request fails, but it works from the wired interface.