Hi,
On Tue February 10 2009, Jan Engelhardt wrote:
> It [Xtables kernel code] will not use l3proto_generic, because
>
> if (nf_ct_l3proto_try_module_get(par->match->family) < 0) {
> printk(KERN_WARNING "can't load conntrack support for "
> "proto=%u\n", par->match->family);
> return false;
> }
>
> already catches the "mistake" (of having forgotten to build the
> _ipv4/_ipv6 module), and returns EINVAL to userspace.
Ups, didn't knew about that. Thanks... :-)
>
> In other words: always look into dmesg for messages!
>
>
> Only nf_conntrack will use l3proto_generic, but nf_conntrack is
> independent of Xtables ;-)
I'm asking me, why does xt_state needs an l3 handler different from generic?
(the call to nf_ct_l3proto_try_module_get ensures this)
Why not trying to handle l3 and l4 in a generic way, if there is no other
module compiled into the kernel, and so being able to access the state via
xt_state.
In any case, in my opinion, the generic l3 handler doesn't serves anything,
because it will return -NF_ACCEPT at the call to get_l4proto. Why not
associate the l4 generic handler to the l3-one? That way, the tracking for
unknown protocols (or not compiled into the kernel) can continue.
Christoph
P.S.: Jan, did you took a look at the code I sended to you? It's no problem,
if you didn't had the time...
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
