Wifi-qcom-ac problem after upgraded to 7.13.4
I have some hap ac2 routers. After upgraded to 7.13.4 and use the wifi-qcom-ac module, my esp32 devices and xiaomi cleaning robot (all using 2.4G wifi) are being disconnected once connected to routers. If I change the wifi module to 'wireless', everything works fine. But I prefer to use the wifi-qcom-ac module. Any suggestions?
Last edited by ykleet on Sat Feb 24, 2024 5:17 pm, edited 1 time in total.
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
What log say?
Can u show ur config?
Can u show ur config?
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
Try to deactivate protected management frames.
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
Most likely config problem.
So yes, show the config.
So yes, show the config.
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
As I am using 'wireless' module on my routers now, need some time to switch it back to wifi-qcom-ac and dump the config and log. Btw, other 2.4G devices, such as mobile devices and pc, have no connection problem when using wifi-qcom-ac. Thank you.
Last edited by ykleet on Sat Feb 24, 2024 5:31 pm, edited 1 time in total.
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
Avoid WPA3 for ssid connecting to IoT stuff.
If needed setup a virtual ssid only for that.
If needed setup a virtual ssid only for that.
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
This, 100%, right here.Avoid WPA3 for ssid connecting to IoT stuff.
If needed setup a virtual ssid only for that.
Soooo many things that you'd never expect have all sorts of "quirks"/issues with WPA3... even the latest intel wireless chipsets/drivers for laptops.
WPA3 is a wonderful security upgrade and long overdue but so many things need to catch up before it's viable to just "set it and forget it" like we can with WPA2 things. Don't even offer WPA3 on general SSID for IOT things especially unless you really need the modernized features... the devices just aren't there yet... Some things that think they support WPA3, which really only support "wpa3 in a very specific configuration that may not be documented" will try to use it and fail to connect, over and over again, without failing-back to wpa2 which would work just fine. Even Intel's PC drivers are terrible with that.
WPA2-PSK, and management frame protection optional-at-best, disabled-more-likely to be successful, for IOT and anything "older".
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
With WPA3 I have not had problems with IoT equipment, not even with the oldest ones, only with mobile phones, even the most modern ones like the iPhone 14, connection and disconnection problems, sometimes they spend up to 24 hours connected, others not even 10 minutes. When I remove WPA3 the problems end.
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
Thank you for your helps.
I did some tests on the problem again using wifi-qcom-ac module (ver 7.13.14）.
1) hard reset the ac2 router
2) enable wireless logging
3) Add 'Inhouse' as ssid to 2.4G interface
4) wpa2 only password
Result:
If esp32 device is the only device connect to the ssid, it keeps being connected and disconnected.
The wifi debugging info shown: wifi1 disassociated, connection lost, signal strength -28
and next line shown: wifi1 associated, signal strength -27
But if I connected to the ssid using a mobile first, then the esp32 can connect to the ssid right away. I also performed the test on a virtual interface and got the same result. Disable 'Management Protection' did not kill the ill too.
I did some tests on the problem again using wifi-qcom-ac module (ver 7.13.14）.
1) hard reset the ac2 router
2) enable wireless logging
3) Add 'Inhouse' as ssid to 2.4G interface
4) wpa2 only password
Result:
If esp32 device is the only device connect to the ssid, it keeps being connected and disconnected.
The wifi debugging info shown: wifi1 disassociated, connection lost, signal strength -28
and next line shown: wifi1 associated, signal strength -27
But if I connected to the ssid using a mobile first, then the esp32 can connect to the ssid right away. I also performed the test on a virtual interface and got the same result. Disable 'Management Protection' did not kill the ill too.
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
But if I connected to the ssid using a mobile first, then the esp32 can connect to the ssid right away. I also performed the test on a virtual interface and got the same result.
Try to set disable-running-check=yes on wifi interface(s).
Reasoning: when there are no stations connected to AP, wifi interface status changes to "not running", which in turn makes associated bridge port status to "inactive". When first station connects, wifi interface transitions to "running" which makes bridge port transition into "active". And that triggers xSTP (if enabled, by default it is) to check for any loops. This takes a few seconds (much longer if bridge mode is set to STP) and during that time, wireless station can not communicate ... e.g. it can't get DHCP lease. Some stations are short tempered and may disconnect before xSTP magic can finally enable the bridge port.
The setting I mentioned disables status transitions of wifi interface so bridge port is always active. It is possible to create a loop using wifi link, but much harder than using a patch cable between two ports of same switch. So disabling running check is pretty safe IMO.
And, BTW, your ESP32 device is way too close to hAP ac2, signal strengths higher than -35dBm or -40dBm tend to overwhelm receivers which in turn sense distorted signal and thus drop in performance.
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
But if I connected to the ssid using a mobile first, then the esp32 can connect to the ssid right away. I also performed the test on a virtual interface and got the same result.
Try to set disable-running-check=yes on wifi interface(s).
Reasoning: when there are no stations connected to AP, wifi interface status changes to "not running", which in turn makes associated bridge port status to "inactive". When first station connects, wifi interface transitions to "running" which makes bridge port transition into "active". And that triggers xSTP (if enabled, by default it is) to check for any loops. This takes a few seconds (much longer if bridge mode is set to STP) and during that time, wireless station can not communicate ... e.g. it can't get DHCP lease. Some stations are short tempered and may disconnect before xSTP magic can finally enable the bridge port.
The setting I mentioned disables status transitions of wifi interface so bridge port is always active. It is possible to create a loop using wifi link, but much harder than using a patch cable between two ports of same switch. So disabling running check is pretty safe IMO.
And, BTW, your ESP32 device is way too close to hAP ac2, signal strengths higher than -35dBm or -40dBm tend to overwhelm receivers which in turn sense distorted signal and thus drop in performance.
It works like a charm. Thank you very much for your advice.
-
-
Nullcaller
Member Candidate
- Posts: 122
- Joined:
Re: Wifi-qcom-ac problem after upgraded to 7.13.4
You might want to consider disabling STP on a home network entirely, by the way.
Home networks are usually dead simple, so the probability of accidentally creating a loop is near-zero. And even if your luck is really bad, home networks are usually dead simple, so you'll find it in near-zero time. There's also no mistaking a loop when it comes to diagnosing what is wrong with the network.
All STP thus does on a home network is save you from the trouble of finding a loop every three to ten years, at the cost of you having to wait two to three seconds every time you connect to an AP, which includes switching from one AP to another in a network with multiple APs <rambling>(which should be any network, since one AP is rarely enough, unless you're living in the US, where walls are often made of hopes and prayers).
With cached content it's not so bad, but with anything live, or if you happen to be using your phone as you pass between rooms, you're gonna experience the "why is my internet so bad" sensation, which is unpleasant.</rambling>
Home networks are usually dead simple, so the probability of accidentally creating a loop is near-zero. And even if your luck is really bad, home networks are usually dead simple, so you'll find it in near-zero time. There's also no mistaking a loop when it comes to diagnosing what is wrong with the network.
All STP thus does on a home network is save you from the trouble of finding a loop every three to ten years, at the cost of you having to wait two to three seconds every time you connect to an AP, which includes switching from one AP to another in a network with multiple APs <rambling>(which should be any network, since one AP is rarely enough, unless you're living in the US, where walls are often made of hopes and prayers).
With cached content it's not so bad, but with anything live, or if you happen to be using your phone as you pass between rooms, you're gonna experience the "why is my internet so bad" sensation, which is unpleasant.</rambling>
Who is online
Users browsing this forum: Ahrefs [Bot], Google [Bot] and 5 guests