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.
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).
Basically the problem is when we're doing revision compatibility
testing as part of an extensions init sequence we will modprobe from
userspace.
I believe we always attempt a module load there instead of first
checking for api existence, and modprobing if the API is missing.
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.
- Maciej
--
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
