Hi,
I've been experiencing some very strange network behaviour under various
versions of Linux, which can be provoked by just sending small amounts
of data to the echo port on a server.
The server is a Cobalt RAQ-3i (AMD-K6, kernel claims to be 2.2.12C3)
While I can only recreate the behaviour using this as a server, tcp
dumps of the network traffic seem to point the finger of blame at Linux
when it is a client.
The client machines are running 'cat text | nc cobalt-box 7'. "Text" is
a 8679 byte file.
The problem: several versions of the Linux kernel seem to be not sending
ACKs correctly to the server, causing a three second delay in reading
the text file back from the echo port. Other UNIX platforms get the data
back instantly (I've tried Solaris, FreeBSD, Digital UNIX and IRIX).
Linux 2.0.36 doesn't seem to show the problem. Linux 2.2.5, 2.2.13,
2.4.0-test10 do.
Heres a trace of the problem: the client here, hydra, is a Redhat 6 box,
with a 2.2.5 kernel. (tcpdump running on hydra)
10:10:15.842522 hydra.3700 > cobalt-box.echo: S 2004401205:2004401205(0) win 32120 <mss 1460,sackOK,timestamp 268081751[|tcp]> (DF)
10:10:15.842703 cobalt-box.echo > hydra.3700: S 605846935:605846935(0) ack 2004401206 win 32120 <mss 1460,sackOK,timestamp 15607468[|tcp]> (DF)
10:10:15.842744 hydra.3700 > cobalt-box.echo: . ack 1 win 32120 <nop,nop,timestamp 268081751 15607468> (DF)
10:10:15.843688 hydra.3700 > cobalt-box.echo: . 1:1449(1448) ack 1 win 32120 <nop,nop,timestamp 268081751 15607468> (DF)
10:10:15.844251 cobalt-box.echo > hydra.3700: . ack 1449 win 31856 <nop,nop,timestamp 15607468 268081751> (DF)
10:10:15.844299 hydra.3700 > cobalt-box.echo: . 1449:2897(1448) ack 1 win 32120 <nop,nop,timestamp 268081752 15607468> (DF)
10:10:15.844310 hydra.3700 > cobalt-box.echo: . 2897:4345(1448) ack 1 win 32120 <nop,nop,timestamp 268081752 15607468> (DF)
10:10:15.845002 cobalt-box.echo > hydra.3700: P 1:1449(1448) ack 1449 win 31856 <nop,nop,timestamp 0 268081751> (DF)
10:10:15.845050 hydra.3700 > cobalt-box.echo: . ack 1 win 32120 <nop,nop,timestamp 268081752 15607468> (DF)
10:10:15.845009 cobalt-box.echo > hydra.3700: . ack 4345 win 30408 <nop,nop,timestamp 15607468 268081752> (DF)
10:10:15.845076 hydra.3700 > cobalt-box.echo: . 4345:5793(1448) ack 1 win 32120 <nop,nop,timestamp 268081752 15607468> (DF)
10:10:15.845090 hydra.3700 > cobalt-box.echo: . 5793:7241(1448) ack 1 win 32120 <nop,nop,timestamp 268081752 15607468> (DF)
10:10:15.845101 hydra.3700 > cobalt-box.echo: FP 7241:8680(1439) ack 1 win 32120 <nop,nop,timestamp 268081752 15607468> (DF)
10:10:15.845773 cobalt-box.echo > hydra.3700: P 1449:2897(1448) ack 4345 win 31856 <nop,nop,timestamp 0 268081752> (DF)
10:10:15.845820 hydra.3700 > cobalt-box.echo: . ack 1 win 32120 <nop,nop,timestamp 268081752 15607468> (DF)
10:10:15.845780 cobalt-box.echo > hydra.3700: . ack 7241 win 30408 <nop,nop,timestamp 15607468 268081752> (DF)
10:10:15.845869 cobalt-box.echo > hydra.3700: . ack 8681 win 30408 <nop,nop,timestamp 15607469 268081752> (DF)
10:10:18.836367 cobalt-box.echo > hydra.3700: P 1:1449(1448) ack 8681 win 31856 <nop,nop,timestamp 15607768 268081752> (DF)
10:10:18.836421 hydra.3700 > cobalt-box.echo: . ack 1449 win 31856 <nop,nop,timestamp 268082051 15607768> (DF)
10:10:18.836961 cobalt-box.echo > hydra.3700: P 1449:2897(1448) ack 8681 win 31856 <nop,nop,timestamp 15607768 268082051> (DF)
10:10:18.844490 hydra.3700 > cobalt-box.echo: . ack 2897 win 31856 <nop,nop,timestamp 268082052 15607768> (DF)
10:10:18.845024 cobalt-box.echo > hydra.3700: P 2897:4345(1448) ack 8681 win 31856 <nop,nop,timestamp 15607768 268082052> (DF)
10:10:18.845148 cobalt-box.echo > hydra.3700: P 4345:5793(1448) ack 8681 win 31856 <nop,nop,timestamp 15607768 268082052> (DF)
10:10:18.845202 hydra.3700 > cobalt-box.echo: . ack 5793 win 30408 <nop,nop,timestamp 268082052 15607768> (DF)
10:10:18.845280 cobalt-box.echo > hydra.3700: P 5793:7241(1448) ack 8681 win 31856 <nop,nop,timestamp 15607768 268082052> (DF)
10:10:18.845400 cobalt-box.echo > hydra.3700: FP 7241:8680(1439) ack 8681 win 31856 <nop,nop,timestamp 15607768 268082052> (DF)
10:10:18.845446 hydra.3700 > cobalt-box.echo: . ack 8681 win 28960 <nop,nop,timestamp 268082052 15607768> (DF)
27 packets received by filter
0 packets dropped by kernel
Note the three second delay! From my reading of this, hydra never ACKs
any of the data received from the server prior to the delay. Only when
the server re-sends the first 1448 bytes after a three second timeout,
does it decide to ACK it. hydra does however seem to send out two
identical 'ack 1' packets. Has the second one got the wrong number in
it?
Any ideas whats going on? I'm no expert at reading tcpdumps, if anyone
can shed some light on the problem, I'd be most greatful.
Cheers,
Ben
Date: Thu, 9 Nov 2000 19:36:23 +0000 (GMT)
From: Ben Mansell <[email protected]>
Any ideas whats going on? I'm no expert at reading tcpdumps, if
anyone can shed some light on the problem, I'd be most greatful.
Anything less than ~2.2.16 are about as buggy as they come wrt. TCP
Please upgrade ;-)
Something is wrong with the Cobalt side, for sure:
10:10:15.845869 cobalt-box.echo > hydra.3700: . ack 8681 win 30408 <nop,nop,timestamp 15607469 268081752> (DF)
Cobalt sends the ACK, everything is fine.
10:10:18.836367 cobalt-box.echo > hydra.3700: P 1:1449(1448) ack 8681 win 31856 <nop,nop,timestamp 15607768 268081752> (DF)
Cobalt then waits for 3 seconds to send data bytes 1:1449
(ie. the echo service response).
10:10:18.836421 hydra.3700 > cobalt-box.echo: . ack 1449 win 31856 <nop,nop,timestamp 268082051 15607768> (DF)
Then hydra immediately ACKs. Hydra is perfectly fine.
Cobalt appears to delay wakeup of echo process to notify it that
data is ready. Ask Cobalt for a more recent 2.2.x kernel so that
maybe you can continue proper Zeus server tuning :-)
The other systems you tested which did not have the delay just do
not trigger the necessary conditions for the wakeup delay on the
Cobalt side, thats all.
Based upon this trace it is erroneous to blame anything but the
2.2.12 kernel on the Cobalt machine.
Later,
David S. Miller
[email protected]
On Thu, 9 Nov 2000, David S. Miller wrote:
> Any ideas whats going on? I'm no expert at reading tcpdumps, if
> anyone can shed some light on the problem, I'd be most greatful.
>
> Anything less than ~2.2.16 are about as buggy as they come wrt. TCP
> Please upgrade ;-)
A fair point! But I still can't see what the server is doing wrong,
which makes it look like the clients (inc 2.4.0-test10) are misbehaving.
> Something is wrong with the Cobalt side, for sure:
>
> 10:10:15.845869 cobalt-box.echo > hydra.3700: . ack 8681 win 30408 <nop,nop,timestamp 15607469 268081752> (DF)
>
> Cobalt sends the ACK, everything is fine.
>
> 10:10:18.836367 cobalt-box.echo > hydra.3700: P 1:1449(1448) ack 8681 win 31856 <nop,nop,timestamp 15607768 268081752> (DF)
>
> Cobalt then waits for 3 seconds to send data bytes 1:1449
> (ie. the echo service response).
This is a resend of the data sent on line 8 of the trace:
10:10:15.845002 cobalt-box.echo > hydra.3700: P 1:1449(1448) ack 1449 win 31856 <nop,nop,timestamp 0 268081751> (DF)
It looks like hydra didn't ACK this data, so the server eventually
re-sent it?
Ben
Date: Fri, 10 Nov 2000 10:13:21 +0000 (GMT)
From: Ben Mansell <[email protected]>
This is a resend of the data sent on line 8 of the trace:
10:10:15.845002 cobalt-box.echo > hydra.3700: P 1:1449(1448) ack 1449 win 31856 <nop,nop,timestamp 0 268081751> (DF)
It looks like hydra didn't ACK this data, so the server eventually
re-sent it?
Maybe hydra didn't even receive it. :-)
There are two things to make to solve this riddle.
First, reproduce this as you have been, and afterwards
check if various network error statistic counters have been
incremented. Here is a short list:
1) On the line from /proc/net/dev for the device used in the
transfer, any counter other than bytes or packets.
2) From /proc/net/snmp
Ip: InHdrErrors
Ip: InDiscards
Tcp: InErrs
Next, reproduce the problem and trace the session using tcpdump
simultaneously from both sides of the connection. This will answer
the "did the packets even make it to the other end" questions.
Thanks a lot for helping to hunt this down.
Later,
David S. Miller
[email protected]
Ok, heres more headache-inducing tcpdumps to look at :)
None of the error counters which you suggested to look at seem to
increase, on either end. I've found that everything works OK if the data
sent to the echo port fits into a single packet. Otherwise, we get the
apparently missing acks and the delays seen here.
To complicate (help?) matters, I've managed to get a trace from both
ends when it once mysteriously worked! I can't reproduce this, though.
Also, to keep stuff up to date, the traces below are running with a
2.4.0-test10 client, artemis.
First of all: the broken, delayed connection:
(client-side tcpdump)
11:05:32.540009 artemis.39061 > cobalt-box.echo: S 2264214878:2264214878(0) win 5840 <mss 1460,sackOK,timestamp 76152422[|tcp]> (DF)
11:05:32.540349 cobalt-box.echo > artemis.39061: S 2249548214:2249548214(0) ack 2264214879 win 32120 <mss 1460,sackOK,timestamp 24578676[|tcp]> (DF)
11:05:32.540417 artemis.39061 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76152422 24578676> (DF)
11:05:32.543134 artemis.39061 > cobalt-box.echo: . 1:1449(1448) ack 1 win 5840 <nop,nop,timestamp 76152422 24578676> (DF)
11:05:32.543155 artemis.39061 > cobalt-box.echo: P 1449:1601(152) ack 1 win 5840 <nop,nop,timestamp 76152422 24578676> (DF)
11:05:32.543580 artemis.39061 > cobalt-box.echo: F 1601:1601(0) ack 1 win 5840 <nop,nop,timestamp 76152422 24578676> (DF)
11:05:32.544908 cobalt-box.echo > artemis.39061: . ack 1449 win 31856 <nop,nop,timestamp 24578676 76152422> (DF)
11:05:32.544969 cobalt-box.echo > artemis.39061: . ack 1602 win 31703 <nop,nop,timestamp 24578676 76152422> (DF)
11:05:32.547518 cobalt-box.echo > artemis.39061: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 0 76152422> (DF)
11:05:32.547703 cobalt-box.echo > artemis.39061: FP 1449:1601(152) ack 1602 win 31856 <nop,nop,timestamp 24578676 76152422> (DF)
11:05:32.557370 artemis.39061 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76152424 24578676> (DF)
11:05:32.557441 artemis.39061 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76152424 24578676,nop,nop,[|tcp]> (DF)
11:05:35.539956 cobalt-box.echo > artemis.39061: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 24578976 76152424> (DF)
11:05:35.540076 artemis.39061 > cobalt-box.echo: . ack 1602 win 8688 <nop,nop,timestamp 76152722 24578976,nop,nop,[|tcp]> (DF)
(server-side)
11:05:32.431950 artemis.39061 > cobalt-box.echo: S 2264214878:2264214878(0) win 5840 <mss 1460,sackOK,timestamp 76152422[|tcp]> (DF)
11:05:32.431995 cobalt-box.echo > artemis.39061: S 2249548214:2249548214(0) ack 2264214879 win 32120 <mss 1460,sackOK,timestamp 24578676[|tcp]> (DF)
11:05:32.432345 artemis.39061 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76152422 24578676> (DF)
11:05:32.436493 artemis.39061 > cobalt-box.echo: . 1:1449(1448) ack 1 win 5840 <nop,nop,timestamp 76152422 24578676> (DF)
11:05:32.436559 cobalt-box.echo > artemis.39061: . ack 1449 win 31856 <nop,nop,timestamp 24578676 76152422> (DF)
11:05:32.436509 artemis.39061 > cobalt-box.echo: P 1449:1601(152) ack 1 win 5840 <nop,nop,timestamp 76152422 24578676> (DF)
11:05:32.436517 artemis.39061 > cobalt-box.echo: F 1601:1601(0) ack 1 win 5840 <nop,nop,timestamp 76152422 24578676> (DF)
11:05:32.436602 cobalt-box.echo > artemis.39061: . ack 1602 win 31703 <nop,nop,timestamp 24578676 76152422> (DF)
11:05:32.437733 cobalt-box.echo > artemis.39061: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 0 76152422> (DF)
11:05:32.438918 cobalt-box.echo > artemis.39061: FP 1449:1601(152) ack 1602 win 31856 <nop,nop,timestamp 24578676 76152422> (DF)
11:05:32.449304 artemis.39061 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76152424 24578676> (DF)
11:05:32.449394 artemis.39061 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76152424 24578676,nop,nop,[|tcp]> (DF)
11:05:35.430026 cobalt-box.echo > artemis.39061: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 24578976 76152424> (DF)
11:05:35.431885 artemis.39061 > cobalt-box.echo: . ack 1602 win 8688 <nop,nop,timestamp 76152722 24578976,nop,nop,[|tcp]> (DF)
And the working connection:
(client-side tcpdump)
11:05:22.483983 artemis.39059 > cobalt-box.echo: S 2257051654:2257051654(0) win 5840 <mss 1460,sackOK,timestamp 76151416[|tcp]> (DF)
11:05:22.484329 cobalt-box.echo > artemis.39059: S 2239718876:2239718876(0) ack 2257051655 win 32120 <mss 1460,sackOK,timestamp 24577670[|tcp]> (DF)
11:05:22.484391 artemis.39059 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76151416 24577670> (DF)
11:05:22.489099 artemis.39059 > cobalt-box.echo: . 1:1449(1448) ack 1 win 5840 <nop,nop,timestamp 76151417 24577670> (DF)
11:05:22.489127 artemis.39059 > cobalt-box.echo: P 1449:1601(152) ack 1 win 5840 <nop,nop,timestamp 76151417 24577670> (DF)
11:05:22.489476 artemis.39059 > cobalt-box.echo: F 1601:1601(0) ack 1 win 5840 <nop,nop,timestamp 76151417 24577670> (DF)
11:05:22.490861 cobalt-box.echo > artemis.39059: . ack 1449 win 31856 <nop,nop,timestamp 24577671 76151417> (DF)
11:05:22.492599 cobalt-box.echo > artemis.39059: P 1:1449(1448) ack 1449 win 31856 <nop,nop,timestamp 0 76151417> (DF)
11:05:22.492660 cobalt-box.echo > artemis.39059: . ack 1602 win 31856 <nop,nop,timestamp 24577671 76151417> (DF)
11:05:22.492910 artemis.39059 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76151417 24577671> (DF)
11:05:22.493168 cobalt-box.echo > artemis.39059: FP 1449:1601(152) ack 1602 win 31856 <nop,nop,timestamp 24577671 76151417> (DF)
11:05:22.501147 artemis.39059 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76151418 24577671,nop,nop,[|tcp]> (DF)
11:05:22.502903 cobalt-box.echo > artemis.39059: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 24577672 76151418> (DF)
11:05:22.506750 artemis.39059 > cobalt-box.echo: . ack 1602 win 8688 <nop,nop,timestamp 76151419 24577672,nop,nop,[|tcp]> (DF)
(server-side)
11:05:22.376433 artemis.39059 > cobalt-box.echo: S 2257051654:2257051654(0) win 5840 <mss 1460,sackOK,timestamp 76151416[|tcp]> (DF)
11:05:22.376493 cobalt-box.echo > artemis.39059: S 2239718876:2239718876(0) ack 2257051655 win 32120 <mss 1460,sackOK,timestamp 24577670[|tcp]> (DF)
11:05:22.376838 artemis.39059 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76151416 24577670> (DF)
11:05:22.382971 artemis.39059 > cobalt-box.echo: . 1:1449(1448) ack 1 win 5840 <nop,nop,timestamp 76151417 24577670> (DF)
11:05:22.383035 cobalt-box.echo > artemis.39059: . ack 1449 win 31856 <nop,nop,timestamp 24577671 76151417> (DF)
11:05:22.383329 cobalt-box.echo > artemis.39059: P 1:1449(1448) ack 1449 win 31856 <nop,nop,timestamp 0 76151417> (DF)
11:05:22.383426 artemis.39059 > cobalt-box.echo: P 1449:1601(152) ack 1 win 5840 <nop,nop,timestamp 76151417 24577670> (DF)
11:05:22.383467 artemis.39059 > cobalt-box.echo: F 1601:1601(0) ack 1 win 5840 <nop,nop,timestamp 76151417 24577670> (DF)
11:05:22.383513 cobalt-box.echo > artemis.39059: . ack 1602 win 31856 <nop,nop,timestamp 24577671 76151417> (DF)
11:05:22.384631 cobalt-box.echo > artemis.39059: FP 1449:1601(152) ack 1602 win 31856 <nop,nop,timestamp 24577671 76151417> (DF)
11:05:22.385584 artemis.39059 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76151417 24577671> (DF)
11:05:22.393606 artemis.39059 > cobalt-box.echo: . ack 1 win 5840 <nop,nop,timestamp 76151418 24577671,nop,nop,[|tcp]> (DF)
11:05:22.393643 cobalt-box.echo > artemis.39059: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 24577672 76151418> (DF)
11:05:22.399212 artemis.39059 > cobalt-box.echo: . ack 1602 win 8688 <nop,nop,timestamp 76151419 24577672,nop,nop,[|tcp]> (DF)
No packets seem to be lost on either end.
I hope this is of some help! If theres any more information needed, let
me know...
Ben
Date: Fri, 10 Nov 2000 11:49:13 +0000 (GMT)
From: Ben Mansell <[email protected]>
(client-side tcpdump)
...
11:05:32.547518 cobalt-box.echo > artemis.39061: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 0 76152422> (DF)
^^^^^^^^^^^
(server-side)
...
11:05:32.437733 cobalt-box.echo > artemis.39061: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 0 76152422> (DF)
^^^^^^^^^^^
Wheee... zero timestamp from Cobalt box. Artemis (correctly) drops
this packet (due to PAWS test because a zero timestamp is "older" than
the most recent timestamp Artemis saw from cobalt-box). Upgrade it's
kernel and retest :-)
Later,
David S. Miller
[email protected]
Date: Fri, 10 Nov 2000 03:46:02 -0800
From: "David S. Miller" <[email protected]>
Wheee... zero timestamp from Cobalt box. Artemis (correctly) drops
this packet (due to PAWS test because a zero timestamp is "older" than
the most recent timestamp Artemis saw from cobalt-box). Upgrade it's
kernel and retest :-)
BTW, I bet the platforms which "worked" to this Cobalt box
did not enable TCP timestamps for the connection.
Later,
David S. Miller
[email protected]
On Fri, 10 Nov 2000, David S. Miller wrote:
> Date: Fri, 10 Nov 2000 11:49:13 +0000 (GMT)
> From: Ben Mansell <[email protected]>
>
> (client-side tcpdump)
> ...
> 11:05:32.547518 cobalt-box.echo > artemis.39061: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 0 76152422> (DF)
> ^^^^^^^^^^^
>
> (server-side)
> ...
> 11:05:32.437733 cobalt-box.echo > artemis.39061: P 1:1449(1448) ack 1602 win 31856 <nop,nop,timestamp 0 76152422> (DF)
> ^^^^^^^^^^^
>
> Wheee... zero timestamp from Cobalt box. Artemis (correctly) drops
> this packet (due to PAWS test because a zero timestamp is "older" than
> the most recent timestamp Artemis saw from cobalt-box). Upgrade it's
> kernel and retest :-)
Bingo! Thanks very much for spotting this... yup, looks like the cobalt
box was at fault all along, and the clients that 'worked' were indeed
ignoring the timestamping.
The cobalt machines have now had a kernel upgrade (only to 2.2.14, thats
the most recent that Cobalt provide...), and the problem has
disappeared.
Thanks once more,
Ben
In article <[email protected]> you wrote:
> The cobalt machines have now had a kernel upgrade (only to 2.2.14, thats
> the most recent that Cobalt provide...), and the problem has
> disappeared.
Should we ignore "timestamp 0" if there are systems out there which will
break on that. Or is timestamp 0 a legal value?
Greetings
Bernd
From: Bernd Eckenfels <[email protected]>
Date: Sat, 11 Nov 2000 20:26:49 +0100
Or is timestamp 0 a legal value?
It is legal.
Later,
David S. Miller
[email protected]
On Sat, Nov 11, 2000 at 02:27:13PM -0800, David S. Miller wrote:
> From: Bernd Eckenfels <[email protected]>
> Date: Sat, 11 Nov 2000 20:26:49 +0100
>
> Or is timestamp 0 a legal value?
>
> It is legal.
NetBSD ignores 0 timestamps. Although that's a hack it is IMHO a reasonable one and
Linux should probably do it too. Even when the 0 is generated legitimately by wrapping
counters it is probably not a big problem to lose timestamps for such few packets.
-Andi
Hello!
> NetBSD ignores 0 timestamps. Although that's a hack it is IMHO a reasonable one and
> Linux should probably do it too. Even when the 0 is generated legitimately by wrapping
> counters it is probably not a big problem to lose timestamps for such few packets.
Sorry, ignoring some values of timestamp is simply impossible.
It is PAWS. One packet is more than enough to kill you. 8)
Zero _echo_ is ignored in RTTM, which is required by the way.
Alexey
Hello!
> The probability of just exactly the zero packet hitting you is very small.
... long laughter ...
Andi, I see you are not very strong in methematics. 8)
Timestamp is not a random number, so that probability of PAWS failure
does not depend on restricting it at all. The only thing which can help
to reduce probability is dropping all tpacket with ts_val==0
or shutting down your machine while time of your peers passes through zero. 8)
BTW I looked to netbsd and certainly did not find any signs of said by you.
They drop packet with ts_val before ts_recent, even if ts_val is zero.
They really have bug, considering zero value of ts_recent as invalid one.
This make PAWS something absolutely useless. 8)
Alexey
In article <[email protected]> you wrote:
> Timestamp is not a random number, so that probability of PAWS failure
> does not depend on restricting it at all. The only thing which can help
> to reduce probability is dropping all tpacket with ts_val==0
> or shutting down your machine while time of your peers passes through zero. 8)
But Timestamps are not increased by one every packet, so the likelyhood that
a wraparound
a) happens and
b) happens while a packet is send
is realy small.
Greetings
Bernd
In article <[email protected]> you wrote:
> Sorry, ignoring some values of timestamp is simply impossible.
> It is PAWS. One packet is more than enough to kill you. 8)
Hmm... Isnt this only important for the first SYN with a Zero Timestamp
which is not very critical for PAWS?
Greetings
Bernd