>> >> 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/