> Thanks a lot for pointing ip_conntrack_core.c and explain all this ! Agreed. Thanks, Henrik.
> The problem is that the definition of the HOWTO states that NEW match: > > A packet which creates a new connection. > > That's not true if you consider this from the protocol point of view I think you are correct here; there's an ambiguity here, and I'd wish connection tracking would be called flow tracking or something. However, it's too late for that, now. Realistically, I think that the docs would be best augmented by an extra chapter on "why does the man-in-the-middle say connection to different things than the protocols". Bad title, I know, but instead of explaining the difference partially and clumsily everywhere it matters, a lucid extra part of the docs would be preferrable (and then reference that where it matters). > > Of these, only ASSURED is directly dependent on the TCP connection > > tracking state, the others are only dependent on the ability of > > identifying which connection the packet may belong to. > > Actually, ASSURED seems to be related to all the protocols which > expect a confirmation from the receiver before establishing the > connection (but in your case only TCP need a confirmation. UDP and > ICMP does not need this). Right ? Right, I think. If another protocol parallel to TCP comes along which has such a setup phase (SCTP comes to mind), it could be handled likewise. Also, I could imagine special TCP conntrack helpers to go even further, and defer the ASSURED marking to a point where more of the connection is known, e.g. real data has been seen in one direction, and correctly acked. best regards Patrick
