[lwip-devel] [bug #34426] TCP retransmission transmits 1 byte instead of original packet, with incorrect byte value

[Min Xu]

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/