Re: Synflood filtering and Conntrack

[Mart Frauenlob <mart.frauenlob@chello.at>]

> 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