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
-
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
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
-
To
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
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
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
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
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
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
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
Date: Fri, 10 Nov 2000 10:13:21 + (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
(DF)
It looks like hydra didn't ACK this data, so the
Date: Fri, 10 Nov 2000 10:13:21 + (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
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
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
14 matches
Mail list logo
