On Thursday 2010-06-03 00:13, Jozsef Kadlecsik wrote: >On Wed, 2 Jun 2010, Curby wrote: > >> This seems to get a bit murkier as some conditions that match INVALID, >> including invalid combinations of TCP flags, seem to be an "active >> match" instead of a "passive default." In other words, if the state >> starts as INVALID, and conntrack determines that it should be state >> NEW, something somehow must be applied afterwards to force it back to >> INVALID due to it being a malformed packet. > >It depends on how one looks at conntrack and it's relation with the other >parts of netfilter. I'd not say that "every packet starts with the state >INVALID". Well yes, I had already considered skb_copy in my back-head, but I put it off as a developer thing, because if you have not looked into code, you don't really know whether ipt_REJECT copies the packet and resets/truncates it or creates a new one from scratch, then copies. (Answer: in the timeline of Linux, both ways have been tried already.) >Of course the state of the packet *before* conntrack invoked is >INVALID, but what else could it be, if conntrack hadn't got a chance yet >to associate a state to the packet? In case of skb_copy, that would be oldskb->nfct* :-) >The current documentations try to describe the states so that it does not >need a deep TCP/IP knowledge from the readers. A rough description on how >a packet traverses conntrack and what state are associated to it could be >the following: > >- loopback or untracked packets are ignored And by loopback, Jozsef does not mean "lo" device transmissions, but skb->nfct != NULL (happens when passing twice through nf_conntrack, such as with xfrm). -- 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
