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.
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).
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:
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.
debug_output.txt
25500.pcap