[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] strange TCP behavior, connection stalls

From: M.H. ten Berge
Subject: Re: [lwip-users] strange TCP behavior, connection stalls
Date: Mon, 11 Apr 2016 22:30:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0

On 11-04-16 15:47, Sergio R. Caprile wrote:
You should first validate the port by running a known to work application, pick one from the contrib tree. The port must not call basic (non-netconn or non-socket) lwIP functions from different threads.

You must specify which API you are using, and it is quite helpful if you post your piece of software.
You seem to be using the socket API, you are definitely using an RTOS.

Where was this capture taken ? Judging by the incorrect checksums reported by wireshark, this seems to be taken at the web server (offloading). I can't see why your server is not accepting the first syn. If the capture is actually taken at the web server, it should have accepted it. Your device is missing frames, it asks for the same sent data twice (thrice in total) in frames 19 to 23. This is common in bad ports and bad layer-2 drivers (and Wi-Fi networks...).

Thanks for your reply Sergio. I'll try to answer your questions one by one:

* known-to-work application:
esp-open-rtos comes with some examples, including a simple 'http_get' example (which I already tested a some months ago, but not with large files). I ran it again, with a modified download URL, and now it exhibits the same behavior as my own application: it stalls after about 15 kB. The source code is attached, together with a new wireshark capture and console log. These 3 belong together, the pcap and log file share the same time span. I stopped the capture after the Apache process had given up.

* API:
My actual application uses the same functions from lwip as the simple http_get example: socket(), connect(), lwip_read(), lwip_write() etc I forgot to mention that esp-open-rtos is a port of FreeRTOS, so yes, indeed, an RTOS. No other tasks (threads) are created in the user application, but the SDK itself is creating one or more threads in the background for wifi, lwip, etc

* Capture:
The captures are indeed taken at the web server itself.
In the new capture, the first SYN is again not accepted. At the moment it doesn't bother me very much, maybe there is some configuration at the server side to be tweaked (it maybe tries to do a reverse DNS lookup or something).

Note: the first DNS lookup fails, because the wireless network connection setup was not finished yet. The second try starts at line 365 of the console log and succeeds.

I wonder why so many DHCP packets get mentioned in the console log? I don't think I have that many DHCP broadcasts in my network! Is it possible that some DHCP packet has got stuck in the network stack or something?

You are suspecting a bad port or network driver. If that's the case, I should probably report a bug against esp-open-rtos. Is there a way I can test whether this is the case?

Kind regards,


Attachment: http_get.c
Description: Text Data

Attachment: download_try006_filter.pcap
Description: application/vnd.tcpdump.pcap

Attachment: lwiplog.txt
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]