On Tue, 2009-02-03 at 11:03 -0800, Shorewall Guy wrote: > > It depends. > > The Linux kernel can be built either with or without module autoloading.
Hrm. That's CONFIG_KMOD, yes? > The 'modprobe' utility only works if module autoloading is enabled. In > most cases, when autoloading is enabled, needed modules are loaded on > demand without an explicit 'modprobe' command. The exception is that > netfilter nat and conntrack helper modules are not autoloaded; they > require an explicit 'modprobe' command. Yeah. This is OpenWRT so it looks like autoloading is disabled: # CONFIG_KMOD is not set I wonder what the motiviation for this is, beyond the obvious of the smaller the better. > When autoloading is not enabled, modules must be excplcitly loaded using > the 'insmod' command. Yeah, it seems a lot of modules packages in OpenWRT come with a file that goes in /etc/modules.d that loads it's modules. > Using insmod, the file name of the module must be > specified and all dependencies for the module must be already loaded. Indeed. > Shorewall supports either model. By default, it tries to modprobe/insmod > everything it could possibly need by processing the > /usr/share/shorewall/modules file. Yeah. That's what I have been trying to figure out/work with given that I was not getting modules autoloaded. I have not see where in "shorewall reload" (on a shorewall-lite machine) this is actually happening. The modules are stored in the "<state_dir>/.modules" but I don't see any effort to try to load them. xtrace from the restore script shows all of the execution prior to the test for the state module as being: + LEFTSHIFT=<< + [ 1 -gt 1 ] + initialize + SHAREDIR=/usr/share/shorewall-lite + CONFDIR=/etc/shorewall-lite + PRODUCT=Shorewall Lite + [ -f /etc/shorewall-lite/vardir ] + . /etc/shorewall-lite/vardir + VARDIR=/etc/shorewall-lite/state + CONFIG_PATH=/etc/shorewall-lite:/usr/share/shorewall-lite + [ -n /etc/shorewall-lite/state ] + TEMPFILE= + DISABLE_IPV6= + uname -r + MODULESDIR=/lib/modules/2.6.25.20 + MODULE_SUFFIX= + LOGFORMAT=Shorewall:%s:%s: + SUBSYSLOCK= + LOCKFILE= + LOGLIMIT= + LOGTAGONLY= + LOGRULENUMBERS= + [ -n restart ] + [ -n -1 ] + [ -n restore ] + [ -n Shorewall:%s:%s: ] + VERSION=4.0.12 + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin + TERMINATOR=fatal_error + DONT_LOAD= + [ -z /usr/sbin/iptables ] + [ -n /usr/sbin/iptables -a -x /usr/sbin/iptables ] + IPTABLES_RESTORE=/usr/sbin/iptables-restore + [ -x /usr/sbin/iptables-restore ] + STOPPING= + [ -d /etc/shorewall-lite/state ] + qt1 /usr/sbin/iptables -N foox1234 + local status + [ 1 ] + /usr/sbin/iptables -N foox1234 + status=0 + [ 0 -ne 4 ] + return 0 + qt1 /usr/sbin/iptables -A foox1234 -m state --state ESTABLISHED,RELATED -j ACCEPT Perhaps the modules loading is supposed to happen before the call to the restore script? I'm using shorewall-lite 4.0.8 on the router and 4.0.12 on the control station. Thots? b.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
