Rainer Sabelka wrote:
> I tried to debug this a bit and added some printk()s in the 
> ctnetlink_create_conntrack() function to find out where the ENOMEM is coming 
> from:
> So, now I see that nf_conntrack_alloc() is not returning this error, but it is 
> coming from a couple of lines below in the same function:
> 
>         helper = nf_ct_helper_find_get(rtuple);
>         if (helper) {
>                 help = nf_ct_helper_ext_add(ct, GFP_KERNEL);
>                 if (help == NULL) {
>                         nf_ct_helper_put(helper);
>                         err = -ENOMEM;
>                         goto err;
>                 }
> 
> There, nf_ct_helper_ext_add() returns NULL, which causes ENOMEM to be 
> returned.
> 
> I didn't debug this further because I'm rather lost in the code. But maybe 
> this gives you some hint what's wrong.

I just noticed a bug that may be the reason for EINVAL while injecting
connections that have a helper. The messages that contained connections
with helpers were malformed (one attribute was missing). Attached a
patch to fix this problem in libnetfilter_conntrack (already applied to
git, so probably it is better if you check out a working copy). With
regards to ENOMEM, probably we're hitting it because of some malformed
message.

The other patch is not directly related but it reduces the size of the
messages that are sent to kernel space to check for the existence of a
conntrack.

I have put a lot effort on the synchronization protocols in this release
but it seems that the commit still need one spin. As always, any help
testing and reporting problems is appreciated.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers