On 14/04/2011 08:13, Maciej Åenczykowski wrote: > Note that: -M '' is -M followed by a space and two single quotes. > > Furthermore, note that with -M '', you will want to modprobe ip_tables > or modprobe ip6_tables manually first at system startup (or build them > into the kernel), since those modules don't autoload (hence why > iptables tries to load them). > > I wonder if there's an easy way iptables userspace could detect > whether these modules are already loaded (or compiled into the > kernel), and not even try to load them, if so... > OK, using kernel 2.6.38 (previously on .37) iptables 1.4.10 patched with the delayed module loading commit, then I still get something like 20 attempts to "modprobe iptables -q" when I start up a near vanilla shorewall script (I just entered enough info that it boots up with a couple of basic zones). If I just do an iptables restore, or a near equivalent "shorewall restore" then I get just a single modprobe iptables -q. This suggests that the shorewall start tickles several iptables calls. Each call causing one modprobe Now this seems to be coming from the iptables.c modprobe call. Annoyingly this didn't seem to be happening when I used kernel 2.6.37. It's timeconsuming to reload kernel changes to this embedded device, but I will check back and confirm this is a change in behaviour between kernels. However, it seems unexpected that there are any calls from iptables since it does some kind of test before calling modprobe? I'm sure I didn't get any on .37??! Any insights on why I get even a single modprobe call given everything built in kernel and a static iptables binary? 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
