ARP stops working after a few minutes when running in softAP mode

[chrishamm]

I've been trying to get esp-open-rtos running on my ESP8266 and it seems to work nicely when running in station mode, but when I change to softAP mode and try to ping the IP address, it stops responding after a few minutes. When I open Wireshark, I can see that it no longer responds to ARP requests.

The symptoms are equal to this report on the Arduino port: https://github.com/esp8266/Arduino/issues/2330

[ourairquality]

Please give the patch in https://github.com/SuperHouse/esp-open-rtos/pull/389 a try, it resolved at least one show stopper that made softap mode unusable in practice, in the case that multiple devices connected it would break and stop - might as well eliminate that.

[chrishamm]

Thanks for that patch, I cherry-picked your PR and updated the LwIP submodule. However I'm afraid it breaks the sdk_wifi_set_opmode() function. Whenever I call it, I get an exception on my NodeMCU/ESP12E. Here the log:

pp_task_hdl : 3fff1dd0, prio:14, stack:512 pm_task_hdl : 3fff2a30, prio:1, stack:176 frc2_timer_task_hdl:3fff5a28, prio:12, stack:200

ESP-Open-SDK ver: 0.0.1 compiled @ Jul 5 2017 09:27:45 phy ver: 273, pp ver: 8.3

Duet WiFi Server starting... SDK version: 0.9.9 Init complete mode : null Connections: free free free free free free free free Switching to STATION_MODE mode : sta(5c:cf:7f:1a:98:2e) Fatal exception (28): epc1=0x40203514 epc2=0x00000000 epc3=0x40202782 excvaddr=0x00000038 depc=0x00000000 excsave1=0x40203511 Registers: a0 40203511 a1 3fff8290 a2 3fff0e7c a3 00000001 a4 00000020 a5 00000000 a6 00ff0000 a7 ff000000 a8 00000000 a9 00000000 a10 00001a7f a11 0000000a a12 00000000 a13 00000000 SAR 0000001f

Stack: SP=0x3fff8290 0x3fff8290: 40217754 00000000 3ffe800c 40106e5c 0x3fff82a0: ffffffff 00000000 ffffffff 00000002 0x3fff82b0: 00000002 00000001 a5302078 3fff1088 0x3fff82c0: 40215d98 00000008 00000000 4020bbc4 0x3fff82d0: a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5

Free Heap: 33252 _heap_start 0x3fff1bc0 brk 0x3fff8598 supervisor sp 0x3ffffb00 sp-brk 30056 bytes arena (total_size) 27096 fordblks (free_size) 3196 uordblocks (used_size) 23900

Investigating this didn't show anything useful to me, because addr2line only resolved the following addresses:

0x40203514 /home/christian/duet/esp-open-rtos/FreeRTOS/Source/queue.c:1610 0x40202782 /home/christian/duet/esp-open-rtos/FreeRTOS/Source/tasks.c:4173 0x40203511 /home/christian/duet/esp-open-rtos/FreeRTOS/Source/queue.c:1610 40203511 /home/christian/duet/esp-open-rtos/FreeRTOS/Source/queue.c:1610 40217754 ??:? 40106e5c /home/gus/dev/esp/rtos/newlib/build/xtensa-lx106-elf/newlib/libc/stdio/../../../../../newlib/libc/stdio/nano-vfprintf.c:531 40215d98 ??:? 4020bbc4 /home/christian/duet/esp-open-rtos/core/sysparam.c:73

I tried the http_get example as well, but even that causes a boot loop - probably due to the same error.

[ourairquality]

That is unexpected, it runs relatively robustly here. Just to eliminate that it has been corrected would be be prepared to try a fresh tree from https://github.com/ourairquality/esp-open-rtos which I test.

[chrishamm]

Hmm, I just cloned your entire repository and tried to build the http_get example once more, but the same problem persists:

pp_task_hdl : 3fff1628, prio:14, stack:512 pm_task_hdl : 3fff2288, prio:1, stack:176 frc2_timer_task_hdl:0x3fff5220, prio:12, stack:200

ESP-Open-SDK ver: 0.0.1 compiled @ Jul 5 2017 10:47:44 phy ver: 273, pp ver: 8.3

SDK version:0.9.9 mode : sta(5c:cf:7f:1a:98:2e) Fatal exception (28): epc1=0x402039ee epc2=0x00000000 epc3=0x4022792e excvaddr=0x00000038 depc=0x00000000 excsave1=0x402039eb Registers: a0 402039eb a1 3fff3fb0 a2 3fff0f14 a3 00000001 a4 00000020 a5 0000ff00 a6 00ff0000 a7 ff000000 a8 00000000 a9 00000000 a10 00001a7f a11 0000000a a12 00000000 a13 00000000 SAR 0000001f

Stack: SP=0x3fff3fb0 0x3fff3fb0: 40216ae0 00000000 3ffe800c 40106d6c 0x3fff3fc0: ffffffff ffffffff ffffffff 00000002 0x3fff3fd0: 00000002 00000001 3f302078 40215734 0x3fff3fe0: 00000008 00000000 3fff1134 4020c7dc 0x3fff3ff0: 00000003 40217f73 3ffe800c 4020233c 0x3fff4000: 006532e0 00007802 40216ba8 3fff5870 0x3fff4010: 3fff4044 3fff4040 00000000 00000000 0x3fff4020: 3fff4080 3fff4070 00000004 40203cd0

Free Heap: 40512 _heap_start 0x3fff1418 brk 0x3fff5cc0 supervisor sp 0x3ffffb00 sp-brk 40512 bytes arena (total_size) 18600 fordblks (free_size) 0 uordblocks (used_size) 18600

Please let me know if you have any more ideas.

[ourairquality]

Sorry, that tree had it's lwip revision out of sync, and I am surprised it even checked out without issues. Could you please try again, and also erase the flash fully just to discount that. A fresh clone and build of http_get worked here, so it would be hard for me to narrow it down.

[chrishamm]

Thanks, but that doesn't seem to make a difference - in fact the resulting firmware binary is just as big as the other one. Hence I enabled debugging in lwipopts.h which allowed me to capture this:

pp_task_hdl : 3fff1628, prio:14, stack:512 pm_task_hdl : 3fff2288, prio:1, stack:176 dns_init: initializing sys_timeout: 0x3fff2338 msecs=1000 handler=cyclic_timer arg=0x4021baf0 sys_timeout: 0x3fff2350 msecs=60000 handler=cyclic_timer arg=0x4021bafc sys_timeout: 0x3fff2370 msecs=500 handler=cyclic_timer arg=0x4021bb08 sys_timeout: 0x3fff2388 msecs=1000 handler=cyclic_timer arg=0x4021bb14 frc2_timer_task_hdl:0x3fff5230, prio:12, stack:200

ESP-Open-SDK ver: 0.0.1 compiled @ Jul 5 2017 12:47:11 phy ver: 273, pp ver: 8.3

SDK version:0.9.9 mode : sta(5c:cf:7f:1a:98:2e) netif: IP address of interface f set to 0.0.0.0 Fatal exception (28): epc1=0x402039ee epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000038 depc=0x00000000 bpbll`pp_task_hdl : 3fff1628, prio:14, stack:512 pm_task_hdl : 3fff2288, prio:1, stack:176 dns_init: initializing sys_timeout: 0x3fff2338 msecs=1000 handler=cyclic_timer arg=0x4021baf0 sys_timeout: 0x3fff2350 msecs=60000 handler=cyclic_timer arg=0x4021bafc sys_timeout: 0x3fff2370 msecs=500 handler=cyclic_timer arg=0x4021bb08 sys_timeout: 0x3fff2388 msecs=1000 handler=cyclic_timer arg=0x4021bb14 frc2_timer_task_hdl:0x3fff5230, prio:12, stack:200

ESP-Open-SDK ver: 0.0.1 compiled @ Jul 5 2017 12:47:11 phy ver: 273, pp ver: 8.3

SDK version:0.9.9 mode : sta(5c:cf:7f:1a:98:2e) netif: IP address of interface f set to 0.0.0.0 Fatal exception (28): epc1=0x402039ee epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000038 depc=0x00000000 excsave1=0x402039eb Registers: a0 402039eb a1 3fff3fb0 a2 3fff0f14 a3 00000001 a4 00000020 a5 0000ff00 a6 00ff0000 a7 ff000000 a8 00000000 a9 000000a0 a10 3fff14dc a11 0000000a a12 00000000 a13 00000000 SAR 0000001f

Stack: SP=0x3fff3fb0 0x3fff3fb0: 3fff4010 3fff4000 00000024 00000001 0x3fff3fc0: ffffffff 00000001 3ffe800c 40106d6c 0x3fff3fd0: 00000004 ffffffff ffffffff 4021a86c 0x3fff3fe0: 00000008 00000000 3fff1138 40210850 0x3fff3ff0: 3fff4010 3fff4000 00000004 40105fea 0x3fff4000: 00000003 000000cb 00000066 00000000 0x3fff4010: 3fff4044 3fff4040 40221948 3fff5880 0x3fff4020: 00000000 3fff13f4 3fff5c98 3fff13f8

Free Heap: 40496 _heap_start 0x3fff1418 brk 0x3fff5cd0 supervisor sp 0x3ffffb00 sp-brk 40496 bytes arena (total_size) 18616 fordblks (free_size) 0 uordblocks (used_size) 18616

So I suspect the network interface isn't properly assigned/initialised, but I'm not sure how this could be resolved.

[ourairquality]

Thank you for trying. Perhaps we would better take this off list as it could be a lot of noise to narrow down. Could you email me 'info at ourairquality.org' and I'll email back my build to try, and perhaps we can iterate to narrow it down.