Crashing in Factory Setup after reload, general instability about lws-esp32-factory HOT 17 CLOSED

I could reproduce it with esp-idf from a few days ago that I had.

Can't reproduce it with today's esp-idf 8f9707fd07571293954c3b36e2e7532b500dd758

Generally lws doesn't do anything special for AP mode. If it's blowing up in AP mode, it's most likely esp-idf. Please try updating that.

from lws-esp32-factory.

I'm seeing this same error, using that same esp-idf commit ending 00dd758

from lws-esp32-factory.

Yes it works better with that version of esp-idf.

Sometimes it shows
1: ERROR on accept:
but continues working.

Yes could really be an issue with esp-idf, I had some problems too with AP.

But it is still crashing after reloading some times.

from lws-esp32-factory.

@tedwoodt25 you see the same error if refreshing the browser? Or also the first time?

It feels like some race regarding socket close. But on my side I call close() there's not supposed to be something else to do because AP mode; this does not exist in station mode. So I don't see what I should / can do about this.

from lws-esp32-factory.

It seems to occur at the point where I try to join the AP, which as you say suggests a problem in esp-idf.

It doesn't always happen - about 10% of attempts to connect to the AP are successful

from lws-esp32-factory.

Hm...

1. it ever dies the FIRST time you try to connect after reset?

2. It's exactly the same backtrace?

3. As I say I can no longer reproduce it here even camping on F5... it works. So maybe related to exact AP type you have? I dunno.

Either way, lws is not responsible for generic AP mode functionality... esp-idf is supposed to provide it... it can still be we need to do something different but I'm waiting for the clue as to what.

from lws-esp32-factory.

1. Yes. It dies the first time you try to connect. Although, even if you do connect it eventually dies. I haven't capture the GDB out from this yet
2. Backtrace exactly the same each time
3. Understood

from lws-esp32-factory.

For 2) I meant exactly the same backtrace as OP told on this bug... or something else?

from lws-esp32-factory.

No my back trace is different but repeatable. Addresses are all similar. I think he was using an older version of esp-idf Or we may have different configs I guess.

from lws-esp32-factory.

Aka "you may have some completely different problem".

Please send your BT when you are able to.

from lws-esp32-factory.

MONITOR
--- idf_monitor on /dev/cu.usbserial-DN02MUXN 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0008,len:8
load:0x3fff0010,len:2492
ho 0 tail 12 room 4
load:0x40078000,len:8920
ho 0 tail 12 room 4
load:0x40080000,len:252
0x40080000: _iram_start at ??:?

entry 0x40080034
0x40080034: _iram_start at ??:?

E (66) boot: force_factory 0 bs.ota_info.offset 53248

I (1038) cpu_start: Pro cpu up.
I (1039) cpu_start: Starting app cpu, entry point is 0x40080dd8
0x40080dd8: call_start_cpu1 at /Users/tedwood/RPK/esp-idf/components/esp32/./cpu_start.c:173

I (0) cpu_start: App cpu up.
I (1048) heap_alloc_caps: Initializing. RAM available for dynamic allocation:
I (1071) heap_alloc_caps: At 3FFAE2A0 len 00001D60 (7 KiB): DRAM
I (1091) heap_alloc_caps: At 3FFB9150 len 00026EB0 (155 KiB): DRAM
I (1112) heap_alloc_caps: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (1134) heap_alloc_caps: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1155) heap_alloc_caps: At 40092658 len 0000D9A8 (54 KiB): IRAM
I (1176) cpu_start: Pro cpu start user code
I (1235) cpu_start: Starting scheduler on PRO CPU.
I (204) cpu_start: Starting scheduler on APP CPU.
I (224) wifi: wifi firmware version: ba7c292
I (224) wifi: config NVS flash: enabled
I (224) wifi: config nano formating: disabled
I (244) wifi: Init dynamic tx buffer num: 32
I (244) wifi: Init dynamic rx buffer num: 50
I (244) wifi: wifi driver task: 3ffc0bb0, prio:23, stack:3584
I (244) wifi: Init static rx buffer num: 10
I (254) wifi: Init dynamic rx buffer num: 50
I (254) wifi: Init rx ampdu len mblock:7
I (254) wifi: Init lldesc rx ampdu entry mblock:4
I (264) wifi: wifi power manager task: 0x3ffc7494 prio: 21 stack: 2560
E (264) wifi: wifi_set_chan_range 1694 ret=1
I (274) wifi: wifi timer task: 3ffc84fc, prio:22, stack:3584
W (274) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration
I (504) phy: phy_version: 350, Mar 22 2017, 15:02:06, 1, 2
I (504) wifi: mode : sta (24:0a:c4:04:ad:d8) + softAP (24:0a:c4:04:ad:d9)
4: No SSL certs... using port 80
4: Initial logging level 63
4: Libwebsockets version: 2.2.0 [email protected]
4: IPV6 not compiled in
4: Threads: 1 each 30 fds
4: mem: platform fd map: 120 bytes
4: Compiled with OpenSSL support
4: SSL disabled: no LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT
4: mem: per-conn: 432 bytes + protocol rx buf
4: ROMFS length 164KiB
{
"schema": "lws1",
"model": "RPK",
"builder": "Teds-MacBook-Pro.local",
"app": "lws-esp32-factory",
"user": "tedwood",
"git": "2331748-dirty",
"date": "Fri 5 May 2017 12:22:25 BST",
"unixtime": "1493983345",
"file": "lws-esp32-factory-1493983345.bin",
"factory": "y"
}
4: Creating Vhost 'ap' port 80, 3 protocols, IPv6 off
4: mounting file:///ap to /
4: mounting callback://esplws-scan to /factory
4: mounting callback://esplws-ota to /otaform
4: setting mount default to factory
I (24824) wifi: n:6 0, o:6 0, ap:6 1, sta:0 0, prof:6
I (24824) wifi: station: a0:99:9b:0b:b4:99 join, AID=1, g, 20
W (24864) wifi: buffer null

4: esp32_lws_fops_open: /ap/factory.html
4: esp32_lws_fops_open: /ap/product.png
4: esp32_lws_fops_open: /ap/factory.png
4: esp32_lws_fops_open: /ap/ssl-pub.png
4: esp32_lws_fops_open: /ap/warning.png
W (31014) wifi: buffer null

W (31014) wifi: buffer null

4: esp32_lws_fops_open: /ap/ssl-pri.png
Guru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled.
Register dump:
PC : 0x400e0548 PS : 0x00060f30 A0 : 0x800e0f4a A1 : 0x3ffc22c0
0x400e0548: hostap_input at ??:?

A2 : 0x3ffcd2bc A3 : 0x3ffcdf7c A4 : 0x00000000 A5 : 0x3ffcd2bc
A6 : 0x3ffce218 A7 : 0x3ffb7ce4 A8 : 0x800e0544 A9 : 0x3ffc22a0
A10 : 0x00000000 A11 : 0x000000d9 A12 : 0x3ffcdf7c A13 : 0x3ffcd2bc
A14 : 0x00000000 A15 : 0x00000000 SAR : 0x00000019 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff

Backtrace: 0x400e0548:0x3ffc22c0 0x400e0f4a:0x3ffc2390 0x400f3388:0x3ffc23b0 0x400f4a96:0x3ffc2400
0x400e0548: hostap_input at ??:?

0x400e0f4a: ap_rx_cb at ??:?

0x400f3388: ppRxPkt at ??:?

0x400f4a96: ppTask at ??:?

from lws-esp32-factory.

Hm it says it blows in 0x4011f6d8: tcpip_adapter_ap_input at /Users/tedwood/RPK/esp-idf/components/tcpip_adapter/./tcpip_adapter_lwip.c:854

But I doubt it's true since it's the end of tcpip_adapter_get_sta_list() and nothing calls that from inside esp-idf AFAICT.

from lws-esp32-factory.

The addresses might not match but the call stack looks similar to the original report

from lws-esp32-factory.

Yes it's the same problem. But the backtrace source stuff seems wrong, so I don't have anywhere to go with it.

from lws-esp32-factory.

Today I am bringing up some new PCBs and spending more time with AP mode... looking at the PC address in the map file, it is actually dying in hostap_input as it says, which lives in their object-only library libnet80211.a.

The wrongly-reported source for the BT address can be looked up in the map file manually, it is the caller of hostap_input at tcpip_adapter_ap_input(), tcpip_adapter_lwip.c:809.

Dumping the args on that doesn't give any clue when it blows

E (101995) tcpip_adapter: buffer 0x3ffdf9dc, len 54, eb 0x3ffd8e0c
E (102005) tcpip_adapter: buffer 0x3ffe0910, len 54, eb 0x3ffd8e60
E (102015) tcpip_adapter: buffer 0x3ffdea10, len 54, eb 0x3ffd8284
Guru Meditation Error...

basically in blows in espressif's closed source 802111 library blob.

from lws-esp32-factory.

This appears to be fixed in latest esp-idf

from lws-esp32-factory.

Great... I meddled with sdkconfig and it went away here a few days ago. But I also updated esp-idf... at any rate it has been happy here.

from lws-esp32-factory.