On 13/04/2011 10:10, Maciej Åenczykowski wrote:
> I should probably point out that iptables module autoloading behaviour
> is very different for a pre-my commit statically compiled, non-shared
> iptables binary
> vs a post-my commit or non-statically compiled binary.
Aha. I am using a static (well, --static --shared) iptables
> The modprobe issue would only show up if you had a statically
> compiled, non-shared iptables binary.
> ie. one where all the extensions were already part of the iptables
> binary and would always get initialized at startup (even for iptables
> -h).
Thanks - although my evidence suggests its simply the statically
compiled bit which is enough to trigger this? My binary is both static
and shared (is that the correct term?)
> The fix would probably be in xtables.c in compatible_revision() to
> change everything starting with:
> xtables_load_ko(xtables_modprobe_program, true);
> into a for loop:
>
> something along the lines of
>
> for (int load = 0; load <= 1; ++load) {
> if (load) xtables_load_ko(...);
>
> ...
>
> and replace "close(sockfd); return 0;" with "if (load) {
> close(sockfd); return 0; }; continue;"
>
> I'll try to write up and maybe even test a real patch tomorrow.
Thanks - although I'm not quite sure that I see that this changes
anything? There is already a "static int load;" in, I think it's
xtables_load_ko (?) which prevents the module loading more than once per
call of iptables - I'm not sure I understand how your loop above changes
that?
Additionally, as helpfully pointed out by Jan, a chunk of my problem is
my static iptables apparently trying to probe a kernel module which
isn't incorporated into my kernel version. I can't immediately see a
solution to not uselessly probing for that (without patching iptables)?
Any ideas?
Thanks
Ed W
--
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
