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
Please update the binaries to ESP-IDF 4.2+. Without this upstream fix, if the internet connection is down it can "brick" Wi-Fi on devices for hours on a failure in internet connectivity. Even after connectivity is restored, or even if the device is power-cycled, it can still fail to connect to the router, or it can generate numerous wifi:esf_buf errors. After a few hours, the devices start working again.
Once I upgraded to ESP-IDF 4.2 for my own custom firmware, this problem disappeared, as per the upstream fix.
Hardware used:
ESP32-WROVER-E 16MB (Lolin D32 Pro)
ESP32-WROVER-IE 8MB (ESP32_DevKitc_V4)
Firmwares used:
esp32spiram-20220117-v1.18.bin
Custom firmware based on v1.18
Steps to reproduce:
Disconnect upstream modem connectivity but leave router online
Attempt to connect to router using code below
When it fails, unplug the ESP32 from power
Reconnect internet, confirm connectivity with your laptop
Plug in device and try again
If it fails, unplug it for a few hours
Confirm connectivity still good
Should start working again
To resolve:
Upgrade ESP-IDF to 4.2+
Recompile firmware
Flash to device
Code used:
import network
sta_if = network.WLAN(network.STA_IF)
sta_if.active(True)
sta_if.connect('MYSSID', 'MYPASSPHRASE')
# Repeatedly paste this command several times until about 60 seconds goes by. Sometimes even when there is connectivity, connection is slow and this should eventually show an IP.
sta_if.ifconfig()
Errors shown:
E (83336) wifi:sta is connecting, return error
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: Wifi Internal Error
Or sometimes:
E (45979) wifi:esf_buf: t=2 l=76 max:32, alloc:32 no eb, TXQ_BLOCK=0
W (45979) wifi:alloc eb len=76 type=2 fail, heap:151108
W (45979) wifi:m f probe req l=0
E (46099) wifi:esf_buf: t=2 l=76 max:32, alloc:32 no eb, TXQ_BLOCK=0
W (46099) wifi:alloc eb len=76 type=2 fail, heap:151108
W (46099) wifi:m f probe req l=0
E (46229) wifi:esf_buf: t=2 l=76 max:32, alloc:32 no eb, TXQ_BLOCK=0
W (46229) wifi:alloc eb len=76 type=2 fail, heap:151108
W (46229) wifi:m f probe req l=0
...
The text was updated successfully, but these errors were encountered:
BetterAutomations
changed the title
Wi-Fi "bricked" for hours when internet connectivity fails
Wi-Fi "bricked" for hours when internet connectivity fails, even after being restored
Apr 11, 2022
BetterAutomations
changed the title
Wi-Fi "bricked" for hours when internet connectivity fails, even after being restored
Wi-Fi "bricked" for hours when internet connectivity fails, even after connectivity restored
Apr 11, 2022
BetterAutomations
changed the title
Wi-Fi "bricked" for hours when internet connectivity fails, even after connectivity restored
ESP32 Wi-Fi "bricked" for hours when internet connectivity fails, even after connectivity restored
Apr 11, 2022
The esp32 firmware available at https://micropython.org/download uses IDF v4.2.2 (or v4.4 for S2, S3, C3 variants). So I think they should be OK, they should include this fix?
Hmm. I know that when I switched my custom firmware from 4.0 to 4.2 the problem disappeared, and I had assumed that because the compilation instructions suggest to use 4.0.2 that the firmware at the download site had used 4.0.2. Perhaps at least update the README.md.
Are you able to reproduce the errors above using the firmware I mentioned? Perhaps there is another cause.
tannewt
pushed a commit
to tannewt/circuitpython
that referenced
this issue
Oct 25, 2023
Please update the binaries to ESP-IDF 4.2+. Without this upstream fix, if the internet connection is down it can "brick" Wi-Fi on devices for hours on a failure in internet connectivity. Even after connectivity is restored, or even if the device is power-cycled, it can still fail to connect to the router, or it can generate numerous wifi:esf_buf errors. After a few hours, the devices start working again.
The fix:
espressif/esp-idf@5a0124a
The discussion on the ESP-IDF Github:
espressif/esp-idf#5391
Once I upgraded to ESP-IDF 4.2 for my own custom firmware, this problem disappeared, as per the upstream fix.
Hardware used:
Firmwares used:
Steps to reproduce:
To resolve:
Code used:
Errors shown:
Or sometimes:
The text was updated successfully, but these errors were encountered: