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?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
