I'm trying to install a third-party VPN client on a Linux system and I'm having a problem. Hopefully one of you kernel gurus out there can help me figure it out.

There's a kernel module integral to the system, but when I try to insert it, I get the error "unresolved symbol nf_register_hook". The obvious response to this is "Build Packet Filtering into your kernel, you ninny," but I have. The system.map claims that it's in there, but don't know any way to actually verify it. I did change the version string just to make sure I was booting the right kernel, and I was. In building the kernel, I made clean, dep, clean, bzImage, modules, and modules_install and then put .../arch/i386/boot/bzImage in the right place. I don't see what I'm doing wrong. Maybe I need some kernel option turned on other than just CONFIG_NETFILTER.

This is on a Gentoo 2.4.26.

grep nf_register_hook /proc/ksyms

c0324760 nf_register_hook_R__ver_nf_register_hook

It's there.

I take it you have a vendor binary kernel module for the vpn ? Matching pre-compiled modules against kernels is nearly impossible in Linux.

Cheers

It's part source, part binary. The nf_register_hook thing appears to exist solely in the source part.

Well, the mucky bit is in how "modules" is configured in the kernel, then.

It SHOULD be as follows in /usr/src/linux*/.config

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

That's the way it is.

>That's the way it is.

Then you are probably not running a kernel that was built with those config options. If modversions is really on, the entry from /proc/ksyms should have a crc code appended to it, as in this one from my system running 2.4.27:

c01d9e80 nf_register_hook_R41316edc

I built it myself from that config last night. Let me doublecheck.

Nope. Definitely set that way.

I'll point out that CONFIG_NETFILTER is not a module, nor, according to menuconfig, can it be.

I'm gonna try to enable some of the netfilter-related config stuff and see if that helps. (Taking shots in the dark now.)

Interestingly, I cannot insmod netfilter-related modules. They give me similar unresolved symbol problems. Was there a bug in 2.4.26 or anything?

Maybe I should just redo my whole kernel config and see if I can figure out what's wrong. This is the first time I've ever had any significant kernel trouble in ten years of using Linux.

You'll be better off by just rebuilding the kernel again.

Do this:

cp .config /tmp/dot_config
make mrproper
cp /tmp/dot_config .config

## edit Makefile by hand and change the EXTRAVERSION line
## at the top to something unique for this build.

make oldconfig
make dep clean bzImage modules modules_install

And install the kernel ("make install" ?) whatever way you normally do.
After reboot, do "uname -r" and verify that the EXTRAVERSION tag is present.

Cheers

That did it. Strange. I wonder what was left over by "make clean" that "make mrproper" fixed.

Thanks a bunch, Mark.

Lots of stuff doesn't get redone correctly if the .config is modified without first doing a "make mrproper" (that's "Mr. Clean" outside of Finland). The kernel make system has never really worked correctly until the 2.6.xx stream.

Cheers

Well, it's the first time a "make clean" hasn't done enough for me, I think. I'll keep it in mind, though.

Although I have to move to 2.6 for my 802.11g driver.

Thanks again.

Okay, time to rub my Magic Genie^H^H^H^H^H^H Lord Lamp again.

I was going to write out the problem I was having, but this small thread elsewhere, the second post, at least, sums things up pretty well. Any ideas?

yea.. I hate that.. I always have issues with redhat's kernel source not being clean enough for some stuff... I always forget to make mrproper to get it all ready for myrinet driver compiling and stuff like that.

MMmm... binary kernel module, eh? If you don't have source code, then the *only* way it will work is on the *exact* kernel that they used when building the module.

Cheers

It worked with a variety of 2.4 kernels and claims to support 2.2, 2.4, and 2.6. It's not binary-only; it's part binary, part source.

Can maybe you clue me in on the "Could not allocate 116 bytes from system (currently using 0 bytes)" part? Seems like allocating 116 bytes shouldn't be so hard.

More likely that whatever kernel call it is using has suffered a parameter change inside the (open-source) kernel. Like expecting a 64-bit value instead of a 32-bit value, or added/removed an extra parameter or some such thing. TONS of that kind of stuff happening almost daily in the 2.6 stream.

Cheers

Okay. Thanks.