Re: kernel helper modules parameters

[Mr Dash Four <mr.dash.four@googlemail.com>]

> Is this wording compatible enough with non-developers? :)
>   
Well, actually, I *am* a developer! As I already pointed out, it is just 
that I am not that knowledgeable of the inner workings of netfilter (yet!).

> +	    { NULL, ENOENT, "An object was not found. Check that the chain, "
>   
"Object not found" perhaps?

> +	                    "target/match extension, and/or per-extension "
> +	                    "named object exists. Look at `dmesg` for "
> +	                    "reports about the latter." },
>   
In some circumstances (well, at least in my case anyway) the same 
message is also shown in the syslog, so you might want to add this as 
well - just in case you have somebody screaming in your ear why that 
wasn't included/provisioned or why is it that they "can't see anything 
in dmesg".

> With CT, this now looks moot to me like it does to you, since packets 
> can now be assigned via the awesome iptables logic, and the 
> nf_conntrack_tuple inside struct nf_conntrack_helper basically goes 
> unused.
>   
Yep, I agree - force-inclusion of the protocol seems unnecessary, 
particularly when you take into account that in the future there could 
be more helpers implementing variety of protocols (not just tcp/udp) 
and, as it stands, I have to create a separate statement for each - 
doesn't really make sense when ipset can handle this quite easily.

> Let's hear what Pablo (cc'd) has to say.
>   
I am all ears!

> 1. Using the "FORWARD" chain in filter as well as specifying "RELATED" 
> and helper name matches;
> 2. Using the PREROUTING/OUTPUT chain in raw by specifying the CT 
> target with a helper name match (this is what I used in my examples up 
> to now).
>
> Are the two methods above interchangeable (i.e. use one or the other, 
> but not both) or should I configure both (in which case I haven't 
> tried my ipset trick using the first scenario!)? In that file there is 
> no indication whether I should use one or the other (or both!).
>
> If I have to use the first method above as well, why is the "FORWARD" 
> chain used (at least in the examples given in that article)? If I want 
> to set up a helper on outgoing packets then using the OUTPUT chain in 
> filter seems to be the best solution.
>
> I also take it either of the above methods is the preferred option 
> instead of using modprobe (and force the loading of that helper 
> module). Am I correct in thinking that?
Any opinion on this?