[lwip-users] Re: [lwip] Newbie TCP problem

[Adam Dunkels]

Hi Andy!

On Friday 04 January 2002 18.43, you wrote:
> Thanks very much for the suggestion. Unfortunately it doesn't seem to have
> the desired effect.
> lwip now does ACK the empty segment from Linux but this doesn't seem to
> prompt Linux to send any more data packets.
>
> I have noticed that after the final data segment is sent from Linux lwip
> immediately responds with an ACK (as you would expect). However, there is
> then a pause of a couple of seconds before Linux sends out it's first
> Keep-Alive message. lwip does then immediately ACK each of the Keep-Alive
> messages but Linux just keeps sending them at increasing intervals as
> before.
>
> I am puzzled as to why Linux should send out any Keep-Alive messages. I
> have checked the SO_KEEPALIVE socket option on the socket that I'm using
> and the value is 0, presumably meaning that the KEEPALIVE option is turned
> off. Even if it were on, I would have thought that the first message should
> not be sent for a couple of hours (the tcp_keepalive_time sysctl is set to
> 7200 seconds).
>
> Do you know of any other circumstances that can cause the sender to send an
> empty segment with an ACK sequence number 1 less than the expected value?

It could be a window probe - when the receiver advertises a 0 window, the 
sender starts sending window probe packets to see if the window has opened.

> I updated to lwip 0.5.0 before adding the code that you suggested but
> obviously this hasn't helped either. In fact it has introduced another
> problem: If I write small packets of 128 bytes into the socket, with a 1
> second gap between them, Linux sends these out immediately with the
> segment's PSH flag set. lwip never ACKs these packets so Linux just resends
> the first segment over and over. This did not happen with 0.4.1 - each
> segment was ACK'd properly.

That's wierd!

Could you please send me packet traces of both these events (mail to me 
privately, outside of the list)? Use tcpdump to produce the trace like this:

# tcpdump -w dumpfile -s 0 -i <interface>

where <interface> should be the actual network interface you are using. This 
could probably help me either find a fix to your problem or to the bug that 
causes your problem.

Again, send it to me in a private message.

Thanks,

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]