You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been testing wifi and wifi to ethernet bridging using the eth2ap code sample (wifi in AP mode).
Testing connectivity with two or more stations connected (stations mutually pinging themselves and the gateway on the ethernet) we have observed the following issue:
When one of those station is disconnected (e.g. by manually disabling wifi on that station or roaming to a different AP), all stations on the esp32 access point loose connectivity (mutual and to gateway). So no packets are transported any more. In the terminal log of esp32 only the disconnected station is logged ("leave"). There is no event logged of any status change of the other stations.
Network connectivity is restored by either:
A. connecting the disconnected station again (!!!)
B. reconnecting (authenticate+associate) the other stations (e.g. be toggling wifi off / on)
C. rebooting the esp32 - which in consequence leeds to a reconnection of the stations presumably caused by the beacon sequence number being reset.
B. + C. obviously just restore the network connection from plain disconnnected state.
A. is the most interesting case as it seems to indicate an issue in the wifi driver of esp32.
We have also traced the 802.11 packets on the air. In case of erroneous disconnectivity the esp32 module does not send dis-assoc or de-auth frames to the stations as a response to any of the packets of the stations arriving. So at that level the esp32 treats the stations as being connected (i.e. still authenticated and associated).
Expected Behavior
Actual Behavior
Steps to reproduce
see above.
Code to reproduce this issue
esp-idf code sample eth2ap
Any ideas how to solve that issue?
Best Regards, Josef
The text was updated successfully, but these errors were encountered:
github-actionsbot
changed the title
wifi : network failure when one of serveral wifi clients disconnects
wifi : network failure when one of serveral wifi clients disconnects (IDFGH-2997)
Mar 30, 2020
@seppf Thanks for reporting, we noticed the issue and already have a fix internally now under reviewing, will update once it is available on GitHub. Thanks.
seppf
changed the title
wifi : network failure when one of serveral wifi clients disconnects (IDFGH-2997)
wifi : network failure when one of several wifi clients disconnects (IDFGH-2997)
Apr 1, 2020
Environment
Problem Description
We have been testing wifi and wifi to ethernet bridging using the eth2ap code sample (wifi in AP mode).
Testing connectivity with two or more stations connected (stations mutually pinging themselves and the gateway on the ethernet) we have observed the following issue:
When one of those station is disconnected (e.g. by manually disabling wifi on that station or roaming to a different AP), all stations on the esp32 access point loose connectivity (mutual and to gateway). So no packets are transported any more. In the terminal log of esp32 only the disconnected station is logged ("leave"). There is no event logged of any status change of the other stations.
Network connectivity is restored by either:
A. connecting the disconnected station again (!!!)
B. reconnecting (authenticate+associate) the other stations (e.g. be toggling wifi off / on)
C. rebooting the esp32 - which in consequence leeds to a reconnection of the stations presumably caused by the beacon sequence number being reset.
B. + C. obviously just restore the network connection from plain disconnnected state.
A. is the most interesting case as it seems to indicate an issue in the wifi driver of esp32.
We have also traced the 802.11 packets on the air. In case of erroneous disconnectivity the esp32 module does not send dis-assoc or de-auth frames to the stations as a response to any of the packets of the stations arriving. So at that level the esp32 treats the stations as being connected (i.e. still authenticated and associated).
Expected Behavior
Actual Behavior
Steps to reproduce
see above.
Code to reproduce this issue
esp-idf code sample eth2ap
Any ideas how to solve that issue?
Best Regards, Josef
The text was updated successfully, but these errors were encountered: