Re: [lwip-users] TCP ACK not received - Probably due to seq no.

[Sergio R. Caprile]

Have you checked the tcp_write() return code ?
Do you call tcp_sndbuf() to see what your available room is ? You seem
to have said so in the first thread, so you actually get out of buffer
space.
Maybe you don't free your received pbufs.
Do you know you have to wait for the other end to send ACKs so the stack
can free your transmitted buffers and signal you can send more by means
of the tcp_sent() callback ?

> Once .10 starts sending data, after 300ms, the seq no it sends with is
> 1 and the ACK field is 1461. However, .74 sends back an ACK with 9251.

No, it is not, you are confusing seq numbers with ACK numbers, the
sequence is correct as far as I understand how TCP works. Unfortunately
I don't have the time nor is this the space for a TCP crash course.
ACK numbers reflect the expected seq numbers for the next message from
the other end. In frame 19, .10 is acknowledging it got data upto 9251
(next data byte will be 9252) and sending 1446 bytes starting from 1 at
the same time (piggybacked ACK).

Regarding that jumbo frame, I don't know what stack is running on .74
and why it does that.
Furthermore, the fact that .10 issues to ACKs for that, one in frame 18
and the other piggybacked in frame 19, makes me think that actually two
frames got out and what we see is an artifact of the capture driver on
.74 where you run wireshark because it is a PC or equivalent (what you
don't say)
I would check on .10 what it sees and why it can't transmit.
You have statistics you can enable and see how memory pools are being
handled.
You can put breakpoints and check return codes.
Your problem, IMO, is in your application, but there is a possibility
you have a broken driver/port or something else.