wifi connect failures stuck in long timeout loop, autoreconnect on PMK failure is wrong #7968
Comments
|
tzapu/WiFiManager#1563 (comment) I have not had time to packet sniff anything |
|
@tablatronix Can you try this framework (easy with Platformio)? We (Tasmota) have timeout issues in lwip (DHCP) in some rare cases. This build uses a older lwip commit (IDF). Our issues are gone when using. |
|
@Jason2866 I will, I saw that when investigating last night but it did not sound exactly similar, Ill try it. |
|
I did not see any change with that repo, Do I need to wipe anything to force lwip in pio? |
|
unifi ap logs This could be a host issue, it should not be handling wrong password like this.. wrong pass on my iphone does the same thing.
|
|
That's my version |
|
It seems this is a normal PSK PMK failure, But this handling is new, so either these events were missing in previous sdk and handled by auth_fail, not sure how you can infer the difference now.. EIther way a 60s autoreconnect is too damn high.. lol |
|
@tablatronix Interesting. Are you saying the Autoreconnect is not working, or it's too aggressive and never fails? I agree that the UniFi AP may be sending back a wrong response on a bad password. |
|
It looks like adding autoreconnect to reason 15 was a bad idea, as bad passwords (depending on wpa config) will throw this error. Also autoreconnecting for 60s is way too long but we can pass custom timeout so not the main issue. |
|
Conclusion WL_CONNECTION_LOST is < WL_DISCONNECTED |
|
oh hey @mrengineer7777 you are the person that refactored this, I wasn't pulling git, thanks this needed a major cleaning up. A couple things I am looking at atm.
|
|
The good news is that my other deauth issue # is gone now, I can connect in 300ms.. |
|
My solution atm is to fail on this reason, and it is working ok.
if(reason == WIFI_REASON_ASSOC_LEAVE) { //Voluntarily disconnected. Don't reconnect!
}
if(reason == WIFI_REASON_4WAY_HANDSHAKE_TIMEOUT) { //Voluntarily disconnected. Don't reconnect!
WiFiSTAClass::_setStatus(WL_CONNECT_FAILED);
}
else if(first_connect) { //Retry once for all failure reasons
and exclude it from autoreconnect bool WiFiGenericClass::_isReconnectableReason(uint8_t reason) {
switch(reason) {
case WIFI_REASON_UNSPECIFIED:
//Timeouts (retry)
case WIFI_REASON_AUTH_EXPIRE:
// case WIFI_REASON_4WAY_HANDSHAKE_TIMEOUT:
case WIFI_REASON_GROUP_KEY_UPDATE_TIMEOUT: |
|
@tablatronix There was quite a bit of discussion on this. Please read here: #7210. It's been a while, but I believe Honestly the whole reconnect mechanism feels kludgy and it could use a re-write. However with the PR I submitted it works "well enough" and I really don't have time to write my own WiFi library from scratch. I developed and tested Probably unrelated: |
|
I figured those errors was due to a bug in PMF, similar to the binary change that was needed here. I would be curious to see if your spurious 4way timeouts are still occurring |
|
@tablatronix That was an interesting read. I'll have to turn off autoreconnect and see what kind of connection failures I am getting. I manage our UniFi AP at work, so I can also try turning on protected management frames (PMF) and see if that is an issue. Unfortunately I'm not setup for packet capture on wireless. Best I can give you is disconnect reason codes from the Arduino core. According to IDF release notes, PMF fix may have been added in IDF 4.4.2. Arduino-esp32 v2.0.5 includes 4.4.2. It is very possible it was fixed since I did my initial testing on v2.0.3. Anecdotally I sometimes still see WiFi disconnects shortly after a reboot, but the autoreconnect logic gets the device right back on the network. I'll do some testing. Ping me in 2 days if I forget. |
|
Yeah those are usually deauth protections and it makes you wait to prevent dos, usually there is a relevant packet descriptor, at least that is my assumption, never found a whitepaper or hostapd docs on that, and its probably not in spec. Alot of this stuff probably gets copied from cisco |
tablatronix
changed the title
|
I updated the title to clarify this is not a problem with trying to reconnect, its a problem with WPA2 connection fails, and they should not be retried, because this is the only event response to abort the connection. Hence we get stuck in a waitforconnectresult timeout. If there are legitimate auth or connection issues with 4-way timeouts then they should be handled special, waitFor.. I would revert this fix and readdress the bug it was intended to fix. In that case perhaps another single reconnect attempt limiter inside of firstconnect Another thing to test is does the spec or router implementations send another event after this timeout to explicitly say auth failed..? Maybe we just need to wait for that, I will see what i can find. Need a wifi engineer here... |
Jason2866
added
Status: Needs investigation
|
@tablatronix Released today a new core build based on latest IDF 4.4. A lot of changes are done since last release. Maybe it fixes the issue. |
|
@Jason2866 thanks, will check it out |
Parsaabasi
removed
the
Status: Needs investigation
|
Hello, Due to the overwhelming volume of issues currently being addressed, we have decided to close the previously received tickets. If you still require assistance or if the issue persists, please don't hesitate to reopen the ticket. Thanks. |
Board
esp32*
Device Description
devkit
Hardware Configuration
Version
v2.0.7
IDE Name
deviot
Operating System
osx
Flash frequency
40
PSRAM enabled
yes
Upload speed
921600
Description
On my Unifi APs
If I use wrong password I get this failure, instead of auth failure.
Auto reconnect gets stuck here for a very long time this will retry many many times then abort. (60s)
Similar issue with some auth protections
wifi:Association refused temporarilytzapu/WiFiManager#1563
Sketch
Debug Message
The text was updated successfully, but these errors were encountered: