lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] TCP retransmissions and duplicate ACKs


From: Niall Donovan
Subject: Re: [lwip-users] TCP retransmissions and duplicate ACKs
Date: Mon, 9 Sep 2013 12:06:03 +0100

Hi Dawid,
   I had a similar problem and found that my driver was setting a receive water mark in the Phy Receive buffer (of my embedded system - a NIOS II processor with freeRTOS and lwIP 1.4.1) to a value which was greater than 64 bytes. The consequence was that any 64 byte packet (or packet whos size was less then the watermark level) the Phy received from my PC got stuck in the Phys Rx FIFO until the next packet came in and 'pushed' it out. The second packet, if it was 64 bytes, then got stuck. My socket link used lots of small packets and often the ACK is send in a small packet. The net result was that the lwIP TCP/IP timouts were firing and/or the PCs timouts fired and re-sends occurred and duplicate ACKs occurred. Eventually the socket hung.

The simple test I did was to send in a single 64 byte packet and see if it triggered the receive interrupt in my driver...it didn't until I re-adjusted the FIFO water mark.

This may not be your problem but it's a quick one to rule out.

Regards
Niall.


On 8 September 2013 16:14, Dawid Oosthuizen <address@hidden> wrote:
Hi,

Yet another ACK problem. I've read many of the topics around ACK behaviour, but have not been able to resolve my problem. Hopefully someone can help.

Device setup
lwip 1.4.1.
Bare metal on an ARM STM32F417.
Using raw TCP calls.
Device IP (obtained from DHCP) is 192.168.9.2, and it connects to server software running on an Ubuntu VM at 192.168.9.250 (which works just fine with previous versions of this product based on uIP 1.0.0).
tcp_tmr() is called at 250ms intervals.

Observations
See the attached Wireshark capture (25500.pcap), my device's debugging output (debug_capture.txt), lwip options (lwipopts.h)
TCP connection is established and some bidirectional communication occurs successfully, but after a while the lwip device does not seem to send an ACK on data received from the server, hence it retransmits.
A short while later, there is a bunch of packets from both sides which are retransmissions, and a number from the server which are shown as duplicate ACKs.
Eventually, tcp_write fails with a -1 (ERR_MEM).

Setup variations tried
I've had nagle enabled and disabled.
I've increased the buffer sizes and quantities, which only makes the problem appear much later. (the packets are tiny in any case)

Other observations which may or may not be applicable
It looks like the trouble starts around (just before/after) the appearance of this line: tcp_fasttmr: delayed ACK.
For some reason, lwip shows a 0x0000 checksum in it's debug output, but I don't see any 0 checksums in Wireshark:
LAN-lwip: IP header:
LAN-lwip: +-------------------------------+
LAN-lwip: | 4 | 5 |  0x00 |        91     | (v, hl, tos, len)
LAN-lwip: +-------------------------------+
LAN-lwip: |       12      |000|       0   | (id, flags, offset)
LAN-lwip: +-------------------------------+
LAN-lwip: |  255  |    6  |    0x0000     | (ttl, proto, chksum)
LAN-lwip: +-------------------------------+
LAN-lwip: |  192  |  168  |    9  |    2  | (src)
LAN-lwip: +-------------------------------+
LAN-lwip: |  192  |  168  |    9  |  250  | (dest)
LAN-lwip: +-------------------------------+
The LAN service routine (running at 3kHz) goes through the tcp_active_pcbs and calls tcp_write and tcp_output for any connection that has queued outgoing data.
The tcp_recv callback function does not call tcp_write (or tcp_output).
The tcp_sent callback function does nothing.
The sequence numbers don't quite make sense to me (big jumps between "Sequence number" and indicated ["Next sequence number"]).

Some insights would be awesome.

Regards,
Dawid

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


reply via email to

[Prev in Thread] Current Thread [Next in Thread]