Hello!
> Why is it a bug to accept the ACK from it? RFC793 page 69 says
>
> If the RCV.WND is zero, no segments will be acceptable, but
> special allowance should be made to accept valid ACKs, URGs and
> RSTs.
8) This obscure place is discussed for ages. The question is:
What is
Hello!
Why is it a bug to accept the ACK from it? RFC793 page 69 says
If the RCV.WND is zero, no segments will be acceptable, but
special allowance should be made to accept valid ACKs, URGs and
RSTs.
8) This obscure place is discussed for ages. The question is:
What is
Replying to Alexey's message from the mailing list archive:
> Hello!
>
> I take my words back. Manfred is right, this requirement is not a MUST.
>
> Real problem is much worse, and it is wholly on the shame of solaris.
> Tcpdump shows at least two different bugs there.
>
> 2060
Replying to Alexey's message from the mailing list archive:
Hello!
I take my words back. Manfred is right, this requirement is not a MUST.
Real problem is much worse, and it is wholly on the shame of solaris.
Tcpdump shows at least two different bugs there.
2060 16:31:42.879337
Hello!
I take my words back. Manfred is right, this requirement is not a MUST.
Real problem is much worse, and it is wholly on the shame of solaris.
Tcpdump shows at least two different bugs there.
2060 16:31:42.879337 eth0 < dynamic.ih.lucent.com.39406 > static.8664: . 675
80:67580(0) ack
On Thu, Jan 25, 2001 at 12:24:11PM +, Studierende der Universitaet des Saarlandes
wrote:
> Andi wrote:
> > Basically it would accept the acks with the data in most
> > cases except when the application has totally stopped
> > reading and in that case it doesn't harm to ignore the
> > acks.
On Thu, 25 Jan 2001, James Sutherland wrote:
> This isn't a violation - the section quoted does not REQUIRE the
> behaviour, it only RECOMMENDS it as being a good idea. Since implementing
> it apparently makes DoS attacks easier, NOT implementing it is now a
> better idea...
Ok, now for the
On Thu, 25 Jan 2001, David S. Miller wrote:
>
> Andi Kleen writes:
> > It's mostly for security to make it more difficult to nuke connections
> > without knowing the sequence number.
> >
> > Remember RFC is from a very different internet with much less DoS attacks.
>
> Andi, one of the
Andi wrote:
> Basically it would accept the acks with the data in most
> cases except when the application has totally stopped
> reading and in that case it doesn't harm to ignore the
> acks.
But it seems that that's exactly what rsync does:
It performs bulk data writes without reading. There
On Thu, 25 Jan 2001, Matthias Andree wrote:
> On Wed, 24 Jan 2001, Andi Kleen wrote:
>
> > It's mostly for security to make it more difficult to nuke connections
> > without knowing the sequence number.
> >
> > Remember RFC is from a very different internet with much less DoS attacks.
>
> If
On Thu, Jan 25, 2001 at 03:44:07AM -0800, David S. Miller wrote:
>
> Andi Kleen writes:
> > > BSD and Solaris both make these kinds of packets, therefore it is must
> > > to handle them properly. So we will fix Linux, there is no argument.
> >
> > How do you propose to handle them? Queue
Andi Kleen writes:
> > BSD and Solaris both make these kinds of packets, therefore it is must
> > to handle them properly. So we will fix Linux, there is no argument.
>
> How do you propose to handle them? Queue the data anyways or just process
> the ACK?
tcp_sequence returns two flag
On Thu, Jan 25, 2001 at 03:32:44AM -0800, David S. Miller wrote:
>
> Andi Kleen writes:
> > It's mostly for security to make it more difficult to nuke connections
> > without knowing the sequence number.
> >
> > Remember RFC is from a very different internet with much less DoS attacks.
>
>
Andi Kleen writes:
> It's mostly for security to make it more difficult to nuke connections
> without knowing the sequence number.
>
> Remember RFC is from a very different internet with much less DoS attacks.
Andi, one of the worst DoSs in the world is not being able to
communicate with
On Wed, 24 Jan 2001, Andi Kleen wrote:
> It's mostly for security to make it more difficult to nuke connections
> without knowing the sequence number.
>
> Remember RFC is from a very different internet with much less DoS attacks.
If you're deliberately breaking compatibility by violating the
On Wed, 24 Jan 2001, Andi Kleen wrote:
It's mostly for security to make it more difficult to nuke connections
without knowing the sequence number.
Remember RFC is from a very different internet with much less DoS attacks.
If you're deliberately breaking compatibility by violating the
Andi Kleen writes:
It's mostly for security to make it more difficult to nuke connections
without knowing the sequence number.
Remember RFC is from a very different internet with much less DoS attacks.
Andi, one of the worst DoSs in the world is not being able to
communicate with half
On Thu, 25 Jan 2001, Matthias Andree wrote:
On Wed, 24 Jan 2001, Andi Kleen wrote:
It's mostly for security to make it more difficult to nuke connections
without knowing the sequence number.
Remember RFC is from a very different internet with much less DoS attacks.
If you're
On Thu, 25 Jan 2001, James Sutherland wrote:
This isn't a violation - the section quoted does not REQUIRE the
behaviour, it only RECOMMENDS it as being a good idea. Since implementing
it apparently makes DoS attacks easier, NOT implementing it is now a
better idea...
Ok, now for the
Andi wrote:
Basically it would accept the acks with the data in most
cases except when the application has totally stopped
reading and in that case it doesn't harm to ignore the
acks.
But it seems that that's exactly what rsync does:
It performs bulk data writes without reading. There are
On Thu, 25 Jan 2001, David S. Miller wrote:
Andi Kleen writes:
It's mostly for security to make it more difficult to nuke connections
without knowing the sequence number.
Remember RFC is from a very different internet with much less DoS attacks.
Andi, one of the worst DoSs in
On Thu, Jan 25, 2001 at 12:24:11PM +, Studierende der Universitaet des Saarlandes
wrote:
Andi wrote:
Basically it would accept the acks with the data in most
cases except when the application has totally stopped
reading and in that case it doesn't harm to ignore the
acks.
But it
On Thu, Jan 25, 2001 at 03:32:44AM -0800, David S. Miller wrote:
Andi Kleen writes:
It's mostly for security to make it more difficult to nuke connections
without knowing the sequence number.
Remember RFC is from a very different internet with much less DoS attacks.
Andi, one
Andi Kleen writes:
BSD and Solaris both make these kinds of packets, therefore it is must
to handle them properly. So we will fix Linux, there is no argument.
How do you propose to handle them? Queue the data anyways or just process
the ACK?
tcp_sequence returns two flag bits
On Thu, Jan 25, 2001 at 03:44:07AM -0800, David S. Miller wrote:
Andi Kleen writes:
BSD and Solaris both make these kinds of packets, therefore it is must
to handle them properly. So we will fix Linux, there is no argument.
How do you propose to handle them? Queue the data
Hello!
I take my words back. Manfred is right, this requirement is not a MUST.
Real problem is much worse, and it is wholly on the shame of solaris.
Tcpdump shows at least two different bugs there.
2060 16:31:42.879337 eth0 dynamic.ih.lucent.com.39406 static.8664: . 675
80:67580(0) ack
Hello!
> must be). Is there another RFC?
It is exactly this place.
As soon as BSD uses this feature, it is must for us.
> Could you check what happened in line 2066 of this tcpdump?
> 2066 16:31:43.108759 eth0 > static.8664 > dynamic.ih.lucent.com.39406:
> . 1583720:1583720(0) ack
On Wed, Jan 24, 2001 at 11:03:34PM +0300, [EMAIL PROTECTED] wrote:
> Hello!
>
> > I read through the tcpdump, and it seems that Linux completely ignores
> > packets with out-of-window sequence numbers:
>
> Yes, Linux is __very__ not right doing this. RFC requires to accept
> ACK, URG and RST on
> Yes, Linux is __very__ not right doing this. RFC requires to accept
> ACK, URG and RST on any segment adjacent to window, even if window
> is zero.
>
Interesting: I checked the RFC 793 and came to the conclusion that Linux
is correct. ("special allowance should be made to accept valid ACKs"
Hello!
> I read through the tcpdump, and it seems that Linux completely ignores
> packets with out-of-window sequence numbers:
Yes, Linux is __very__ not right doing this. RFC requires to accept
ACK, URG and RST on any segment adjacent to window, even if window
is zero.
Solaris also does
Hello!
I read through the tcpdump, and it seems that Linux completely ignores
packets with out-of-window sequence numbers:
Yes, Linux is __very__ not right doing this. RFC requires to accept
ACK, URG and RST on any segment adjacent to window, even if window
is zero.
Solaris also does thing,
Yes, Linux is __very__ not right doing this. RFC requires to accept
ACK, URG and RST on any segment adjacent to window, even if window
is zero.
Interesting: I checked the RFC 793 and came to the conclusion that Linux
is correct. ("special allowance should be made to accept valid ACKs" not
On Wed, Jan 24, 2001 at 11:03:34PM +0300, [EMAIL PROTECTED] wrote:
Hello!
I read through the tcpdump, and it seems that Linux completely ignores
packets with out-of-window sequence numbers:
Yes, Linux is __very__ not right doing this. RFC requires to accept
ACK, URG and RST on any
Hello!
must be). Is there another RFC?
It is exactly this place.
As soon as BSD uses this feature, it is must for us.
Could you check what happened in line 2066 of this tcpdump?
2066 16:31:43.108759 eth0 static.8664 dynamic.ih.lucent.com.39406:
. 1583720:1583720(0) ack 69041 win
I checked RFC793, and AFAICS Solaris is the culprit:
it sends out invalid packets, Linux ignores them and thus Linux doesn't
receive acks.
Which Solaris version do you use?
* The last valid ack from the Solaris computer is for byte 1583721, win
8760 (line 2078)
* No packet after line 2078 from
I read through the tcpdump, and it seems that Linux completely ignores
packets with out-of-window sequence numbers:
* the solaris computers (dynamic...) sends further data although the
Linux box (static) says 'win 0'.
See lines 2067, 2069, 2076, ...
2066 16:31:43.108759 eth0 > static.8664 >
I'm sorry I didn't give you a more specific version number: the "X" in the
2.2.18preX kernel version we tried is 17.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Ville Herva <[EMAIL PROTECTED]> suggested I post this bug report here and that
possibly David Miller or Alexey Kuznetsov could help out. I found the
problem back at the end of October and narrowed it down as much as I could
but didn't know where to report it until now. For complete details
I'm sorry I didn't give you a more specific version number: the "X" in the
2.2.18preX kernel version we tried is 17.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Ville Herva [EMAIL PROTECTED] suggested I post this bug report here and that
possibly David Miller or Alexey Kuznetsov could help out. I found the
problem back at the end of October and narrowed it down as much as I could
but didn't know where to report it until now. For complete details please
I read through the tcpdump, and it seems that Linux completely ignores
packets with out-of-window sequence numbers:
* the solaris computers (dynamic...) sends further data although the
Linux box (static) says 'win 0'.
See lines 2067, 2069, 2076, ...
2066 16:31:43.108759 eth0 static.8664
I checked RFC793, and AFAICS Solaris is the culprit:
it sends out invalid packets, Linux ignores them and thus Linux doesn't
receive acks.
Which Solaris version do you use?
* The last valid ack from the Solaris computer is for byte 1583721, win
8760 (line 2078)
* No packet after line 2078 from
42 matches
Mail list logo
