There is a firewall, but it is not blocking anything going to port 1883, other clients can connect while the ESP32 cannot. I cannot disable the FW since docker requires it to run.WiFive wrote:Looks like they both send 7x tcp_output_segment, but one case receives many unacceptable reset and the other only receives 1 or none. So is there firewall or something else rejecting these packets before they get to wireshark/docker?
As I wrote earlier, I can only reproduce the behavior when Docker is involved - running the MQTT broker directly on a PC yields in the expected results. Also, during your tests, did you restart the ESP32 during your 4:th step or did you program the application to attempt reconnection? I've found that resetting the ESP32 usually results in a successful connection even if it couldn't connect before the reset, which makes sense since the problem only occurs when the first connection attempt fails.heyinling wrote: There might some difference between our test:
Do you mean the packets seen from tshark after the server is started? There are none - the ESP32 seemingly doesn't send anything once the problem has been seen.heyinling wrote: And could you paste the packet capture log after you setup server? did ESP32 send SYN to server?
I'm quite certain that the issue only happens when lwIP reports "Software caused connection abort" and not when it reports "Connection reset by peer".