Hi!
Thanks for the hint.
It is rather difficult to switch to the newest kernel on this system. It
uses a lot of custom-made patches, which should be adapted to 2.6.24.
So this will take quite some time.
Meanwhile, I was wondering if this RST is a result of the local
application closing the socket too soon.
In /net/ipv4/tcp.c: tcp_disconnect()
As I see, a RST is generated, when there is still something in the send
buffer when closing the socket.
I'll try to get the app. developer's opinion.
The TCP stack, when I close the socket, and there is still data in the
send (or maybe even in the receive) buffer, sends a RST.
Am I seeing this correctly?
B.R, Gergely.
Varun Chandramohan wrote:
Gergely Magyarosi wrote:
I have noticed a strange behavior with heavy traffic.
Linux TCP stack resets connection, after exchanging 3 ACKs with zero
advertised window size.
That is:
1. ACK, win=0,len=0 received from peer
ACK, win=0, len=0 sent to peer
2. same as 1.
3. ACK, win=0,len=0 received from peer
RST, ACK, win >0, len=0 sent to peer
The sequence numbers remain the same, because neither side can send.
3rd ACK received frequently triggers a RST. (It shouldn't IMHO,
according to RFC.)
Is this a feature for conserving resources, or a bug?
the kernel version: 2.6.5
Does the same happen with newer kernels? 2.6.24?
Regards,
Varun
Thanks.
Best Regards, Gergely Magyarosi.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
