> OK this I agree with - I should have thought of it myself... but then
> another question - why not set ack_seq to rcv_nxt instead of taking it
> from the packet header?
It was mistake.
> Linux might do it though I haven't checked recently. Using seq+1 in such a
> case will only ack the first byte of the data in the packet. I don't
> understand where RST comes into it...
I apologize 8) This piece was copied-n-pasted from tcp_v4_send_reset
and I was confused by their similarity.
Yes, certainly, it was broken. Andi fixes or already fixed it.
> transmitted. Any stack that expects an ACK to an ACK is broken beyond
> repair.
Acking data is main, but not the only function of ACKs.
One example is keepalive function as recommended by RFC1122,
keepalive ping is ACK out of window by 1. Though it warns
in the same place, that some broken stacks do not ACK bare ACKs 8)8)8)
"Unfortunately, some misbehaved TCP implementations fail
to respond to a segment with SEG.SEQ = SND.NXT-1 unless
the segment contains data."
We do not want to be misbehaved. 8)8)8)
Alexey
-
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/