lkml.org 
[lkml]   [1999]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: timestamps, tcp_paws_discard and out of order packets/acks (fwd)
Why do some of the packets in leeloo's tcpdump appear out of order?  (#7
below is stamped before #6)

00:40:38.361622 leeloo.1023 > mole.22: P 0:20(20) ack 1 win 31856 <nop,nop,timestamp 262843 214024> (DF) [tos 0x10]
00:40:38.415734 mole.22 > leeloo.1023: P 2897:4301(1404) ack 20 win 32120 <nop,nop,timestamp 218511 262823> (DF) [tos 0x10]
00:40:38.415862 leeloo.1023 > mole.22: . ack 1 win 31856 <nop,nop,timestamp 262848 218511,nop,nop,[|tcp]> (DF) [tos 0x10]
00:40:38.421972 leeloo.1023 > mole.22: P 20:40(20) ack 1 win 31856 <nop,nop,timestamp 262849 218511,nop,nop,[|tcp]> (DF) [tos 0x10]
00:40:38.428937 mole.22 > leeloo.1023: P 1:1449(1448) ack 20 win 32120 <nop,nop,timestamp 218511 262823> (DF) [tos 0x10]
00:40:38.429063 leeloo.1023 > mole.22: . ack 1449 win 30408 <nop,nop,timestamp 262849 218511,nop,nop,[|tcp]> (DF) [tos 0x10]
00:40:38.428962 mole.22 > leeloo.1023: . ack 20 win 32120 <nop,nop,timestamp 218529 262843> (DF) [tos 0x10]
00:40:38.442884 mole.22 > leeloo.1023: P 1449:2897(1448) ack 20 win 32120 <nop,nop,timestamp 218511 262823> (DF) [tos 0x10]
00:40:38.442966 leeloo.1023 > mole.22: . ack 1449 win 30408 <nop,nop,timestamp 262851 218529,nop,nop,[|tcp]> (DF) [tos 0x10]

That scares me already. Ignoring those, though, and paying attention to
leeloo's tcp state, and only showing the other side's timestamp numbers,
we see:

0 ms: send 20
54 ms: accept out-of-order 4301 with ack 20
54 ms: ack 1
60 ms: send 40, still acking 1
67 ms: accept in-order 1449 with ack 20, set ts_recent = 218511
67 ms: ack 1449
67 ms: receive dup ack of 20 with ts_val 218529 (set ts_recent?)
81 ms: reject in-order 2897 with ack 20 ts_val 218511 (ts_val < ts_recent)
81 ms: ack 1449 with ts_ecr = 218529

It's not clear to me from rfc1323 that leeloo should be setting
ts_recent for the dup ack packet it gets. Can an expert verify this
is the correct behavior? If so, you're just hosed by the massive
reordering. The trace from the other end does think it's sending the
packets out in the correct order.

-- Pete

blah@kvack.org said:
> I'm resending this to linux-kernel as netdev hasn't sent out any messages
> in the past week (at least to me).
>
> ---------- Forwarded message ----------
> Date: Wed, 14 Jul 1999 20:15:21 -0400 (EDT)
> From: "Benjamin C.R. LaHaise" <blah@kvack.org>
> To: netdev@nuclecu.unam.mx
> Subject: timestamps, paws and out of order packets/acks
>
> Hello all,
>
> I'm wondering if anyone has tackled the problem I pointed out a while ago
> where an ack manages to arrive before data sent on the same connection
> due, causing the tcp paws support in 2.2/2.3 to dump the data packet? The
> traces at http://www.kvack.org/~blah/a.(leeloo|mole) are still valid
> against 2.3.10, and the behaviour disappears when timestamps are disabled.
> Debugging verified that tcp_paws_discard is the source of the packet
> drops, specifically the second term (...tsval - tp->ts_recent) < 0.
>
> -ben

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:2.214 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site