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 <[email protected]>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_pcbsand > callstcp_writeand > 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
