Messages in this thread | | | Date | Sat, 6 Mar 1999 17:01:21 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: select()/socket has problems under 2.2.x. |
| |
On Sat, 6 Mar 1999, Alan Cox wrote:
>> >> 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... > >If you allow one frame of extra data to be queued, thats out by 64K, because >I can send 64K frames. In fact this is the classic "kill SunOS 4" attack >- SYN bombing with a syn attached to 64K of data.
I only changed the TCP_ESTABLISHED behavior. So I think you can only alloc a skb of one mss per established connection.
>> >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. > >Ok then you have more than one deadlock. TCP performs best with 3 or more frames
I have the deadlock that the min-trusize of a skbuff is just > rcvbuf.
>in the window size. So you reduce the MSS to windowsize/3 if need be.
Ok.
>> Should the receiver offer a so high window and mss even if the rcvbuf is 1008? > >No
Fun ;).
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/
| |