Wifi will refuse to re-associate and in certain circumstances hard reset

[TheBestJohn]

it seems as if after a few requests using urequests, something timesout and then it goes into a loop of not being able to reassociate. I can swap modes, set station.active(False) and back again and try again but it will not connect no matter what

urequests.request("PUT","https://api.example.com/", headers=headerBuffer)
I (402628) wifi: bcn_timout,ap_probe_send_start
I (405128) wifi: ap_probe_send over, resett wifi status to disassoc
I (405128) wifi: state: run -> init (1)
I (405128) wifi: n:8 0, o:8 0, ap:255 255, sta:8 0, prof:1
I (405128) wifi: pm stop, total sleep time: 0/237425451

I (405138) wifi: STA_DISCONNECTED, reason:200
mbedtls_ssl_handshake error: -71
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "urequests.py", line 56, in request
OSError: [Errno 5] EIO
>>> I (406828) wifi: STA_DISCONNECTED, reason:201
I (408518) wifi: STA_DISCONNECTED, reason:201
I (410208) wifi: STA_DISCONNECTED, reason:201
I (411888) wifi: STA_DISCONNECTED, reason:201
I (411888) wifi: STA_DISC..... ad infinitum

Then in some cases it will just hard fail and reboot

mbedtls_ssl_handshake error: -4290
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "urequests.py", line 56, in request
OSError: [Errno 5] EIO

urequests.request("PUT","https://api.example.com/", headers=headerBuffer)

assertion "0" failed: file "../../py/../extmod/modussl_mbedtls.c", line 151, function: socket_new
abort() was called at PC 0x4013657f on core 0

Backtrace: 0x40086edf:0x3ffcee60 0x40086f0b:0x3ffcee80 0x4013657f:0x3ffceea0 0x400ececf:0x3ffceed0 0x400df6fa:0x3ffcef20 0x400dbba5:0x3ffcef50 0x400dbc0d:0x3ffcef70 0x400e8be9:0x3ffcef90 0x400df788:0x3ffcf030 0x400dbba5:0x3ffcf060 0x400dbc0d:0x3ffcf080 0x400e8be9:0x3ffcf0a0 0x400df788:0x3ffcf140 0x400dbba5:0x3ffcf1b0 0x400dbbd2:0x3ffcf1d0 0x400f7126:0x3ffcf1f0 0x400f7370:0x3ffcf290 0x400eee7c:0x3ffcf2d0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
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:3408
load:0x40078000,len:9488
load:0x40080000,len:252
entry 0x40080034
I (1395) cpu_start: Pro cpu up.
I (1395) cpu_start: Single core mode
I (1397) heap_init: Initializing. RAM available for dynamic allocation:
I (1408) heap_init: At 3FFAE2A0 len 00001D60 (7 KiB): DRAM
I (1426) heap_init: At 3FFD4FD8 len 0000B028 (44 KiB): DRAM
I (1446) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (1465) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1485) heap_init: At 400920A0 len 0000DF60 (55 KiB): IRAM
I (1505) cpu_start: Pro cpu start user code
I (1565) cpu_start: Starting scheduler on PRO CPU.
OSError: [Errno 2] ENOENT
MicroPython v1.9.2-270-g14fb53e0 on 2017-09-13; ESP32 module with ESP32

[TheBestJohn]

From what I've been able to track down, It may be because TLS 1.2. Now I'm not sure which TLS this api is using in it's SSL but I can make calls to this specific url without a problem several times before this error so I think that rules that out. Also, this looks to be closed Micropython discussion on TLS

This may be IDF related but it looks like they fixed this issue last year as discussed in this issue on the IDF git. This looks to be closed as well though.

[dpgeorge]

but it will not connect no matter what

Error code 200 means "beacon timeout" so the esp32 thinks that the AP has gone offline. Then error 201 means "AP not found" so it indeed can no longer see it. If you're certain that the AP is still on and working then the issue is most likely with the esp32 hardware (eg antenna) or low-level wifi driver, so can't be fixed here.

In 0d183d7f0eb21b10302b283887159acd73c56697 I added some better error messages to help debug these situations.

Then in some cases it will just hard fail and reboot

This looks like a different problem, likely related to mbedtls. I'd suggest trying the latest version of this code because in f0561abcfca5d2d84abb14141c44cafe0bfb8b08 I updated to the latest ESP IDF and lots of things changed with mbedtls.

[TheBestJohn]

I'll test these out as soon as I can.

I can confirm that the AP is still there and there is absolutely nothing wrong with it. If I reboot the ESP it will connect right away, no arguments at all. It will also happily sit there for hours connected to the AP and only when I send urequest functions in regular succession do I get the issue. (like less than 5 seconds in between requests).

[TheBestJohn]

Everything seems to be running fine now. cant reproduce the issue. with the latest build urequests isn't included. This may be because it's the first time I'm compiling it myself, I got the previous bin from micropython.org/downloads.

urequests seems to be new as well. I can find 3 distinct versions of it. One on the micropython git, one through upip and another somewhere else that I can't think of.

Regardless the one in the previous bin didn't have a close method and I'm thinking that it was just opening a ton of sockets and self destructing the whole time. The second case may have been me trying to add a socket AS the connection to AP was in the process of being dropped.

Really weird though, that the upip version has quite a few helpful functions but doesn't work on the esp32 for some reason. I took the one in the micropython-lib and added the helpers from the upip version

[dpgeorge]

There is only one urequests and it lives in the micropython-lib repository. It is published on PyPI (available via upip) and included in the esp32 builds. Sometimes there may be different versions in these locations but they are the same and versions are updated often.