Open ptpt52 opened 3 years ago
the same issue if sta connect to upstream WIFI and ap not working I have to first find out the upstream WIFI channel and set to the option so it work.
I found that I need to reboot the router to change AP's channel. otherwise it didn't show up (include restarting the interface from luci)
update to latest master code if ap set to auto channel and sta connected logread keep reporting:
Mon Mar 15 20:19:32 2021 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Mon Mar 15 20:19:32 2021 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Mon Mar 15 20:19:32 2021 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Mon Mar 15 20:19:32 2021 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Mon Mar 15 20:19:32 2021 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Mon Mar 15 20:19:32 2021 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Mon Mar 15 20:19:32 2021 daemon.err hostapd: Wrong coupling between HT and VHT/HE channel setting
Mon Mar 15 20:19:38 2021 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Mon Mar 15 20:19:38 2021 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Mon Mar 15 20:19:38 2021 daemon.err hostapd: Wrong coupling between HT and VHT/HE channel setting
...
and if I set the channel to the specify channel (say 52, sta on this channel) the log stop report
and then I change the upstream AP channel from 52 to 36 the sta can never connected
[ 270.883450] wlan1: authenticate with c8:5b:a0:e7:34:64
[ 271.252789] wlan1: send auth to c8:5b:a0:e7:34:64 (try 1/3)
[ 271.265511] wlan1: authenticated
[ 271.275877] wlan1: associate with c8:5b:a0:e7:34:64 (try 1/3)
[ 271.289317] wlan1: RX AssocResp from c8:5b:a0:e7:34:64 (capab=0x11 status=0 aid=1)
[ 271.304627] wlan1: associated
[ 271.467174] wlan1: AP VHT information is invalid, disable VHT
[ 271.478736] wlan1: AP c8:5b:a0:e7:34:64 changed bandwidth, new config is 5180.000 MHz, width 2 (5190.000/0 MHz)
[ 271.498916] wlan1: AP c8:5b:a0:e7:34:64 changed bandwidth in a way we can't support - disconnect
[ 271.516481] wlan1: failed to follow AP c8:5b:a0:e7:34:64 bandwidth change, disconnect
@nbd168 need help this is totally broken 5G wifi AP + STA never works STA connected ok but AP cannot work on correct channel
I test on ath10k or mt76 with latest openwrt code, all broken.
I have the same issue with my Fritzbox 4040 and Archer C7 V5.
DFS Channels work only if you "fix" the AP Channel, "Auto" does not work.
I can confirm this, I get the same behaviour. Can you please take a look?
@nbd168 ping need help on this issue.
I am trying to fix it here https://github.com/openwrt/openwrt/pull/4904 maybe you could test it @Suxsem @ychromosome @orangepizza
Just here to +1 this report. I have a similar or related problem. .. or maybe not, IDK.
Critical specs: OpenWRT device: TP-Link Archer C7 v2. OpenWRT version: OpenWrt 22.03.4 r20123-38ccc47687 / LuCI openwrt-22.03 branch git-23.093.57104-ce20b4a Kernel version: 5.10.176
In my case, I set up my Archer C7 as an isolated subnet then use WiFi in client mode to handle connecting to the upstream gateway. This network design architecture has worked very well for me at my last residence, but at my new place (new gateway device) I'm getting frequent disconnects at regular intervals.
The error messages are the very same daemon.err hostapd: Wrong coupling between HT and VHT/HE channel setting
.
I also think the problem is taking out the WiFi network as a whole too, as another device attached in parallel to the same WiFi gateway loses connection at the same time the Archer C7 does.
Update openwrt to the most recent release (23.05 or 22.03) and try again
Not sure if you are talking to me, as, from my last post, you can see that I'm on OpenWrt 22.03... but I'll try and update to 23.05 I guess....
LOL.... sigh..... Probably ignore me.
... looking through my config and logs I saw an error/warning that reminded me... I had created an ad-hoc keep alive cron script that essentially pinged the gateway and, if not found, would reset the network.... of course... the IP to the gateway was hardcoded and no longer the same now that I moved. It was likely a coincidence that I also had the aforementioned error as well.
The good news, my keep alive script worked as intended. Here it is if anyone else want's to set themselves up for problems later down the road. :D
* * * * * if [ $? -eq 0 ] | ping -c4 192.168.1.1 > /dev/null; then exit 0; else /etc/init.d/network restart; fi
Not sure if you are talking to me, as, from my last post, you can see that I'm on OpenWrt 22.03... but I'll try and update to 23.05 I guess....
to you. either 22.03.7 (but still broken probably) or 23.05.5 or snapshot 24.10.
set
option channel 'auto'
and the 5Ghz wifi would keep in 5Ghz and no wifi signal scan by my phone/PCThe latest code in master branch.