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 16:31:42.
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 inte
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 wor
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 ar
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 y
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 th
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 bit
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 ha
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 sp
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
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" not
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,
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 > dyn
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 pleas
21 matches
Mail list logo
