Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 6 Mar 1999 16:18:14 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: select()/socket has problems under 2.2.x. |
| |
On Sat, 6 Mar 1999, Alan Cox wrote:
>On a ful receive queue you must still always process the ack and window >information then throw the frame. Its as simple as that. > > State > Ack > Window > if it fits > Data > Fin > end
Ah, this is the reason we don't reject the packets before entering in tcp_input.c. Very well, OK, at least that now make sense to me.
>> I really can't see how this can open a window for a DoS attack. Really >> please can you write an exploit for it? Overrunning the rcvbuf if the >> queue is empty it's exactly what I wanted to achieve. > >By 64K ?
I don't understand this...
>> What if I'll change the MTU during a transer? I just thought at the way >> you are proposing and it simply doesn't look like the right way to fix the >> bug to me. > >If your MTU is < 3 * the max window you propose to offer you should set the >MSS lower in the tcp connection options (TCP MSS blah). This also makes tcp >work better as well as solving your deadlock.
You mean that we should decrease the mss if our rcvbuf is low? The deadlock happens also with 3 byte of data in the packet so I don't think it's enough.
I am looking now at the tcp trace of the deadlock. Now I have my patch applyed so it doesn't deadlock anymore. See it:
16:09:06.947418 localhost.1048 > localhost.telnet: S 2378452431:2378452431(0) win 31072 <mss 3884,sackOK,timestamp 567981 0,nop,wscale 0> (DF) ^^^^^ ^^^^ 16:09:06.947478 localhost.telnet > localhost.1048: S 2374855488:2374855488(0) ack 2378452432 win 31072 <mss 3884,sackOK,timestamp 567981 567981,nop,wscale 0> (DF) 16:09:06.947509 localhost.1048 > localhost.telnet: . ack 1 win 31072 <nop,nop,timestamp 567981 567981> (DF) ^^^^^ 16:09:06.993209 localhost.telnet > localhost.1048: P 1:4(3) ack 1 win 31072 <nop,nop,timestamp 567985 567981> (DF) 16:09:07.005029 localhost.1048 > localhost.telnet: . ack 4 win 31069 <nop,nop,timestamp 567987 567985> (DF)
Should the receiver offer a so high window and mss even if the rcvbuf is 1008?
Comments?
Andrea Arcangeli
- 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/
| ![\](/images/icornerr.gif) |