lwIP - A Lightweight TCP/IP stack - Bugs: bug #60402, Transmitting TCP packets stops...
You are not allowed to post comments on this tracker with your current authentication level.
bug #60402: Transmitting TCP packets stops after TCP window update is received
Submitter: | Peter Begella <begi> | ||
Submitted: | Fri 16 Apr 2021 09:39:26 AM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Planned Release: | None |
lwIP version: | 2.1.1 |
Attached Files
file #51276: tcp_1s_stop_and_retransmission_after_window_update.pcapng added by begi (58KiB - application/octet-stream)
file #51277: tcp_1s_stop_after_window_update.pcapng added by begi (29KiB - application/octet-stream)
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2021-04-16 | begi | Attached File | - | Added tcp_1s_stop_and_retransmission_after_window_update.pcapng, #51276 | |
Attached File | - | Added tcp_1s_stop_after_window_update.pcapng, #51277 | |||
Carbon-Copy | - | Added begi |
Powered by Savane 3.13-d3ae.
Corresponding source code
Hi lwIP developers,
First of all let me thank you your work.
Unfortunately I ran into an issue on Xilinx Zynq7000 system where we use lwip211_v1_1 for transmitting large amount of data over TCP with at least 550Mbit/s throughput.
This is easily achievable (max. is 930Mbit/s) however sometimes there is a glitch somewhere which results in a 1s stop in the transmission. This happens randomly and always comes after a received a TCP Window Update packet.
The only thing I was able to figure out that there are two type of issues which might be caused by the same error.
1. In case TCP_WRITE_FLAG_MORE is not always passed to tcp_write() (for the last portion of the buffer that is transmitted is not set) then the issue comes with a TCP Spurious Retransmission beside the 1s glitch.
2. In case the TCP_WRITE_FLAG_MORE is always passed to tcp_write() then the only symptom is the 1s stop.
Our TCP code is simple.
1. When data is available then send as many data as possible
using tcp_sendbuf() to learn the count then tcp_write() and then tcp_output().
2. From the TCP send callback do the same until all data is acked.
3. Send next buffer if data is available
I have attached two small pcap logs where the issue can be seen.
Can you please suggest a way how to track the issue?
Thank you in advance!