[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] strange TCP ack
From: |
Kieran Mansley |
Subject: |
Re: [lwip-users] strange TCP ack |
Date: |
Tue, 27 Apr 2010 15:55:07 +0100 |
On Tue, 2010-04-27 at 21:24 +0800, yueyue papa wrote:
> >>Have you attached the right packet capture?
> i check. It is right.
>
> >>The IP addresses don't match the ones in your email,
> I am not understand. One is 192.168.8.130, another is 192.168.8.40.
> There are only two IP address in the capture.
My apologies - I was looking at a similarly named file from an earlier
problem.
> >> I can't see either end ACKing 1024 bytes of a segment.
> Item 4: 192.168.8.40 send 1400 bytes to 192.168.8.130 (server in vista)
> Item 5: 192.168.8.130 only ack 1025. 1400 is get, it should ack 1401
> (like item 7)
> Item 6: Due to the windows strange ACK, lwIP resend after 5s
> Item 7: acked by lwIP. One echo finihsed.
>
> I am not understand this flow.
>
> 1. why lwIP resend after 5s.
lwIP will resend when the retransmission timeout (RTO) occurs. This
should be closer to 500ms rather than 5s, but the RTO is a dynamic value
that changes for each connection. TCP tries to measure the round trip
time and base the RTO on that. It is initialized in tcp_alloc():
pcb->rto = 3000 / TCP_SLOW_INTERVAL;
and then updated when ACKs are received back. There are debug log
statements you can enable to see how it changes.
If you think it is wrong, check that TCP_SLOW_INTERVAL is set correctly,
and that your port is calling tcp_tmr() at the correct frequency.
> 2. why windows ack 1025.
It looks like it is being a bit naughty, and lwIP does not cope will
with this. It initially offers 8K of window space in the SYN-ACK. When
it receives data it decides to decrease the available window to 1K.
I.e. it's going back on what it previously advertised we could do. I
don't know why it does this, nor why it throws away and refuses to ACK
part of the packet - it seems a very odd thing to do as it forces a
retransmission which is very slow. It is then expecting lwIP to
re-segment the frames and send the next portion, but lwIP prefers to
just wait for the window to get bigger as re-segmenting is hard work for
a small device.
Kieran