Help compiling modules on ReadyOS 6.4.2 (required to route eth1 over tun1)

[TonyKL]

Hi all,

I'm wanted to route traffice from eth1 over a VPN connection via openvpn.

I've installed and configured openvpn and all is good however I believe I need support for netfilter in iptables to set this route up?

I've downloaded the sources for 6.4.2 and configured the kernel from the readynas config to enable the modules and rebuilt everything.  However I'm unable to load the modules once they have been installed.

Modinfo appears to report the same information for the new modules compared to the existing shipped modules but I don't know why they wont load.  I usually get 'invalud argument' when attempting to load.

Anybody correctly built modules on the readynas?

[WhoCares_]

I ran into the same problem. Since 6.4.1 or 6.4.2 I can no longer build kernel modules on my VMs but have to build them directly on the ReadyNAS to get working versions. Don't know if it's the same problem for I'm mostly builting modules external to the kernel tree but you should see some additional messages when running

dmesg

after trying to load the module(s) in question.

-Stefan

[TonyKL]

Thanks for the reply, I'm actually trying to do this on the ReadyNAS as I didn't know how to do it from a VM.

I will try again on 6.4.2 as the kernel is updated.  I get stuff like this in dmesg:

nf_conntrack: disagrees about version of symbol skb_copy_bits

nf_conntrack: Unknown symbol skb_copy_bits (err -22)

nf_conntrack: disagrees about version of symbol register_net_sysctl

nf_conntrack: Unknown symbol register_net_sysctl (err -22)

nf_conntrack: disagrees about version of symbol skb_make_writable

nf_conntrack: Unknown symbol skb_make_writable (err -22)

nf_conntrack: disagrees about version of symbol seq_open_net

nf_conntrack: Unknown symbol seq_open_net (err -22)

nf_conntrack: disagrees about version of symbol nf_afinfo

nf_conntrack: Unknown symbol nf_afinfo (err -22)

nf_conntrack: Unknown symbol nf_conntrack_destroy (err 0)

nf_conntrack: Unknown symbol nf_ct_destroy (err 0)

nf_conntrack: disagrees about version of symbol register_pernet_subsys

nf_conntrack: Unknown symbol register_pernet_subsys (err -22)

nf_conntrack: disagrees about version of symbol init_net

nf_conntrack: Unknown symbol init_net (err -22)

nf_conntrack: disagrees about version of symbol seq_release_net

nf_conntrack: Unknown symbol seq_release_net (err -22)

nf_conntrack: disagrees about version of symbol unregister_pernet_subsys

nf_conntrack: Unknown symbol unregister_pernet_subsys (err -22)

nf_conntrack: disagrees about version of symbol nf_log_packet

nf_conntrack: Unknown symbol nf_log_packet (err -22)

nf_conntrack: disagrees about version of symbol inet_proto_csum_replace4

nf_conntrack: Unknown symbol inet_proto_csum_replace4 (err -22)

nf_conntrack: Unknown symbol ip_ct_attach (err 0)

nf_conntrack: disagrees about version of symbol unregister_net_sysctl_table

nf_conntrack: Unknown symbol unregister_net_sysctl_table (err -22)

[WhoCares_]

What's the actual command set you're running and is this an ARM or an Intel based ReadyNAS?

-Stefan

[TonyKL]

This is a ReadyNAS Ultra 4 so x86 architecture.

I've downloded the kernel sources and extracted them, copied the readynas config to .config then ran configure to enable netfilter (I'm after NAT routing for iptables).

after make, make modules, make modules_install i then have modules in /lib/modules/xxx

if I try to insmod the module it failes

[WhoCares_]

Try first running

make mrproper

then copy the ReadyNAS default config to .config and then run your commands again.

[WhoCares_]

Oh, and yes, the kernel sources will only work for the releases they're numbered with since NETGEAR updates the kernels quite often lately 😉

-Stefan

[TonyKL]

Right, so I download the sources (can no longer find them - do you have a location?), then extract.

I then run $make mrproper before anything else.

I'll give it a go, thanks!

[WhoCares_]

Sources are here: http://kb.netgear.com/app/answers/detail/a_id/2649/ (You'll need to scroll down quite a bit)

Anyway, I'm not sure you actually need the netfilter modules depending on what you're trying to do. But I may be mistaken there.

-Stefan

[TonyKL]

I've downloaded from here: 

http://www.downloads.netgear.com/files/GPL/ReadyNASOS_V6.4.2_WW_src.zip

I'm wanting to route all traffic on eth1 through a vpn tun1.  I believe I require NAT for iptables which is the missing module?

[WhoCares_]

If you only want to route the traffic through the tunnel on the tun1 interface then no, you don't need any netfilter modules. If, however, what you're trying to is to masquerade the traffic from eth1 using the tunnel IP of tun1 so that it looks like the traffic would come from your assigned tunnel IP without exposing the hosts on the network behind the eth1 interface then yes, you'd need the netfilter modules.

-Stefan

[TonyKL]

I'm giving the modules another compile, however if I don't need the modules then this would be easier/better following firmware updates.

So what I am trying to do is plug the network from my MacBook into the eth1 port of my ReadyNAS and access the internet via the VPN (tun1) created on the ReadyNAS using OpenVPN.

I did originally think I could route all traffic on the eth1 (192.168.x.x) network down the tunnel but I've failed everytime which is why I'm reaching for iptables as most solutions google turns up points that way.

I had MacBook (192.168.1.10) with router of (192.168.1.1) which is the ip of readynas eth1.

[WhoCares_]

In your case you'll need to use NAT and thus you'll need the netfilter modules. Actually, the packets from your Mac may have made it to the other side of the tunnel. But since the destionation system didn't have any idea of where to route packets for your (private) IP network to, your Mac never received an answer 😉

-Stefan

[TonyKL]

That makes perfect sense, it's been far too long since I've been this low down in the network stack, thanks for your help.

I'll try and update on my progress with compiling the 6.4.2 modules.

[TonyKL]

Unfortunately I still have the same issue, even if I run make mrproper first 😞

nf_conntrack: disagrees about version of symbol skb_copy_bits
nf_conntrack: Unknown symbol skb_copy_bits (err -22)
nf_conntrack: disagrees about version of symbol register_net_sysctl
nf_conntrack: Unknown symbol register_net_sysctl (err -22)

/lib/modules/4.1.16.x86_64.1/kernel/net/netfilter# modinfo nf_conntrack.ko 
filename:       nf_conntrack.ko
license:        GPL
depends:        
vermagic:       4.1.16.x86_64.1 SMP mod_unload modversions 
parm:           nf_conntrack_helper:Enable automatic conntrack helper assignment (default 1)
parm:           acct:Enable connection tracking flow accounting.

/lib/modules/4.1.16.x86_64.1/kernel/net/netfilter# insmod /lib/modules/4.1.16.x86_64.1/kernel/net/netfilter
/nf_conntrack.ko 
insmod: can't insert '/lib/modules/4.1.16.x86_64.1/kernel/net/netfilter/nf_conntrack.ko': Invalid argument

[WhoCares_]

I haven't tried to compile the netfilter modules so I'm just guessing here. But chances are that by enabling the netfilter stuff the kernel config routines also alter other things that influence the functions available for other modules compiled in the process. However, since you can't install the kernel you're building it's quite possible that the routines needed by the netfilter modules aren't present in the running kernel on the ReadyNAS.

A way to check would be to run diff against the original default config and the one generated by your edits. This should only list changes for the modules you enabled. If there's more chances are that netfilter configs somehow manipulate other settings.

-Stefan

[IcyK]

---

@TonyKL wrote:
[...]

/lib/modules/4.1.16.x86_64.1/kernel/net/netfilter# modinfo nf_conntrack.ko 
filename:       nf_conntrack.ko
license:        GPL
depends:        
vermagic:       4.1.16.x86_64.1 SMP mod_unload modversions 
parm:           nf_conntrack_helper:Enable automatic conntrack helper assignment (default 1)
parm:           acct:Enable connection tracking flow accounting.

[...]

I vaguely rememer you have to add ".RNx64_64.2.2" in some Makefile to get the correct vermagic (or something else starting with RNx64_, check an existing 'native' module.

From the dvb_core module I compiled for 6.3.5:

/lib/modules/3.12.43.RNx86_64.2.2/kernel/drivers/media/dvb-core # modinfo dvb-core.ko
filename:       dvb-core.ko
license:        GPL
author:         Marcus Metzler, Ralph Metzler, Holger Waechtler
description:    DVB Core Driver
depends:
vermagic:       3.12.43.RNx86_64.2.2 SMP mod_unload modversions
parm:           dvbdev_debug:Turn on/off device debugging (default:off).

[...]

[TonyKL]

Copying the readynas config I get vermagic of

/lib/modules/4.1.16.x86_64.1/kernel/net/ipv4/netfilter# modinfo iptable_na
t.ko 
filename:       iptable_nat.ko
license:        GPL
depends:        nf_nat_ipv4
vermagic:       4.1.16.x86_64.1 SMP mod_unload modversions 

which seems to match the existing netconsole module which I can load

[WhoCares_]

I really wonder where you get the 3.x kernel version from. This looks like either you used the wrong sources for compiling the dvb modules or the wrong kernel source tree. Most likely you did a compile of the dvb modules on an older kernel and the build process just remembered (by using symlinks) where the kernel sources used back then where located. So I think it's not a point where one should start the research. Did you run a diff of the kernel configs before and after making your changes as I suggested?

-Stefan

[TonyKL]

Did you run a diff of the kernel configs before and after making your changes as I suggested?

I have yet to do this, I get very little time to play with my NAS 😞

Also, please don't confuse the reply from IcyK informing of the vermagic check, my modules have the correct version

4.1.16.x86_64.1 

 thanks.

[IcyK]

---

@WhoCares_ wrote:

I really wonder where you get the 3.x kernel version from. This looks like either you used the wrong sources for compiling the dvb modules or the wrong kernel source tree. [...]

-Stefan

---

I highly doubt that, it came with the GPL sources of 6.3.5 (that I have running on some Ultra units). But that's off-topic. 😉

@TonyKL: sorry I can't be of further help...

[mdgm-ntgr]

6.3.5 used an older kernel, so that would explain it.