On Wednesday 2010-06-02 22:48, 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. How does that "something" >fit in with this chain of events, and what does it check for? The 'error' check function (bad length, flags, zz.) runs before creating a ct entry. >The first is determined in the context of the conntrack system, and >takes into consideration conntrack's knowledge of the state of the >network and the connections therein. The second treats packets in a >vacuum and evaluates parts of the packet against other parts to >determine its consistency. conntrack has no knowledge of the network layout, topology, speed, or any other condition, other than perhaps the recently-added user-settable zone identifier. >It's likely that my confusion stems from a still-incomplete knowledge >of how packets traverse the different parts of netfilter and xtables. Start by reading http://en.wikipedia.org/wiki/Netfilter and /iptables, perhaps. Their current version is clean and approved by me :p -- 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
