wifi: bcn_timout,ap_probe_send_start (IDFGH-83) #1021
Comments
|
Possibly related to #974 |
FayeY
changed the title
|
Any news yet? I (62062) wifi: n:6 0, o:6 0, ap:255 255, sta:6 0, prof:1 D (62092) tcpip_adapter: if0 start ip lost tmr: enter V (62112) event: exit default callback And so on. Also reconnect does not work |
|
Yes i get this error too!, I use aws iot mqtt pub sub and a tcp server, when too many messages are sent, wifi timeout and refuses to connect again, tried many things like disconnecting and connecting again, but only way is to restart the esp module. Any workaround for this? |
|
Hi, ESP-IDF branch: release/v3.0 updated at commit 0ebae99 (17 dec 2017) |
|
Solved , see post: |
|
@jasslo @ricksondpenha things you can do to check what's the problem: |
|
Hi, |
|
@0BackDoor1 Can you capture the packets in the air？ |
|
@jack0c my issue doesn't occur anymore with IDF updated to latest commit available, good! |
|
@0BackDoor1 Can you give commit you use. Maybe can help us and other developers. Thanks! |
|
I'm experiencing this as well. From reading this thread, and the one referenced above, it's still not clear to me whether this has been fixed, and whether it requires a change to user code. Can someone elucidate? Thanks... |
|
Is there any update? I also experience this issue
I (121489) wifi: n:7 0, o:7 0, ap:255 255, sta:7 0, prof:1 |
|
@NOA-Vernon first of all ensure to have IDF updated, the same issue occurs if the free heap size (esp_get_free_heap_size) is too low, don't know if this could help on your case |
|
@0BackDoor1 thank you very much for the response, the IDF I used is ESP-IDF v3.1-dev-961-ga255622-dirty, the free heap size is around 50000, this issue still happened again and not have a solution yet. hoping there is anyone who can elucidate or point out the problems. |
|
This is reproducible easily using the power_save example source with the current esp-idf. I have seen it on two different mainstream routers using 100ms beacon interval and DTIM settings of 1 or 3. I feel like it happens much more often with DTIM=1. With DTIM=3 I have seen it run for 1/2 hour to 1 hour before getting bcn_timout and disconnecting. I am still testing trying to work around the disconnect. It seems like wifi gets messed up after and can't reconnect. I am using low power mode light sleep. Log: I (894) wifi: n:11 0, o:1 0, ap:255 255, sta:11 0, prof:1 I (2904) power_save: Unknown system event 4 I (209594) wifi: bcn_timout,ap_probe_send_start I (212104) wifi: n:11 0, o:11 0, ap:255 255, sta:11 0, prof:1 |
|
Have anyone resolve this issue. I am facing same. I think it is due to interval ram less available. but with external RAM. I get wifi alloc error. |
|
I was able to work around it by running both cores at 266 mHz. I suspect it is wake timing related. Not my plan for the long term. I hope it gets looked at. |
|
Yes I am only using one core. I think two cores with external RAM is not stable and safe on Esp32. I am using Http Web server with SD card. I am getting similar error I am using WIFI with external RAM. Internal Heap free: 41120 Plenty of external ram and some internal RAM. Does in default settings WIFI only uses internal ram. |
|
@snahmad If you are using TLS and have 41k internal free, you will likely run out of memory due to TLS connections. Read through the comments on #2184 to see how you can switch to using external RAM for TLS, or see if you can free up more internal RAM. In my tests it seems like each TLS connection takes > 20kB of internal RAM. |
|
I am not using TSL yet. in future may be. |
|
Why WIFI is using external RAM. I need to specify for both Tx and RX static buffer on internal RAM only for Wifi. W (6548) wifi: m f probe req l=0 W (6699) wifi: alloc eb len=76 type=2 fail, heap:4192980 W (6700) wifi: m f probe req l=0 Stack free: 6396 |
|
Any progress I am having this issue too |
|
You mean run-out internal ram. you can specify to use only static ram for Wifi in menuonfig. |
|
@dalerks, what's your issue? beacon timeout or the log "m f probe req l=0" is displayed? Could you paste your error log here? |
|
W (351669) wifi: alloc eb len=24 type=3 fail, heap:88 W (351669) wifi: m f null I (357609) wifi: bcn_timout,ap_probe_send_start W (357609) wifi: m f probe req l=0 W (358109) wifi: alloc eb len=76 type=2 fail, heap:88 W (358109) wifi: m f probe req l=0 W (358609) wifi: alloc eb len=76 type=2 fail, heap:88 W (358609) wifi: m f probe req l=0 W (359109) wifi: alloc eb len=76 type=2 fail, heap:88 W (359109) wifi: m f probe req l=0 W (359609) wifi: alloc eb len=76 type=2 fail, heap:88 W (359609) wifi: m f probe req l=0 I (360109) wifi: ap_probe_send over, resett wifi status to disassoc W (360119) wifi: m f disassoc I (360119) wifi: pm stop, total sleep time: 290332841 us / 355180847 us I (360129) wifi: new:<10,0>, old:<10,0>, ap:<255,255>, sta:<10,0>, prof:1 I (362489) AirCylcer: Event called |
|
HI @dalerks , for "alloc eb fail" issue, please refer to: #3044 In WiFi driver, the TX management frames, such as beacon, probe request, probe response etc, are categorized to following type:
Generally, the "alloc eb fail" error has following reasons:
|
projectgus
changed the title
|
@jasslo Thanks for reporting the issue, feel free to reopen the issue if it still exists. Thanks. |
|
I also had this problem. I solved it with the following method. |
|
I am getting this issue occasionally, as i am reading this it seems it only happens when flashing a lot and then only occasionally. |
|
Hi @ZweiEuro, could you provide following info:
|
|
我将idf版本从4.2升级到4.3后解决了这个问题。 |
Hi,
I have on my ESP32 simple web server, which get data from esp8266 thru get requests and display it on web page. In future ESP32 will send this data to thingspeak or something like that. Everything works fine, but after few minutes it crash and display on monitor:
This information will be displaying over and over.
I must mention that in the beginning wifi is in AP mode and we can configure sta ssid and password and then wifi is switched to ap+sta mode.
Someone maybe have idea what is wrong ?
Thanks in advance.
The text was updated successfully, but these errors were encountered: