Harald Welte wrote:
> the patch removes the whole old ip_conntrack_netlink.c file and replaces
> it with a new one.  I don't really see why.  An, now, you changed the
> directory name from 2.6.11 to 2.6.12.  Is this neccessarry?  Why would
> your recent changes to ctnetlink not work with a 2.6.11 kernel?

I did that because of the file linux-2.6.patch, the 2.6.11 version 
differs from the new 2.6.12 one. Can we have in pom-ng two different 
file patches for every version? I mean, something like 
linux-2.6.11.patch and linux-2.6.12.patch living in ctnetlink. If so, 
please add the patch attached to ctnetlink.

>>I've split this big patch above into four pieces to make it easier to 
>>understand the changes:
>>http://people.netfilter.org/~pablo/ctnetlink-2.6.12/2.6.11-vs-2.6.12/
> 
> please remove stuff like
> 
>>-#if 0
>>+#if 1
>> #define DEBUGP printk
> 
> before releasing a patch, thanks.

OK, I'll do so.

> Also, I would rather not like to have NFNL_SUBSYS_CTNETLINK_EXP deleted.
> I thought it would be nice to have expect handling separated from
> conntracks, since they really are two seperate data structures.
> 
> Apart from that I'm fine with all of your modifications.
> 
> I don't understand why the order of the expectation list was changed,
> though.  Would you please explain why this was done?

Because of the table dumping logic I was using.

-                       if (ct->id <= *id)
+                       if (ct->id >= *id)
                                 continue;

I needed to add the conntracks at the tail. This isn't really needed so 
I've just reverted this change in the linux-2.6.12.patch attached.

Please see that you have to apply the patch 05ctnetlink.patch to 
ctnetlink as well.

>>- Implement ip_conntrack_stats dumping and reset (accounting)
> 
> you want to dump the statistics via netlink?  i'm not sure whether that
> is required.  lnstat is the only program using those counters, and using
> /proc seems fine for that.

Could this be useful for accounting purposes? I mean, dump and reset as 
a single operation, something similar to conntrack -L -z, say conntrack 
-S -z.

>>- Implement get conntrack and destroy (accounting)
> 
> sorry, what are you referring to?

An atomical operation to dump conntrack information and then destroy it. 
For example, if someone does:

conntrack -D --orig-src 1.1.1.1 --orig-dst 2.2.2.2 -p tcp 
--orig-src-port 10 --orig-dst-port 20

the it sends the conntrack info and destroy it. This could be worth it 
for accounting.

>>- Kill event/dump mask based (?). Although it's unique, I think that it 
>>could be useful for weak conntrack event notification (think of just 
>>new, established and destroy event notification to reduce performance 
>>impact).
> 
> 
> well, an interesting optimization.  My major problem with this whole
> system (like the other IPCTNL_MSG_CONFIG stuff) is: how to correctly
> deal with multipel users.  

Yes, this is a problem.

> Now, I think there is a way to do it right.  Basically every application
> would only request the events that it is interested in, and the kernel
> would bitwise-or those events to create the event mask that actually is
> to be dumped into userspace.
> 
> It's a bit like multicast membership subscription with IGMP...
> 
> So the only question remaining is: how does the kernel clean up / expire
> the masks?  If apps only subscribe but never unsubscribe, we would never
> clean up.
> 
> I'm not sure if we could somehow (cleanly) tie into the scoket
> close/destroy code.  If yes, we could check if we can reduce the mask at
> socket destroy time.

I think there's no sane way to do this but let me check the netlink code 
again. I could use multicast netlink subscrition, so the client can get 
subscribed to those events that the user considers interesting.

Initially the purpose of the mask based event notification was reducing 
the impact of an socket overrun under big stress situations. Say you've 
got a firewall very loaded, so conntrack-netlink subsys has to send tons 
of update messages, in that case the buffer can overrun and some 
messages will be drop.

To avoid this I could use an approach similar to what you do in ULOG and 
just keep the mask in userspace. Anyway, this hurts performance as well, 
since unneeded messages will be delivered to userspace and dropped if 
the client doesn't consider them interesting. This solution isn't that 
bad though since the conntrack-netlink subsys will send burst of 
messages in once.

--
Pablo