[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #34426] TCP retransmission transmits 1 byte instead of
From: |
Min Xu |
Subject: |
[lwip-devel] [bug #34426] TCP retransmission transmits 1 byte instead of original packet, with incorrect byte value |
Date: |
Thu, 29 Sep 2011 00:15:00 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0 |
URL:
<http://savannah.nongnu.org/bugs/?34426>
Summary: TCP retransmission transmits 1 byte instead of
original packet, with incorrect byte value
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: maximalmin
Submitted on: Thu 29 Sep 2011 12:14:59 AM GMT
Category: TCP
Severity: 3 - Normal
Item Group: Faulty Behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: 1.4.0
_______________________________________________________
Details:
Hi
We have developed a driver for an integrated EMAC module on the TI DSP that
can achieve a high throughput using RAW / NO_SYS mode. In the following
description, DSP application is the software that is based on the LwIP stack
and the Desktop application is a Win32 application.
In order to maximize that throughput, we increased the receive buffer size on
the desktop application to 65535 (max). When the DSP application sends out
data, it first check the send buffer size available (by calling tcp_sndbuf).
When the returned value is large, the DSP application calls tcp_write (with
TCP_WRITE_FLAG_COPY) with a large payload. The problem however, is that when
the arp entry for the desktop has expired (either because ETHARP_TRUST_IP_MAC
was defined as 0, --OR-- MORE importantly, when there is a lack of network
activity for a while, and the desktop then initiates another transfer), each
of the packet that would've been sent out is then transmitted as an ARP REQ
(for desktop's IP address).
After the large number of ARPs (I have observed 43 consecutive ARP REQ, each
of which is dutifully responded by the desktop, corresponding to 62780 bytes
if each ARP REQ was representative of 1460 TCP payload), the DSP begins to
transmit a new packet, followed by "retransmission" of the lost TCP pdus.
However, after 1 ack, then a DUP ack from the desktop, the DSP transmits a 1
byte TCP packet 4 times (since there is only 1 DUP ack -- as captured by
Wireshark with large buffer -- , it's unlikely a fast retransmission). Each
of those 4 retransmits has the correct TCP and IP checksum, so there's no
memory corruption. The problem is that the next retransmission has the same
TCP sequence number (in example1.pcap, rel seqno = 347699281; in
example2.pcap, rel seqno = 22944221), but with the proper 1460 bytes payload,
and the first byte of the payload data has a different value from the 4
previous retransmissions.
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Thu 29 Sep 2011 12:14:59 AM GMT Name: example1.pcap Size: 44kB By:
maximalmin
Example wireshark capture showing the invalid retransmissions
<http://savannah.nongnu.org/bugs/download.php?file_id=24039>
-------------------------------------------------------
Date: Thu 29 Sep 2011 12:14:59 AM GMT Name: example2.pcap Size: 35kB By:
maximalmin
Example wireshark capture showing the invalid retransmissions
<http://savannah.nongnu.org/bugs/download.php?file_id=24040>
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?34426>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
- [lwip-devel] [bug #34426] TCP retransmission transmits 1 byte instead of original packet, with incorrect byte value,
Min Xu <=