lwip-users
[Top][All Lists]
Advanced

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

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


From: Sergio R. Caprile
Subject: Re: [lwip-users] TCP ACK not received - Probably due to seq no.
Date: Wed, 10 Feb 2016 10:56:21 -0300
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

> 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.

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.
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 ?
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'

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.


-- 
Sergio R. Caprile, Human Being, Bs.As., Argentina
        http://www.scaprile.ldir.com.ar/



reply via email to

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