-
Notifications
You must be signed in to change notification settings - Fork 13.3k
SoftAP never populates station info after short power-off cycle #3638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@me-no-dev @igrr : This looks like a bug in the low-level closed-source SDK. If a work-around existed (other than telling the user to power off for 60 seconds), I would take it. But I tried restarting the SoftAP by setting mode to none and then back to SoftAP, and that didn't help. |
Edit: i see now that you have raised the issue in the nonOS SDK issue tracker, which might prevent BBP report from being accepted. |
WiFi.mode() would require a delay at the end (returns before being done, it's an asyn sequence). Without it, a call to softAP immediately afterwards could fail. This has been addressed with #6721 , with the restriction that the delay happens only when called from CONT context. When calling from SYS (e.g.: wifi event, Ticker), it's up to the user to serialize a waiting task (e.g.: Ticker). |
Basic Information
This is a copy of the issue espressif/ESP8266_NONOS_SDK#43, because my test case is an Arduino sketch, and I would take a workaround to force the station info to re-populate, if one existed.
https://github.com/esp8266/Arduino + https://github.com/plerup/makeEspArduino
Problem has been reproduced with https://github.com/esp8266/Arduino at master, 2.4.0-rc1, and update_sdk_2.1.0.
Description
The SoftAP never populates station info list after short power-off cycle. It will behave normally when booting after a long power-off time, or when a client manually disconnects and then reconnects.
But after only a short power-cycle, the client will automatically reconnect but not be included in the station info list. It will report the correct number of authenticated stations in wifi_softap_get_station_num(), but will not refresh their DHCP lease or add them to the list accessible via wifi_softap_get_station_info().
Sketch
Debug Messages
As you can see, the low-level debug output goes through the same sequence of events in both cases. In the short power-off case, the "wifi evt: 5" station connected event does trigger the user station connected handler, and count the client in the number of connected stations. The PC client actually connects, and reuses their previous DHCP lease, but the lease isn't refreshed (no dhcp client output in syslog), and the client list doesn't contain any items in the linked list.
The text was updated successfully, but these errors were encountered: