ESP32-S2 MQTT subscriber "OSError: [Errno 113] ECONNABORTED"

[pythoncoder]

I really don't know what is going on here. I've been using a FeatherS2 quite intensively with mqtt_as over the last couple of days. Aside from the USB issue, addressed by using a different PC, I haven't seen any sign of unexpected behaviour. I am now confident that mqtt_as works well with the S2 chip.

There is scope for hardware problems with ESP32 chips, and I suspect this is what you are experiencing. When the ESP32 first connects to WiFi it draws a brief pulse of quite high current. This could be causing a voltage drop and the disruption you are experiencing.

[davealexis]

I'm getting the ECONNABORTED issue also, but noticed that it works once then stops working. Here's what I'm seeing...

1) ESP8266 freshly flashed with MicroPython 1.18. Connects to the Mosquitto broker and sends messages normally.
2) Reboot the ESP8266 and rerun the code - I get ECONNABORTED.
3) Re-flash MicroPython on the ESP8266 and run the code again, and it works perfectly until the next time I reboot the device.

I don't think there's anything wonky with the mosquitto broker. I'm able to connect and send/receive messages from a Pi and from various PCs using mosquitto_pub/mosquitto_sub, Python code and JavaScript code, and an MQTT GUI client.

Something seems to be getting cached on the device and causing issues after reboot. (?)

[davealexis]

Found a solution! Hopefully this works for you also.
It turns out that access point mode was also enabled! My code definitely didn't activate it, so maybe it gets activated by default? In any case, I just added this line near the top of my program so ensure that access point mode is disabled:

network.WLAN(network.AP_IF).active(False)

Now the MQTT connection works like a charm with no ECONNABORTED error.

[swiv32]

I'm running in to this same issue with ab ESP32 S2. I tried disabling the AP, but I still get the Errno 113 ECONNABORTED message using mqtt_as. It errors out right at the point where it is trying to use the socket module to Write bytes. I've also tried umqttsimple and it also fails at the same point. I'm stumped at this point.

[pythoncoder]

I suspect there is something wrong with your setup as I have had a test running for two days with an ESP32-S2 running mqtt_as.

Have you checked network connectivity? Can you ping the ESP from a PC? Have you ensured that there is a good quality power source i.e. a short USB lead with low resistance?

[mcL]

Just wanted to add that I'm seeing similar issues with my 8266 and have been unsuccessfully trying to track it down for a while. If I can build a simple script to cause the error I will provide it. I see 2 issues: 1) OSError 113 on initial startup after a previous crash, but after exiting REPL and re-entering, 2) hang during a publish (socket.write) but only after ~100 publishes. The first issue is like the connection isn't released so attempting a new connection causes the OSError and closes the connection. Once that closes a new connection is without error. This isn't that big of a deal as I just do a machine.reset() and it comes right back thereafter. The second issue IDK -- need to do more testing. I need to try to flood the socket and see if I can reproduce with a snippet.

Here's what I see:
* I have 2 other working 8266's (SonoffR3) running 24/7 with "similar" code built on v1.12 without this issue. So pretty sure broker is ok. They have been publishing to a broker on a Synology NAS docker image for years
* Problem started with development on my 3rd device using 1.18
* I have: network.WLAN(network.AP_IF).active(False)
* After crash, exiting, and mpremote cp'ing a file over, it generates the OSError 113 but only on the first attempt. After a softboot (^d or machine.reset()) it connects to broker ok
* Using mqtt.simple -- no asyncio
* Program is just publishing the attribs from a Class, in a loop. It publishes ~3 passes of ~30 subtopics without error then hangs. If I interrupt it via ^c it's usually on line 32 of mqtt.simple

Code: Select all

socket.write(): 
    def _send_str(self, s):
        self.sock.write(struct.pack("!H", len(s)))
 >>> self.sock.write(s)

* I've also interrupted it where it tries to push the topic in publish() and dies at line 124: self._send_str(topic)
* Issue still occurs with 200ms sleep between publishes
* frequently dies in the same spot in my publish loop, but not always

[marcidy]

ECONNABORTED is raised deep in lwip, and it's not necessarily the devices' fault, it could be anyone along the network's fault.

I was struggling with this two days ago, though my symptom was a working websocket client on my desktop connected to a websocket server running on an esp32. It was ping-ponging every 5 seconds, but I would get a 113 ECONNABORTED after approximately 5 mins.

Got frustrated with debugging through LWIP so i searched "tcp connection dropped after 5 mins" and was led astray by looking at things like TCP_KEEPALIVE. Even went so far as to implement that option in setsockopt to test, but it wasnt the problem.

Finally i did what i should have started with: analyzing the packets.

I used wireshark and monitored with

Code: Select all

ip dst net 192.168.3.136 or ip src net 192.168.3.136

where the .136 address was my device.

Each time I received a ECONNABORTED, it was at the same time as a DHCP request.

I run a DHCP server and access point on my desktop, and the DHCP lease was set to time out after 10 mins, which required renewing the lease. After some searching, i set the default-lease-time to something more like a month. No more DHCP requests, no more ECONNABORTED.

The point here is that it was my network, and not the device, causing the problem.

If you aren't familiar with wireshark, it's extremely helpful for debugging networking issues like this, as you can sniff the traffic and see what else is going on besides what you expect.

[mcL]

Thank you marcidy for your insights. I have used wireshark. I was hoping not to dive that deep but I may need to. I assume I do not NOT have a network problem because I'm running 2 other Sonoffs (8266's) on the same network and they never have this issue, and this test device is ~10' from an AP. Of course the code in the others are a little different, and they have other issues. That's why I'm developing a updated version in 1.18.

I stripped down my program and quadrupled the published class attributes (~30 to ~145), remove all the delays, remove the REPL prints, to eliminate screen print delays and try to flood the mqtt socket, but could NOT reproduce the hanging error. The initial OSError 113 is still there however. Because I can not cause an error with my skeleton program I can only assume the hang is due to my code. Strange that at least 2 others have seemly the exact same issue though. I've tried everything I can think of, for over a week now. I guess the next step is to go back to 1.12 and see how that does.