On Wed, 20 May 2009, Philip Craig wrote: > Jozsef Kadlecsik wrote: > > You mean, when the ack flag is not set in the packet, we handle it as it > > was set and had a proper ack field? What else could be done? :-) > > No, I mean when there the ack flag is set, but there is no data, > as handled by this code: > > if (seq == end > && (!tcph->rst > || (seq == 0 && state->state == TCP_CONNTRACK_SYN_SENT))) > /* > * Packets contains no data: we assume it is valid > * and check the ack value only. > * However RST segments are always validated by their > * SEQ number, except when seq == 0 (reset sent answering > * SYN. > */ > seq = end = sender->td_end; > > We've encountered this in practice where a 'tcp accelerator' was > creating a new tcp connection with all the same port numbers, but > a different sequence number, and the tcp conntrack was accepting > a pure ack packet as part of the old connection, even though the > sequence number was wrong. This setup won't work no matter what > tcp conntrack does of course, but it did complicate working out > what was going on. I see. The rationale behind not checking the sequence number in this case is that there's no data in the packet. If the packet is out of the window of the receiver, it'll answer with an ack with the proper seq, ack values. But it can be argued that conntrack should still check the sequence number of dataless packets too :-). Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
