[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,
Matthijs
http_get.c
Description: Text Data
download_try006_filter.pcap
Description: application/vnd.tcpdump.pcap
lwiplog.txt
Description: Text document