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

[M.H. ten Berge]

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,

Matthijs

http_get.c
Description: Text Data

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

lwiplog.txt
Description: Text document