Re: [PATCH] ct-event API port to 2.6.11

[Amin Azez <azez@ufomechanic.net>]

For the record I forgot to say:
add Pablos patches from the post I was replying to (see 
http://lists.netfilter.org/pipermail/netfilter-devel/2005-April/019182.html
)
to the unpacked libctnetlink and libnfnetlink before you compile them.

What is ctnltest supposed to do?

Running ctnltest I only ever get one packet where the subsys id is 
NFNL_SUBSYS_CTNETLINK_EXP

I can bring connections up and down all day and ctnltest doesn't receive 
any more packets.

I'm so close now to completing this path through the jungle, when I'm 
done I shall walk up and down it to make the path wider and explore the 
side roads.

I was hoping that ctnltest would start spitting out reports when 
connections came up and down.

I'm currently investigating how libctnetlink goes through libnfnetlink 
and touches ct-event to see if it even should do what I think, but any 
tips anyone has will be appreciated.

Sam



Pablo Neira wrote:
> Amin Azez wrote:
> 
>> Thanks for the patches Pablo, they seemed to do the trick.
>> ctnl_del_conntrack has been expanded to 3 args, should I be using 
>> CTA_UNSPEC or CTA_ORIG or CTA_STATUS as the 3rd arg on line 118 of 
>> ctnltest.c?
> 
> 
> +int ctnl_del_conntrack(struct ctnl_handle *cth,
> +                      struct ip_conntrack_tuple *tuple,
> +                      enum ctattr_type_t t)
> 
> The 3rd arguments says if you're referring to CTA_ORIG or CTA_RPLY. So 
> you can kill conntracks based on the direction.

Hmmm... in the context of ctnltest.c its hard to say what is required.
I'm not even sure why ctnltest is calling ctnl_del_conntrack for packets 
where (NFNL_SUBSYS_ID(nlh->nlmsg_type) == 
           NFNL_SUBSYS_CTNETLINK)

> fix ctnl_del_conntrack, CTA_UNSPEC isn't ok as 3rd param.

will do: really dumb question, why is ctnltest even calling 
ctnl_del_contrack?

Amin