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

[Gaurav Jain]

I am not that well versed with nuances of TCP/IP and LWIP. So I may
need a little detailed help from you.
Please find my reply inline.

On Wed, Feb 10, 2016 at 7:26 PM, Sergio R. Caprile <address@hidden> wrote:
>> My port actually works and I know that because, if I change the mode
>> to immediate loopback mode, i.e. the data received in packet is sent
>> back to the client
>
> Sorry, I'm not convinced by that.
> Maybe I'm too old or too strict but I need to see a known good
> application from the contrib tree running OK. However, that is just my
> opinion.

I would capture the trace for some application from the contrib tree
and get back.

> Looking at your capture, I see:
>
> .74 sends something to .10. Do I have to guess .74 is your PC and -10 is
> your lwIP box ? Looking at their MAC addresses, I think my guess is an
> educated guess.
> IP checksums for .74 are marked as bad. Maybe due to IP checksum offload
> in your PC and you running wireshark on that very same PC.
> TCP checksums for .74are marked as bad. Maybe due to TCP checksum
> offload in your PC and you running wireshark on that very same PC.
>
> .74 sends 4 x 1460 + oops 1951 [(?) you are not supposed to do that on
> plain Ethernet] = 9251 bytes. I'm not able to help on jumbo frames.

Even I could not understand why is it sending the last one as 1951
bytes. The case is that there is 9KB data. So after sending 1460*4
bytes, rather than sending 1460 bytes and then the remaining bytes in
a different packet, it clubs them and sends them as 1951 bytes. I was
hoping you could help.

> Data always starts with 'mdsp' and then counts up starting from '00' in
> the first segment and then keeping the count up from previous segment.
> Data ends with 'mda123', after the count stopping at 'ff'
> .10 ACKs your data, even the abnormal length frame, though it does so in
> two ACKs. Total data received is 9251 bytes; frame 19, where .10 also
> starts sending, and this happens 300ms after the first one of the two
> ACKs. Something happened inside .10
> .10 sends 5 x 1446 + 450 = 7680
> .74 ACKs that data, though the final ACK is 200ms after final data,
> maybe it was expecting more data ?

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.
Now why should that be? Yes it was expected more data. There is a
footer that is sent after all the data from the DDR is sent. However
since the transaction never goes past 7680 bytes, the footer is not
sent and the client never knows that the transaction was complete and
it should close the connection.

> Data counts up starting from '00' in the first segment and then keeping
> the count up from previous segment. There is no "header". There is no
> trailer, and the count stops at 'a7'

Yes the "header" and "footer" have been truncated.

> Seqnos are correct, data is ACKed by both sides, so the communication
> takes place. If there is a problem, it seems to be at the application
> layer. If there is a network/transport problem (besides the obvious
> checksums), I don't see it.

If the data is ACKed  by both sides then why does not the send buffer
restore to the original size after every ACK received? Isn't it how
the LWIP send_buf supposed to work?