esp32 + asynctcp exception on serial

[ramarro123]

hi there,

i noticed a closed issue here (https://github.com/me-no-dev/AsyncTCP/issues/54) that's exactly what i got on my esp32 board.

everything it's up to date (every lib, sdk, etc) via platformio. i am trying the esp32 example provided here https://github.com/marvinroger/async-mqtt-client/tree/master/examples/FullyFeatured-ESP32

no ssl, no special "stuff" mqtt server run on same lan segment and on esp8266 same example (obviusly for esp8266 variant) work without flooding console.

on esp32 i see [E][AsyncTCP.cpp:1105] _poll(): 0x3ffdf9c4 != 0x3ffdf720 [E][AsyncTCP.cpp:1105] _poll(): 0x3ffdf9c4 != 0x3ffdf720 repeated forever

any idea about what can be the issue?

[phamminhkhac]

same problem. 0x3ffdf9c4 like new socket id it's different from current socket id (0x3ffdf720) the library seem tried to reuse old socket but it's failed. I forced close the connection on onMqttDisconnect event to clear the old _pcb data, but i'm not sure that's is the safe and good solution

[ramarro123]

i think that this lib it's abandoned unfortunatley, someone have find a replacement?

[bertmelis]

Fork it and cherry pick from other forks... That's what I do.

[ghost]

Same Issue.

[E][AsyncTCP.cpp:934] _poll(): 0x3ffdc8d0 != 0x3ffdcd20
[E][AsyncTCP.cpp:934] _poll(): 0x3ffdcb08 != 0x3ffdcd20
[E][AsyncTCP.cpp:934] _poll(): 0x3ffdcf40 != 0x3ffdcd20
[E][AsyncTCP.cpp:934] _poll(): 0x3ffdce6c != 0x3ffdcd20
[E][AsyncTCP.cpp:867] _lwip_fin(): 0x3ffdcb08 != 0x3ffdcf40
[E][AsyncTCP.cpp:867] _lwip_fin(): 0x3ffdc8d0 != 0x3ffdcf40
[E][AsyncTCP.cpp:867] _lwip_fin(): 0x3ffdcd20 != 0x3ffdcf40
[E][AsyncTCP.cpp:867] _lwip_fin(): 0x3ffdce6c != 0x3ffdcf40

can anybody tell what exactly is happening in the background and what is this error trying to say?

[bertmelis]

Could you update the async lib?

You're logging at line 934 but in the code it is line 953. This suggests you're not using the latest version.

[ghost]

I am using the latest released version 0.8.1. is there any other latest version I should use. Will it solve my issue?

[ghost]

@bertmelis if possible can you just give an explanation to what is going wrong, due to which I am getting this error code.

If possible can you link to library which you have been using. It would be great help to me. thanks.

[bertmelis]

@bertmelis if possible can you just give an explanation to what is going wrong, due to which I am getting this error code.

If possible can you link to library which you have been using. It would be great help to me. thanks.

I can't explain. but I would look into connection issues. MQTT builds on top of TCP. So you have a TCP connection and an MQTT connection. Now you can have a persistant MQTT connection with an unstable TCP connection. My guess is that this lib (and any other MQTT lib for this platform) isn't capable of managing this.

But that's only my best guess.

It would explain why force disconnecting makes the errors go away.

I did nothing in my fork to solve this.

[CircuitSetup]

I'm seeing the same issue. Has anyone figured anything out with this? It seems to be related to the handling of _pull between AsyncTCP and this lib.

[rowdy15]

Try changing the wifi name that the esp32 is broadcasting. This worked for me.

WiFi.setHostname("wifi_name"); // change this name

The cause:

You may have programmed 2 different devices with the same broadcasted wifi name and so the router in the network doesn't like it when there are 2 different mac addresses with the same wifi name.

I don't know if this the reason for sure, but certainly changing the wifi name of the device made it go away for me.

[slaesh]

same issue here. appears "sometimes" after a disconnect/reconnect.

is this a problem of "this lib" to poll something what does not exist?

or is the mqtt-broker polling something which is already "closed"?

:thinking:

[bertmelis]

No, it is asynctcp. When trying to connect, the lib starts polling but no PCB is available until the connection is made.

[slaesh]

thanks @bertmelis

so.. asynctcp polls an already closed connection.. but "we", the asyncmqttclient, are keeping a "broken" connection somehow alive/in-memory? or is the "memoryleak" in asynctcp too? which is polling something which should be "already gone" ..

any idea how to debug this further? getting this logs twice a second.. I am not sure if this error stacks up or not.. :see_no_evil: but could go wild over a long long period of time with several disconnects ^^

[slaesh]

it does not stack up.. after another reconnect/disconnect.. it is gone. not sure "where" this gets stuck and why it's not "self-healing" :thinking: trying to dig into it sooner or later though