On Thu, 29 Jul 2010, Jan Engelhardt wrote:
They are not destroyed on DROP, and you can easily check that.
YOU could have easily check that - arrogant brick!!!
2 minutes it is.
[...]
Think. -m conntrack --ctstate NEW would not work if the ct only sprung into existence once it is confirmed.
Think yourself. [...]
Oh we'll all die of earlier arthritis now...
arrogant bs [...]
But the ct entry must undoubtly exist to be able to match -m conntrack --ctstate NEW.
>> Perhaps it's just that conntrack(8) won't show it? Now it's the others... of course. > On Thu, 29 Jul 2010, Jozsef Kadlecsik wrote:
I don't see why it looks soo complicated: of course, a ct entry is created by conntrack whenever a new connection is detected. And of course the entry is destroyed if the packet, which triggered to create the new entry, is dropped by a rule. Why should the conntrack entry be kept, if the connection is not allowed by the rules? The new ct entries are kept in the unconfirmed list and only added to the conntrack hash iff the entry will be confirmed, that is the entry-creating packet won't be dropped by a rule.
roflmao Jan: shame, shame, shame - shame on you! Thanks Pascal, Josef -- 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
