* TCP hangs --- zero window probes
@ 2004-05-04 14:26 Mikulas Patocka
2004-05-04 15:25 ` Praveen Kumar Amritaluru
0 siblings, 1 reply; 4+ messages in thread
From: Mikulas Patocka @ 2004-05-04 14:26 UTC (permalink / raw)
To: netdev
Hi
This is tcpdump of hung TCP connection (from paranoia.kolej.mff.cuni.cz's
point of view). It looks like Linux did misbehave.
213.29.7.213 is a Linux box. (don't know which version, I have no access
to it).
paranoia.kolej.mff.cuni.cz is stack that I wrote myself.
Linux is sending only ACKs without any data as zero-window probes. My
stack ignores them. People at IETF tcp mailing lists told me that it's
linux bug, that window probe must contain some new data.
Is it known bug in Linux? What workaround do you suggest?
Mikulas
16:34:49.832097 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: SWE 1711254266:1711254266(0) win 8192 <mss 1460,sackOK,wscale 10,eol>
16:34:49.838957 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: S 1163781419:1163781419(0) ack 1711254267 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 0>
16:34:49.838968 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 1 win 8
16:34:49.840002 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P 1:500(499) ack 1 win 8
16:34:49.847349 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
16:34:49.863592 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 1:1461(1460) ack 500 win 6432
16:34:49.863651 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 1461 win 6
16:34:49.867490 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 1461:2921(1460) ack 500 win 6432
16:34:49.867558 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 2921 win 6
16:34:49.871498 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 2921:4381(1460) ack 500 win 6432
16:34:49.871567 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 4381 win 5
16:34:49.872729 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 4381:5841(1460) ack 500 win 6432
16:34:49.872777 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 5841 win 3
16:34:49.875631 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 7301:8761(1460) ack 500 win 6432
16:34:49.875714 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 5841 win 3 <nop,nop,sack sack 1 {7301:8761} >
16:34:49.876881 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 5841:7301(1460) ack 500 win 6432
16:34:49.876953 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 8761 win 0
16:34:49.907290 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 8761 win 2
^^^^ this packet was probably lost or the last two were reordered
16:34:50.088544 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
16:34:50.512936 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
^^^ this looks to me like a bug --- window probe doesn't contain data
16:34:51.348911 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
16:34:53.028754 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
16:34:56.389624 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
16:35:03.110512 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
^^^ exponential backoff on window probes is fine, except that the packets are pure acks
16:35:16.552095 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
16:35:43.435482 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
16:35:58.706896 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: FP 500:500(0) ack 8761 win 17
^^^ paranoia closed the connection without receiving any data
16:35:58.717487 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 10221:11681(1460) ack 501 win 6432
16:35:58.717569 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: R 501:501(0) ack 11681 win 0
16:35:58.718673 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 8761:10221(1460) ack 501 win 6432
16:35:58.718692 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: R 501:501(0) ack 10221 win 0
16:35:58.720054 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 11681:13141(1460) ack 501 win 6432
16:35:58.720074 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: R 501:501(0) ack 13141 win 0
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TCP hangs --- zero window probes
2004-05-04 14:26 Mikulas Patocka
@ 2004-05-04 15:25 ` Praveen Kumar Amritaluru
2004-05-04 16:28 ` Mikulas Patocka
0 siblings, 1 reply; 4+ messages in thread
From: Praveen Kumar Amritaluru @ 2004-05-04 15:25 UTC (permalink / raw)
To: mikulas; +Cc: netdev
Hi,
I raised a similar issue sometime back on this mailing list. It
is basically non-conformance of RFC.
Its not that Linux is sending ACK only packets rather it is
sending an unacceptable ACK segment forcing the receiver to send
an ACK. Use Ethereal to view the ACK segments since that will
show the sequence no. as well.
I feel that it is a bug, but others may not feel the same way.
The clarification/justification I heard in this mailing-list was
that "this implementation is more interoperable with other
implementations" compared to "sending zero window probes" as
defined in RFC793/RFC1122.
Regards,
Praveen
> Hi
>
> This is tcpdump of hung TCP connection (from paranoia.kolej.mff.cuni.cz's
> point of view). It looks like Linux did misbehave.
>
> 213.29.7.213 is a Linux box. (don't know which version, I have no access
> to it).
> paranoia.kolej.mff.cuni.cz is stack that I wrote myself.
>
> Linux is sending only ACKs without any data as zero-window probes. My
> stack ignores them. People at IETF tcp mailing lists told me that it's
> linux bug, that window probe must contain some new data.
>
> Is it known bug in Linux? What workaround do you suggest?
>
> Mikulas
>
> 16:34:49.832097 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: SWE 1711254266:1711254266(0) win 8192 <mss 1460,sackOK,wscale 10,eol>
> 16:34:49.838957 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: S 1163781419:1163781419(0) ack 1711254267 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 0>
> 16:34:49.838968 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 1 win 8
> 16:34:49.840002 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P 1:500(499) ack 1 win 8
> 16:34:49.847349 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
> 16:34:49.863592 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 1:1461(1460) ack 500 win 6432
> 16:34:49.863651 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 1461 win 6
> 16:34:49.867490 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 1461:2921(1460) ack 500 win 6432
> 16:34:49.867558 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 2921 win 6
> 16:34:49.871498 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 2921:4381(1460) ack 500 win 6432
> 16:34:49.871567 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 4381 win 5
> 16:34:49.872729 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 4381:5841(1460) ack 500 win 6432
> 16:34:49.872777 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 5841 win 3
> 16:34:49.875631 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 7301:8761(1460) ack 500 win 6432
> 16:34:49.875714 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 5841 win 3 <nop,nop,sack sack 1 {7301:8761} >
> 16:34:49.876881 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 5841:7301(1460) ack 500 win 6432
> 16:34:49.876953 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 8761 win 0
> 16:34:49.907290 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 8761 win 2
> ^^^^ this packet was probably lost or the last two were reordered
> 16:34:50.088544 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
> 16:34:50.512936 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
> ^^^ this looks to me like a bug --- window probe doesn't contain data
> 16:34:51.348911 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
> 16:34:53.028754 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
> 16:34:56.389624 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
> 16:35:03.110512 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
> ^^^ exponential backoff on window probes is fine, except that the packets are pure acks
> 16:35:16.552095 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
> 16:35:43.435482 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432
> 16:35:58.706896 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: FP 500:500(0) ack 8761 win 17
> ^^^ paranoia closed the connection without receiving any data
> 16:35:58.717487 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 10221:11681(1460) ack 501 win 6432
> 16:35:58.717569 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: R 501:501(0) ack 11681 win 0
> 16:35:58.718673 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 8761:10221(1460) ack 501 win 6432
> 16:35:58.718692 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: R 501:501(0) ack 10221 win 0
> 16:35:58.720054 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 11681:13141(1460) ack 501 win 6432
> 16:35:58.720074 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: R 501:501(0) ack 13141 win 0
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TCP hangs --- zero window probes
2004-05-04 15:25 ` Praveen Kumar Amritaluru
@ 2004-05-04 16:28 ` Mikulas Patocka
0 siblings, 0 replies; 4+ messages in thread
From: Mikulas Patocka @ 2004-05-04 16:28 UTC (permalink / raw)
To: Praveen Kumar Amritaluru; +Cc: netdev
> Hi,
>
> I raised a similar issue sometime back on this mailing list. It
> is basically non-conformance of RFC.
>
> Its not that Linux is sending ACK only packets rather it is
> sending an unacceptable ACK segment forcing the receiver to send
> an ACK. Use Ethereal to view the ACK segments since that will
> show the sequence no. as well.
>
> I feel that it is a bug, but others may not feel the same way.
>
> The clarification/justification I heard in this mailing-list was
> that "this implementation is more interoperable with other
> implementations" compared to "sending zero window probes" as
> defined in RFC793/RFC1122.
>
>
> Regards,
>
> Praveen
Yes. I fixed the client so that it sends ACKs if it receives ACK with
non-matching seq number.
Mikulas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TCP hangs --- zero window probes
@ 2004-05-05 7:49 Ronnie Sahlberg
0 siblings, 0 replies; 4+ messages in thread
From: Ronnie Sahlberg @ 2004-05-05 7:49 UTC (permalink / raw)
To: netdev
Are you sure they are zero window probes and not normal keep-alives?
A zero window probe contains one byte of payload just beyong the right edge
of the window, thats why they are
called zero window probes : send one extra byte of data even though the
window is zero to opportunistically probe
if the window has opened again.
zero window probes also usually run on a normal constant timer and usually
do not contain any exponential backoff.
a tcp keepalive on the other hand usually
transmit an "invalid" segment containing zer or 1 byte of payload just one
byte prior to the left edge of the window.
These usually have an exponential backoff in the same way as normal data
segments have.
These segments have deliberately an sequence number outside of the expected
window so that they will
trigger an immediate ACK to be sent back from the other side.
An implementation that can not send an immediate ACK back to a keep-alive is
completely broken.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-05-05 7:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-05 7:49 TCP hangs --- zero window probes Ronnie Sahlberg
-- strict thread matches above, loose matches on Subject: below --
2004-05-04 14:26 Mikulas Patocka
2004-05-04 15:25 ` Praveen Kumar Amritaluru
2004-05-04 16:28 ` Mikulas Patocka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox