Esp-idf: Wifi station sometimes unable to connect (IDFGH-46)
sometimes wifi station never connects and just immediately fires the disconnect event in response to connect request:
reason given is 201. there are no visible differences in initialization messages and there are no code differences - this just sometimes happens on our automated hardware test rig. it doesn't happen often, i'd say once in a couple dozen times.
AP is out of suspicion: at the very same time other hw tests, including on another esp32 device, connect to it just fine.
wifi messages for normal run:
E (2765) wifi: esp_wifi_get_mode 768 wifi is not init
mgos_wifi_set_mode WiFi mode: STA
E (2775) wifi: esp_wifi_set_mode 761 wifi is not init
I (2785) wifi: frc2_timer_task_hdl:3ffc1fac, prio:22, stack:2048
I (2795) wifi: Init lldesc rx mblock:25
I (2795) wifi: Init lldesc rx ampdu len mblock:7
I (2805) wifi: Init lldesc rx ampdu entry mblock:4
I (2815) wifi: pp_task_hdl : 3ffcfa6c, prio:23, stack:8192
E (2815) wifi: esp_wifi_connect 794 wifi not start
I (2825) wifi: mode : sta (24:0a:c4:00:39:f8)
event_handler event: 2
mgos_wifi_setup_sta WiFi STA: Connecting to Cesanta
mgos_i2c_create I2C initialized (SDA: 22, SCL: 23)
mgos_sys_config_init HTTP server started on [80]
mg_rpc_channel_mqtt 0x3ffd0fac docker-agent.2B2088A1119E6083/rpc
mg_rpc_channel_uart 0x3ffd1074 UART0
mgos_init Init done, RAM: 153684 free, 151108 min free
Tick
I (4465) wifi: n:11 0, o:1 0, ap:255 255, sta:11 0, prof:1
I (5025) wifi: state: init -> auth (b0)
I (5035) wifi: state: auth -> assoc (0)
Tock
I (5045) wifi: state: assoc -> run (10)
I (5055) wifi: connected with Cesanta, channel 11
mgos_wifi_on_change_ Wifi: connected
bad run:
E (2749) wifi: esp_wifi_get_mode 768 wifi is not init
mgos_wifi_set_mode WiFi mode: STA
E (2759) wifi: esp_wifi_set_mode 761 wifi is not init
I (2759) wifi: frc2_timer_task_hdl:3ffc131c, prio:22, stack:2048
I (2769) wifi: Init lldesc rx mblock:25
I (2779) wifi: Init lldesc rx ampdu len mblock:7
I (2779) wifi: Init lldesc rx ampdu entry mblock:4
I (2789) wifi: pp_task_hdl : 3ffced58, prio:23, stack:8192
E (2799) wifi: esp_wifi_connect 794 wifi not start
I (2799) wifi: mode : sta (24:0a:c4:00:39:f8)
event_handler event: 2
mgos_wifi_setup_sta WiFi STA: Connecting to Cesanta
mgos_sys_config_init HTTP server started on [80]
mg_rpc_channel_mqtt 0x3ffd02b4 docker-agent.2D0C09498A207136/rpc
mg_rpc_add_channel 0x3ffd02b4 '*' MQTT
mg_rpc_channel_uart 0x3ffd0368 UART0
mg_rpc_add_channel 0x3ffd0368 '' UART
mgos_init Init done, RAM: 161224 free, 161224 min free
mgos_upd_boot_finish 1 0
wifi_event_handler WiFi STA: disconnected, reason 201; reconnecting
mgos_wifi_on_change_ Wifi: disconnected
wifi_event_handler WiFi STA: disconnected, reason 201; reconnecting
mgos_wifi_on_change_ Wifi: disconnected
... (this continues in a tight loop) ...
(ignore the "not init" and "not start" errors, they are handled in the code and wifi is inited and started as required).
rojer
All 24 comments
https://github.com/espressif/esp-idf/blob/master/components/esp32/include/esp_wifi_types.h#L86
Could be signal issue? Other person mentioned this error had an antenna problem.
negativekelvin
on 14 Feb 2017
no, as i said, at the very same instant a bunch of other devices (1 more esp32 and 2 esp8266) were running other tests on the same AP.
rojer
on 14 Feb 2017
Does that rule out a hw issue on the esp32 board? Have you seen the issue on multiple units?
negativekelvin
on 15 Feb 2017
admittedly, this i don't know. i don't have logs from the past cases, will need to wait for this to happen again to see if it's the same.
rojer
on 15 Feb 2017
just happened on the other device we have running automated tests, so i don't think it's hardware
rojer
on 15 Feb 2017
@rojer are you able to get an 802.11 frame capture ("monitor mode" capture) for the good & bad behaviour?
projectgus
on 16 Feb 2017
not easily, but i'll look into it later (currently traveling).
but complete lack of any output suggests that it's probably some sort of initialization failure.
rojer
on 16 Feb 2017
fwiw, this still happens sometimes
rojer
on 12 Apr 2017
still happening, including on latest IDF (a41ac2d21d90fc69f8426eb6036d2d1e1274ec28).
latest "good" log:
esp32_mgos_init aws_iot_test_fw 2017051015 (20170510-152825/master@1120910a)
esp32_mgos_init Mongoose OS Firmware 2017051015 (20170510-152825/master@1120910a)
esp32_mgos_init ESP-IDF v1.0-1290-gc66b4fb
esp32_mgos_init Boot partition: app_0, Task ID: 0x3ffbbc38, RAM: 219052 free
esp32_fs_mount Mounting SPIFFS from fs_0 (131072 @ 0x190000)
esp32_fs_mount Total: 113201, used: 18323, free: 94878
mgos_sys_config_init MAC: 240AC40039E0
mgos_sys_config_init WDT: 30 seconds
E (2727) wifi: esp_wifi_get_mode 781 wifi is not init
mgos_wifi_set_mode WiFi mode: STA
E (2737) wifi: esp_wifi_set_mode 774 wifi is not init
I (2737) wifi: wifi firmware version: 384bc4e
I (2747) wifi: config NVS flash: enabled
I (2747) wifi: config nano formating: disabled
I (2757) wifi: Init dynamic tx buffer num: 32
I (2767) wifi: Init dynamic rx buffer num: 64
I (2767) wifi: wifi driver task: 3ffbd00c, prio:23, stack:3584
I (2777) wifi: Init static rx buffer num: 10
I (2777) wifi: Init dynamic rx buffer num: 0
I (2787) wifi: Init rx ampdu len mblock:7
I (2787) wifi: Init lldesc rx ampdu entry mblock:4
I (2797) wifi: wifi power manager task: 0x3ffd118c prio: 21 stack: 2560
E (2807) wifi: esp_wifi_connect 813 wifi not start
I (2807) wifi: wifi timer task: 3ffd21f8, prio:22, stack:3584
I (2837) phy: phy_version: 350, Mar 22 2017, 15:02:06, 0, 0
I (2837) wifi: mode : sta (24:0a:c4:00:39:e0)
event_handler event: 2
mgos_wifi_setup_sta WiFi STA: Connecting to Cesanta
mgos_sys_config_init HTTP server started on [80]
mg_rpc_channel_mqtt 0x3ffd2aa0 docker-agent.5H9JOPRA/rpc/#
mg_rpc_add_channel_i 0x3ffd2aa0 '*' MQTT, trusted
mg_rpc_channel_uart 0x3ffd2bd8 UART0
mg_rpc_add_channel_i 0x3ffd2bd8 '' UART, trusted
mg_rpc_add_channel_i 0x3ffd2c4c 'RPC.LOCAL' loopback, trusted
mgos_init Init done, RAM: 182208 free, 181504 min free
mgos_upd_boot_finish 1 0
mg_rpc_ev_handler 0x3ffd2c4c CHAN OPEN (loopback)
I (2977) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (3817) wifi: state: init -> auth (b0)
I (3827) wifi: state: auth -> assoc (0)
I (3837) wifi: state: assoc -> run (10)
I (3857) wifi: connected with Cesanta, channel 1
mgos_wifi_on_change_ Wifi: connected
I (4387) event: ip: 192.168.1.29, mask: 255.255.255.0, gw: 192.168.1.1
mgos_wifi_on_change_ WiFi: ready, IP 192.168.1.29, DNS 192.168.1.1
and "bad":
esp32_mgos_init aws_iot_test_fw 2017051015 (20170510-152825/master@1120910a)
esp32_mgos_init Mongoose OS Firmware 2017051015 (20170510-152825/master@1120910a)
esp32_mgos_init ESP-IDF v1.0-1290-gc66b4fb
esp32_mgos_init Boot partition: app_0, Task ID: 0x3ffbbc38, RAM: 219052 free
esp32_fs_mount Mounting SPIFFS from fs_0 (131072 @ 0x190000)
esp32_fs_mount Total: 113201, used: 22339, free: 90862
mgos_sys_config_init MAC: 240AC40039E0
mgos_sys_config_init WDT: 30 seconds
E (2740) wifi: esp_wifi_get_mode 781 wifi is not init
mgos_wifi_set_mode WiFi mode: STA
E (2750) wifi: esp_wifi_set_mode 774 wifi is not init
I (2750) wifi: wifi firmware version: 384bc4e
I (2760) wifi: config NVS flash: enabled
I (2760) wifi: config nano formating: disabled
I (2770) wifi: Init dynamic tx buffer num: 32
I (2780) wifi: Init dynamic rx buffer num: 64
I (2780) wifi: wifi driver task: 3ffbd19c, prio:23, stack:3584
I (2790) wifi: Init static rx buffer num: 10
I (2790) wifi: Init dynamic rx buffer num: 0
I (2800) wifi: Init rx ampdu len mblock:7
I (2800) wifi: Init lldesc rx ampdu entry mblock:4
I (2810) wifi: wifi power manager task: 0x3ffd124c prio: 21 stack: 2560
E (2820) wifi: esp_wifi_connect 813 wifi not start
I (2830) wifi: wifi timer task: 3ffd22b8, prio:22, stack:3584
I (2850) phy: phy_version: 350, Mar 22 2017, 15:02:06, 0, 0
I (2860) wifi: mode : sta (24:0a:c4:00:39:e0)
event_handler event: 2
mgos_wifi_setup_sta WiFi STA: Connecting to Cesanta
mgos_sys_config_init HTTP server started on [80]
mg_rpc_channel_mqtt 0x3ffd2b40 docker-agent.5H9JOPRA/rpc/#
mg_rpc_add_channel_i 0x3ffd2b40 '*' MQTT, trusted
mg_rpc_channel_uart 0x3ffd2c78 UART0
mg_rpc_add_channel_i 0x3ffd2c78 '' UART, trusted
mg_rpc_add_channel_i 0x3ffd2cec 'RPC.LOCAL' loopback, trusted
mgos_init Init done, RAM: 182028 free, 181468 min free
mgos_upd_boot_finish 1 0
mg_rpc_ev_handler 0x3ffd2cec CHAN OPEN (loopback)
mongoose_poll New heap free LWM: 180356
wifi_event_handler WiFi STA: disconnected, reason 201; reconnecting
mgos_wifi_on_change_ Wifi: disconnected
wifi_event_handler WiFi STA: disconnected, reason 201; reconnecting
mgos_wifi_on_change_ Wifi: disconnected
wifi_event_handler WiFi STA: disconnected, reason 201; reconnecting
mgos_wifi_on_change_ Wifi: disconnected
wifi_event_handler WiFi STA: disconnected, reason 201; reconnecting
mgos_wifi_on_change_ Wifi: disconnected
wifi_event_handler WiFi STA: disconnected, reason 201; reconnecting
mgos_wifi_on_change_ Wifi: disconnected
...
Hi @rojer reason 201 is WIFI_REASON_NO_AP_FOUND, it means the esp32 doesn't find the specified AP, it looks strange because other device can connect the AP while the bad esp32 can't find the AP. Currently the log is not enough for debugging this issue, also I didn't observe any similar behavior in our lab test.
Could you help to provide following info?
- If possible, capture the packets in the channel on which the AP is running (here it's channel 1, ht20), filter the packets with esp32 and AP's mac, because I need to check whether the esp32's probe request is sent out or not? also whether the AP's probe response is sent out or not?
- Do you configure the channel dwell duration with esp_wifi_scan_start? The default behavior of esp32 foreground scan is to scan each channel for 120ms, if the dwell scan duration is configured to a smaller duration, then esp32 may fails to find the AP
- Check the hardware status of the bad esp32, is this problem only happen to this specified esp32 board and all other esp32 board are good?
- Relative position between the bad esp32 board and the AP, does the bad esp32 board has the same test environment (such as distance, position etc) as the good esp32/8266?
I will as our QA to do some stability test about this issue and hope we can reproduce it in lab....
liuzfesp
on 11 May 2017
@liuzfesp thanks for response. it's not that easy for me to do packet capture, as none of the adapters i have in the area seem to be doing monitor mode properly - some just flat out don't support it, and one that claims to just returns no packets. i'll try to figure something out.
i don't configure any parameters related to scan. i configure station and then just invoke connect.
this happens on both esp32 devkit boards we have configured in this hardware test rig. and both logs i posted here are actually from the same device, just seconds apart.
it must be something related to scan, it even seems that it's never started, for whatever reason- these disconnection events come pretty quickly, as if station is not even trying to find AP - failing to even initiate scan, perhaps? there are no error log entries though, as you can see.
perhaps, you could throw in a couple info or debug-level messages in key places of the scan process?
rojer
on 11 May 2017
HI @rojer " you could throw in a couple info or debug-level messages in key places of the scan process", it's a good idea, however, currently in release 2.1 (and former release), the release version, we don't have too much infor/log for wifi debug, we have a bunch of debug info/log in debug version, I think the detailed debug/info should be ready in next release (not release2.1).
liuzfesp
on 22 May 2017
I experience the same issue. When I perform scan, the AP I want to connect to is found with a signal strength -33. However, when I connect, I receive disconnected with reason 201. ESP32 connects to the AP only in 1 out of 15 cases. So far i haven't found any pattern.
yaqwsx
on 30 May 2017
I am getting similar failure condition and can repeat reliable. I monitor the system core firmware with TeraTerm version 4.89 to my serial USB interface. The error message I get that tell me I have crashed is "E (43684) Wifi ieee 80211_sta.c 649. If I wait for a period of time the system start a core dump.
My application is sending approximately 191 bytes of data thru the "pub" function. My message packet is a JSON formated string that is NULL terminated. If I call "pub" 11 times it generates the above error. The time period for sending these packets is about once every 10 seconds. All packets are received and are correct except the last when the failure occurs. My "pub" msg buffer is set to 512 because some of my packet are larger than others.
I am controlling the application via AMAZON AWS tools, test interface MQTT Client.
danstirling
on 24 Jun 2017
Although perhaps unrelated, these earlier and later issues discuss some workarounds which might lead to a solution: issue 539, issue234
Notably the fact that it happens when waking from deepsleep. You apparently have to restart the ESP32 after waking up.
axello
on 22 Aug 2017
Hi @rojer @danstirling @yaqwsx we have a lot of optimization about scan in latest IDF master branch and some optimization in release 2.1, could you help to check whether this issue still exist or NOT?
liuzfesp
on 10 Oct 2017
the issue still stands: sometimes station just won't connect.
however, i think i have additional information: in this case it seems to not scan channel 11 for some reason.
we run an automated test that:
1) connects to our wifi network (Cesanta)
2) scans wifi networks in the background
these are carried out at the same time, so we tell wifi station to connect but _also_ run wifi scan every 5 seconds and print results.
so, sometimes the following happens:
1) station cannot connect to Cesanta
2) scan results never contain APs with channel 11
incidentally, Cesanta uses channel 11. so (1) seems to be the reason for (2), so it's no wonder.
why the scan skips channel 11 however, i have no clue.
for example, here's the result of a scan from a good run:
mgos_wifi_setup_sta WiFi STA: Connecting to Cesanta
I (691) phy: phy_version: 362.0, 61e8d92, Sep 8 2017, 18:48:11, 0, 0
I (691) wifi: mode : sta (24:0a:c4:00:39:e0)
...
mgos_net_on_change_c WiFi STA: connecting
I (2031) wifi: n:11 0, o:1 0, ap:255 255, sta:11 0, prof:1
I (2971) wifi: state: init -> auth (b0)
I (2981) wifi: state: auth -> assoc (0)
sw_timer_cb 0 ctr 0 -> 16697, diff = 16697
I (2991) wifi: state: assoc -> run (10)
I (3011) wifi: connected with Cesanta, channel 11
mgos_net_on_change_c WiFi STA: connected
sw_timer_cb 1 ctr 16697 -> 20001, diff = 3304
I (3541) event: sta ip: 192.168.1.26, mask: 255.255.255.0, gw: 192.168.1.1
mgos_net_on_change_c WiFi STA: ready, IP 192.168.1.26, GW 192.168.1.1, DNS 192.168.1.1
...
mgos_wifi_dev_scan_c WiFi scan done, num_res 9
wifi_scan_cb 123 9 results 0x3ffcacc4
wifi_scan_cb 123 SSID 'Cesanta' chan 11 auth 3 RSSI -45
wifi_scan_cb 123 SSID 'eduroam' chan 1 auth 5 RSSI -61
wifi_scan_cb 123 SSID 'TCDguest' chan 1 auth 0 RSSI -62
wifi_scan_cb 123 SSID 'DIRECT-D3C1860 Series' chan 11 auth 3 RSSI -70
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 7 auth 3 RSSI -77
wifi_scan_cb 123 SSID 'Amethyst WiFi' chan 9 auth 4 RSSI -77
wifi_scan_cb 123 SSID 'ICHEC Guest' chan 7 auth 3 RSSI -78
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -87
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -87
...
mgos_wifi_dev_scan_c WiFi scan done, num_res 5
wifi_scan_cb 123 5 results 0x3ffdbbf8
wifi_scan_cb 123 SSID 'Cesanta' chan 11 auth 3 RSSI -45
wifi_scan_cb 123 SSID 'Mongoose_05E802' chan 6 auth 3 RSSI -48
wifi_scan_cb 123 SSID 'TCDguest' chan 6 auth 0 RSSI -53
wifi_scan_cb 123 SSID 'eduroam' chan 6 auth 5 RSSI -53
wifi_scan_cb 123 SSID 'DIRECT-D3C1860 Series' chan 11 auth 3 RSSI -71
note that channel 11 has two APs: Cesanta and DIRECT-D3C1860 Series (whatever that is).
on a bad run, however, repeated scans never contain anything on channel 11:
mgos_wifi_setup_sta WiFi STA: Connecting to Cesanta
I (689) phy: phy_version: 362.0, 61e8d92, Sep 8 2017, 18:48:11, 0, 0
I (689) wifi: mode : sta (24:0a:c4:00:39:e0)
...
mgos_net_on_change_c WiFi STA: connecting
sw_timer_cb 0 ctr 0 -> 10002, diff = 10002
esp32_wifi_ev Disconnected from Cesanta, reason: 201
mgos_net_on_change_c WiFi STA: disconnected
mgos_net_on_change_c WiFi STA: connecting
sw_timer_cb 1 ctr 10002 -> 20002, diff = 10000
sw_timer_cb 2 ctr 20002 -> 30001, diff = 9999
sw_timer_cb 3 ctr 30001 -> 40002, diff = 10001
esp32_wifi_ev Disconnected from Cesanta, reason: 201
mgos_net_on_change_c WiFi STA: disconnected
mgos_net_on_change_c WiFi STA: connecting
sw_timer_cb 4 ctr 40002 -> 50003, diff = 10001
sw_timer_cb 5 ctr 50003 -> 60002, diff = 9999
mgos_wifi_dev_scan_c WiFi scan done, num_res 6
wifi_scan_cb 123 6 results 0x3ffcab5c
wifi_scan_cb 123 SSID 'Mongoose_003AAA' chan 6 auth 3 RSSI -14
wifi_scan_cb 123 SSID 'Cesanta' chan 11 auth 3 RSSI -47
wifi_scan_cb 123 SSID 'eduroam' chan 6 auth 5 RSSI -53
wifi_scan_cb 123 SSID 'ICHEC Guest' chan 12 auth 3 RSSI -87
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -88
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -88
sw_timer_cb 6 ctr 60002 -> 70001, diff = 9999
sw_timer_cb 7 ctr 70001 -> 80001, diff = 10000
sw_timer_cb 8 ctr 80001 -> 90002, diff = 10001
sw_timer_cb 9 ctr 0 -> 0, diff = 0
sw_timer_cb 10 ctr 0 -> 0, diff = 0
mgos_wifi_dev_scan_c WiFi scan done, num_res 2
wifi_scan_cb 123 2 results 0x3ffcaa5c
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -87
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -87
sw_timer_cb 11 ctr 0 -> 0, diff = 0
sw_timer_cb 12 ctr 0 -> 0, diff = 0
sw_timer_cb 13 ctr 0 -> 0, diff = 0
sw_timer_cb 14 ctr 0 -> 0, diff = 0
sw_timer_cb 15 ctr 0 -> 0, diff = 0
mgos_wifi_dev_scan_c WiFi scan done, num_res 3
wifi_scan_cb 123 3 results 0x3ffcaa9c
wifi_scan_cb 123 SSID 'ICHEC Guest' chan 12 auth 3 RSSI -88
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -89
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -90
sw_timer_cb 16 ctr 0 -> 0, diff = 0
sw_timer_cb 17 ctr 0 -> 0, diff = 0
sw_timer_cb 18 ctr 0 -> 0, diff = 0
sw_timer_cb 19 ctr 0 -> 0, diff = 0
sw_timer_cb 20 ctr 0 -> 0, diff = 0
mgos_wifi_dev_scan_c WiFi scan done, num_res 7
wifi_scan_cb 123 7 results 0x3ffcab9c
wifi_scan_cb 123 SSID 'Mongoose_E03C9A' chan 6 auth 3 RSSI -44
wifi_scan_cb 123 SSID 'TCDwifi-firststeps' chan 6 auth 0 RSSI -52
wifi_scan_cb 123 SSID 'TCDguest' chan 6 auth 0 RSSI -52
wifi_scan_cb 123 SSID 'eduroam' chan 6 auth 5 RSSI -52
wifi_scan_cb 123 SSID 'ICHEC Guest' chan 12 auth 3 RSSI -88
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -88
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -89
sw_timer_cb 21 ctr 0 -> 0, diff = 0
sw_timer_cb 22 ctr 0 -> 0, diff = 0
sw_timer_cb 23 ctr 0 -> 0, diff = 0
sw_timer_cb 24 ctr 0 -> 0, diff = 0
sw_timer_cb 25 ctr 0 -> 0, diff = 0
mgos_wifi_dev_scan_c WiFi scan done, num_res 3
wifi_scan_cb 123 3 results 0x3ffcaa9c
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -87
wifi_scan_cb 123 SSID 'ICHEC Guest' chan 12 auth 3 RSSI -87
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -89
sw_timer_cb 26 ctr 0 -> 0, diff = 0
sw_timer_cb 27 ctr 0 -> 0, diff = 0
sw_timer_cb 28 ctr 0 -> 0, diff = 0
sw_timer_cb 29 ctr 0 -> 0, diff = 0
sw_timer_cb 30 ctr 0 -> 0, diff = 0
mgos_wifi_dev_scan_c WiFi scan done, num_res 3
wifi_scan_cb 123 3 results 0x3ffcaa9c
wifi_scan_cb 123 SSID 'ICHEC Guest' chan 12 auth 3 RSSI -88
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -89
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -90
sw_timer_cb 31 ctr 0 -> 0, diff = 0
sw_timer_cb 32 ctr 0 -> 0, diff = 0
sw_timer_cb 33 ctr 0 -> 0, diff = 0
sw_timer_cb 34 ctr 0 -> 0, diff = 0
sw_timer_cb 35 ctr 0 -> 0, diff = 0
mgos_wifi_dev_scan_c WiFi scan done, num_res 5
wifi_scan_cb 123 5 results 0x3ffcab1c
wifi_scan_cb 123 SSID 'Cesanta' chan 11 auth 3 RSSI -46
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 7 auth 3 RSSI -76
wifi_scan_cb 123 SSID 'ICHEC Guest' chan 12 auth 3 RSSI -87
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -89
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -91
sw_timer_cb 36 ctr 0 -> 0, diff = 0
sw_timer_cb 37 ctr 0 -> 0, diff = 0
sw_timer_cb 38 ctr 0 -> 0, diff = 0
sw_timer_cb 39 ctr 0 -> 0, diff = 0
sw_timer_cb 40 ctr 0 -> 0, diff = 0
mgos_wifi_dev_scan_c WiFi scan done, num_res 7
wifi_scan_cb 123 7 results 0x3ffcab9c
wifi_scan_cb 123 SSID 'Mongoose_0039F8' chan 6 auth 3 RSSI -27
wifi_scan_cb 123 SSID 'TCDwifi-firststeps' chan 6 auth 0 RSSI -52
wifi_scan_cb 123 SSID 'TCDwifi-firststeps' chan 1 auth 0 RSSI -61
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -88
wifi_scan_cb 123 SSID 'ICHEC Guest' chan 12 auth 3 RSSI -89
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -89
wifi_scan_cb 123 SSID 'creme-backup2' chan 1 auth 4 RSSI -95
sw_timer_cb 41 ctr 0 -> 0, diff = 0
sw_timer_cb 42 ctr 0 -> 0, diff = 0
sw_timer_cb 43 ctr 0 -> 0, diff = 0
sw_timer_cb 44 ctr 0 -> 0, diff = 0
sw_timer_cb 45 ctr 0 -> 0, diff = 0
mgos_wifi_dev_scan_c WiFi scan done, num_res 6
wifi_scan_cb 123 6 results 0x3ffcab5c
wifi_scan_cb 123 SSID 'Mongoose_E03C9A' chan 6 auth 3 RSSI -44
wifi_scan_cb 123 SSID 'TCDguest' chan 6 auth 0 RSSI -52
wifi_scan_cb 123 SSID 'eduroam' chan 6 auth 5 RSSI -52
wifi_scan_cb 123 SSID 'ICHEC Staff 2.4G' chan 12 auth 3 RSSI -88
wifi_scan_cb 123 SSID 'ICHEC Staff' chan 12 auth 3 RSSI -88
wifi_scan_cb 123 SSID 'ICHEC Guest' chan 12 auth 3 RSSI -89
sw_timer_cb 46 ctr 0 -> 0, diff = 0
sw_timer_cb 47 ctr 0 -> 0, diff = 0
sw_timer_cb 48 ctr 0 -> 0, diff = 0
sw_timer_cb 49 ctr 0 -> 0, diff = 0
sw_timer_cb 50 ctr 0 -> 0, diff = 0
... etc, etc ...
WiFi log for scan/connect will be ready in IDF v3.3 soon, then we can debug the hard-reproduce WiFi connected issue with the log.
liuzfesp
on 24 Nov 2018
I guess it's not your case, but anyway...
Something similar happened to me after updating to esp-idf v3.3. With older versions there was no problem. The bug was uncorrect wifi_config_t initialization. wifi_config_t wifi_config = {0} at the beginning helped.
ImrichFischer
on 7 Dec 2018
Thanks, @ImrichFischer. That fixed the connection problem for me in 3.1 and in 3.2.
toddlesher
on 13 Dec 2018
@ImrichFischer 闈炲父鎰熻阿,鎴戜篃鏄繖涓棶棰樺搱鍝堝搱
qinjmin
on 14 Feb 2019
@ImrichFischer. Thank U
here is the code for those who need it
wifi_config_t sta_config = {
.sta = {
.ssid = "MYWIFI",
.password="MYPASSWORD",
.scan_method=WIFI_FAST_SCAN, /**< do all channel scan or fast scan */
//WIFI_FAST_SCAN = 0, /**< Do fast scan, scan will end after find SSID match AP */
//WIFI_ALL_CHANNEL_SCAN, /**< All channel scan, scan will end after scan all the channel */
.bssid_set=0,
/**bssid_set < whether set MAC address of target AP or not. Generally,
* station_config.bssid_set needs to be 0;
* and it needs to be 1 only when users need to check the MAC address of the AP.*/
.bssid={0}, /**< MAC address of target AP*/
.channel=0, /**< channel of target AP. Set to 1~13 to scan starting from the specified channel before connecting to AP. If the channel of AP is unknown, set it to 0.*/
.listen_interval=0, /**< Listen interval for ESP32 station to receive beacon when WIFI_PS_MAX_MODEM is set. Units: AP beacon intervals. Defaults to 3 if set to 0. */
.sort_method=WIFI_CONNECT_AP_BY_SIGNAL, /**< sort the connect AP in the list by rssi or security mode */
//WIFI_CONNECT_AP_BY_SIGNAL = 0, /**< Sort match AP in scan list by RSSI */
//WIFI_CONNECT_AP_BY_SECURITY, /**< Sort match AP in scan list by security mode */
.threshold.rssi=0, /**< When sort_method is set, only APs which have an auth mode that is more secure than the selected auth mode and a signal stronger than the minimum RSSI will be used. */
//int8_t rssi;/**< The minimum rssi to accept in the fast scan mode */
.threshold.authmode=WIFI_AUTH_OPEN /**< The weakest authmode to accept in the fast scan mode */
//WIFI_AUTH_OPEN = 0, /**< authenticate mode : open */
//WIFI_AUTH_WEP, /**< authenticate mode : WEP */
//WIFI_AUTH_WPA_PSK, /**< authenticate mode : WPA_PSK */
//WIFI_AUTH_WPA2_PSK, /**< authenticate mode : WPA2_PSK */
//WIFI_AUTH_WPA_WPA2_PSK, /**< authenticate mode : WPA_WPA2_PSK */
//WIFI_AUTH_WPA2_ENTERPRISE, /**< authenticate mode : WPA2_ENTERPRISE */
//WIFI_AUTH_MAX
}
};
ORParga
on 4 Jun 2020
I guess it's not your case, but anyway...
Something similar happened to me after updating to esp-idf v3.3. With older versions there was no problem. The bug was uncorrect wifi_config_t initialization. wifi_config_t wifi_config = {0} at the beginning helped.
Thaks!
italijancic
on 10 Oct 2020
I had the same issue under IDF 4.0. Doing the null initialization fixed the problem.
VaderMester
on 14 Jan 2021
Related issues
LosDeiblos
路
4Comments
luc-github
路
4Comments
ghost
路
4Comments
bfriedkin
路
4Comments
feelfreelinux
路
4Comments
Most helpful comment
I guess it's not your case, but anyway...
Something similar happened to me after updating to esp-idf v3.3. With older versions there was no problem. The bug was uncorrect wifi_config_t initialization. wifi_config_t wifi_config = {0} at the beginning helped.