>> It may well be the case that it's the kernel which is running the code >> in xtables.c. > > No no no. Not unless you run a hack like Kernel Mode Linux, which I > doubt you do. Or do you? I have no idea what grsec put into their > stuff, or whether you have an authentic unpatched iptables program. > It does not look standard at all. Nope, normal 2.6.37 kernel with grsec patches. iptables 1.4.10 is compiled under gentoo and largely vanilla other than I have added the commit from Maciej and my own hack to delete modprobing I think grsec is relatively unexciting in this case - largely it's just a big "constifying" patch, plus some RBAC features. If you strip out the "constify" stuff (and chroot limitations), the remaining patch is reasonably small and sane. >> $ cat /tmp/modp.log >> ip_tables -q >> -q -- ipt_SET >> -q -- ipt_SET >> -q -- ipt_set >> -q -- ipt_set > > The trailing -q is a hint towards the call from iptables, whereas the > leading -q is kernel-invoked calls. Specifically, it seems that > xt_set is indeed not built-in, but a module. Hmm, that's an interesting point. So ipt_SET of course not build in to the kernel (2.6.37/38). Further I can't find any reference to it in a 2.6.38 kernel tree? I do however see something in the 2.6.39-rc3 tree (sanity check please - is this correct?) This would seem to explain why the kernel autoloader was having a try to find some missing module? It's actually completely missing on this kernel? However, I really don't understand the sequence of calls here that has caused apparently a "modprobe iptables" from xtables.c to trigger the kernel (?) to try and insert some module that it knows nothing about (only iptables seems to know about it)? Hmm, not sure how to progress this now? 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
