Yes - if you don't process the other fields you will deadlock
> >> 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.
> >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
in the window size. So you reduce the MSS to windowsize/3 if need be.
> Should the receiver offer a so high window and mss even if the rcvbuf is 1008?
No
-
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/