TUN/TAP problems with Kirkwood kernel

As requested by Bodhi on the kernel thread, I'm going to make a separate topic to unclutter that thread.

I recently setup a Seagate DockStar with the 3.16 rootfs and latest Uboot. Everything is working fine on it, but have run into a potential limit of the kernel (or my understanding of the process).

I have setup several "offsite sync" boxes in the past, using a Raspberry Pi and an external USB hard drive. I have them at a few different locations, with rsync jobs and btsync installs keeping my data in it's own kind of "cloud".

The dockstar is a perfect device to do this with since I am out of RPi at the moment. The problem is that I use the N2N project's mesh VPN network to keep all of my devices talking to each other.

http://www.ntop.org/products/n2n/

It's basically a peer-to-peer implementation of what OpenVPN does, creating TUN/TAP devices and linking them with encryption and ARP routing. The difference is that OpenVPN uses a server->client architecture, while N2N has a tracker and nodes (peer to peer).

Regardless, the N2N compile goes fine on the kirkwood, and the binaries run without a problem. I can see on the tracker (supernode) when the kirkwood box comes online, and I can use 'arping' to do ARP pings between the kirkwood device, and any other device on my mesh (and visa versa).

Where it all goes wrong is that is all I can do. I see the registration on the tracker, and I can 'arping', but I can pass no real traffic through the interface. ICMP pings fail, ssh fails, everything. ARP is the only traffic that seems to be able to communicate.

Last night I did a RPi fresh install and a fresh install on the kirkwood, and line for line did the same steps. The RPi joined the mesh and could ping and connect, while the kirkwood could not (only arp traffic).

The tun0 device is being made properly, shows packets sent and received (the ARP stuff i'm assuming), and everything looks identical to the RPi done in tandem. My only thought is that the kernel is missing something, or there is a package in a RPi install of Raspbian that i'm not thinking of that I should add to the Debian kirkwood installl to fix it.

Thoughts?

i dont use a RPi, however as a starter for 10 i would issue the following cli command and cross reference the output from each device.

dpkg -l

I presume that n2n has a list of depencies displayed somewhere on its website - both mandatory and recomended

Just my thoughts of approach if i was looking to troubleshoot

another thought comes to me - if the n2n package sets up a virtual interface, you may need to look that the option to allow the linux device to act as a router is enabled - i presume that it is on the RPI distributions as the last time is set one up as a wifi router, i didnt have to enable this myself

e.g.
edit the /etc/sysctl.conf to add the following

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1

Also to change options without rebooting you could:

echo 1 > /proc/sys/net/ipv4/ip_forward
for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done

without any info/configuration you won't get much help. Post everything you have and someone might help you.

No luck on adding those sysctl options, the N2N binaries set those when it is run. I compared /proc/sys/net/ipv4/conf/*, and each setting is the same.

I just did a wheezy install on a VM on my main desktop, and from the first boot I went through the same procedure. It worked fine.

So it works on a fresh Debian in VM, and a fresh Raspbian on RPi. The process I follow goes like this:

apt-get -q update
apt-get -y -q install build-essential libssl-dev subversion uml-utilities nano
cd ~
svn co https://svn.ntop.org/svn/ntop/trunk/n2n/n2n_v2
cd n2n_v2
make
make install
rm /etc/rc.local
cat <<EOT >> /etc/rc.local
#!/bin/sh -e
##
##-Uncomment this for a client node
##edge -d n2n0 -a static:10.2.3.XXX -c tufnet -k secret -l supernodeip:1201
exit 0
EOT
chmod +x /etc/rc.local
echo ***Edit /etc/rc.local to choose an IP and adjust password, then reboot.

This is a copy of my script. I modified it slightly for the kirkwood device so it wouldn't clear rc.local and lose the LED code examples.

As you can see its just a basic installation of the files needed to compile, then a svn get, a compile, and then I reboot. On the reboot, it joins into the mesh.

N2N is working, as I said before because I can see the MAC address registering on the supernode, and I can use several arp tools to send ARP pings and ARP traffic between the kirkwood device and any other node. No regular traffic, (including ICMP ping) will work though.

Example:

root@debian:/home/tufkal# arping 10.20.30.109
ARPING 10.20.30.109
42 bytes from 26:2a:bd:d5:fe:ec (10.20.30.109): index=0 time=3.409 msec
42 bytes from 26:2a:bd:d5:fe:ec (10.20.30.109): index=1 time=3.915 msec
42 bytes from 26:2a:bd:d5:fe:ec (10.20.30.109): index=2 time=5.128 msec
42 bytes from 26:2a:bd:d5:fe:ec (10.20.30.109): index=3 time=3.881 msec
^C
--- 10.20.30.109 statistics ---
4 packets transmitted, 4 packets received,   0% unanswered (0 extra)
root@debian:/home/tufkal# ping 10.20.30.109
PING 10.20.30.109 (10.20.30.109) 56(84) bytes of data.
^C
--- 10.20.30.109 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3025ms

root@debian:/home/tufkal#

In the above example. 10.20.30.109 is the kirkwood device, and i'm on my own PC.

So here's the thing. We know it's not a problem with the arm packages, since it works on the RPi. We know it's not a problem with the current debian wheezy packages and current SVN of the code, because it worked on first time in a VM.

The make output is exactly the same, so there is no difference in dependencies or missing packages.

So, the only thing that is left is the kernel, it's the only thing that is different. I combed through the config for bodhi's kernel and I didn't see anything that jumped out at me that could be causing it.

@Almaz,

Which kernel are you running (uname -a) that works for TUN/TAP as you've mentioned here?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Like I said before your network isn't setup properly. Using VM is not the same as using a stand alone box. Setup routes, network bridge and iptables properly. Here is the basic setup for you http://blog.rot13.org/2011/10/n2n-connect-your-networks-using-p2p-vpn.html

My old box is running 3.12.0-kirkwood-tld-3 but I don't see why it shouldn't work with a new one if network is setup properly.



Edited 3 time(s). Last edit at 03/13/2015 05:08AM by Almaz.

The kernel i not likely to be in issue here - what i dont see from the install above is any reference to iptables, which isnt a dependecy of the above rather its an additional package. + i see from the above link that ip masquerading hs to be turned on - a VM will do all this for you

extract from http://blog.rot13.org/2011/10/n2n-connect-your-networks-using-p2p-vpn.html

remote# sysctl -w net.ipv4.ip_forward=1

remote# iptables -t nat -A POSTROUTING -s 10.1.2.1 -o tun0 -j MASQUERADE

This will turn forwarding and NAT for our packets coming from community tap interface and going out through tun0 to LAN. We also need to setup 

route on local side for remote LAN network:

local# ip route add 172.18.0.0/16 via 10.1.2.2

You guys are assuming I am bridging and creating an actual VPN with N2N. I am not. Each device can only contact other devices in the same /24, and can't connect to other devices on any other nodes network. It is a very simple setup, that I run on each machine I own (and several small machines in remote locations for backup). Iptables is not required, as no routing is done. My iptables --list output on every machine I looked at is blank, because they are all inside well secured networks with no open ports. I installed iptables on the kirkwood device for the hell of it, with the same blank table, no change.

Those sysctl options, and iptables would be needed if I had a edge node at home, and wanted to use my personal gateway remotely, or access resources on non-edge machines, but that is not the setup I use.

I don't feel like I need to explain why the comment about a "VM will do that for you" is incorrect, but to put that to rest I just got done installing Debian wheezy on an old laptop of mine. From the first boot I ran 4 commands.

wget http://dropbox.com/url/to/my/script.sh
sh myscript.sh
nano /etc/rc.local (set the IPs)
reboot

That machine came online after reboot, and I am able to communicate fully to and from it on it's edge IP. I don't know how much clearer I can be that this process works on every device I have, and is repeatably working on every setup I have tried except the kirkwood device using bodhi's 3.16 rootfs. Something is wrong, and I would like some guidance not to what I am doing wrong, but to how I can debug whats happening at that low ARP level so bodhi can get some info on where the bug is.

Running supernode and edge with -vvv shows everything is 100% perfect, the traffic from the kirkwood node is the same as any other, n2n is working fine (as per the ARPing results).

not sure i should be replying after having been told i dont know what im on about when i talk about VM's

"I don't feel like I need to explain why the comment about a "VM will do that for you" is incorrect"

so in my ignorance of all things virtual and physical i hesitate to offer you in your deep knowledge and wisdom of all things the following useful snippet when tracing low level network issues

tcpdump : https://packages.debian.org/wheezy/tcpdump

Ugh...i was hoping to avoid packet sniffing and going through pages of log files. tcpdump here I come I guess~

As to the comment on VM knowledge, I apolagize. I had just spent 5+ hours debugging this problem and I was cranky. I knew it couldn't be something that a VM would affect because I knew I wasn't routing or using iptables etc etc (which is now explained). I retract that snide comment~

tufkal Wrote:
-------------------------------------------------------
> Ugh...i was hoping to avoid packet sniffing and
> going through pages of log files. tcpdump here I
> come I guess~
>
> As to the comment on VM knowledge, I apolagize. I
> had just spent 5+ hours debugging this problem and
> I was cranky. I knew it couldn't be something
> that a VM would affect because I knew I wasn't
> routing or using iptables etc etc (which is now
> explained). I retract that snide comment~


Don't worry, you are not alone. When the first time I setup openvpn in Debian it took me all night to figure it out a simple problem with iptables and routing.

I don't have anything better to offer other than Almaz and Gravelrash already said, but am interested in how this problem is solved!

@tufkal,

Even though the kernel config is mostly the same between mainline Debianwheezy and my config, I think you've probly overlooked this point: if you install from mainline, there are a lot of default configurations settings were done by that process. When you install a custom kernel, especially on a barebone rootfs, you're mostly on your own about these settings.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> @tufkal,
>
> Even though the kernel config is mostly the same
> between mainline Debianwheezy and my config, I
> think you've probly overlooked this point: if you
> install from mainline, there are a lot of default
> configurations settings were done by that process.
> When you install a custom kernel, especially on a
> barebone rootfs, you're mostly on your own about
> these settings.

Agreed, there are many things that i'm sure they do to a default (even minimal) install that aren't in your rootfs build. One of them is what I need.

I don't think I overlooked that fact, I think I just got it in my head that you were as good as the entire Debian team, and made just as good a default build. :P You're saying your not the master of all kernels?? Lies! Bodhi knows all! :P

> Lies! Bodhi knows all! :P

:)) I wish there were a tiny grain of truth in that:))

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

OK so another multiple hour session beating my head on this, and heres what I got.

I did traffic back and forth from 2 brand new N2N nodes, one the kirkwood devices with bodhi's rootfs, and one my laptop with wheezy. As before, neither one could ping each other, but both show that they see each other on the ARP table.

Using tcpdump I can now also report that the kirkwood device receives echo requests, and produces a echo reply, but it is never received at the other end. Inversely, when the laptop is recieving from the kirkwood, it sees nothing.

So traffic on the TUN interface on the kirkwood is being produced, but isn't leaving the network card. It sees the pings, and makes a reply, but that reply hits something on it's way out. That same "thing" that the replies hit on the way out is just plain blocking outgoing traffic completely.

Incoming: Receives packets, produces replies, packets don't exit NIC
Outgoing: Produces packets, packets don't exit NIC

3 out of the 4 parts of this 2 way communication work, so the question now is why can my regular interfaces send traffic, but my TAP ones cannot? Why can eth0 send packets, and tun0 cannot?

I don't know the exact setup you have but it looks like you still didn't setup your network properly. eth0 is your wan network and doesn't know tap or tun0 even exist. The traffic you are trying to send via tap/tun doesn't know where to go. Setup bridge for now, here is an example.

EDIT /etc/network/interfaces

## This is the network bridge declaration
## Start these interfaces on boot
auto lo br0
iface lo inet loopback
iface br0 inet static 
  address 192.168.1.30 
  netmask 255.255.255.0
  gateway 192.168.1.1
  bridge_ports eth0
iface eth0 inet manual
  up ip link set $IFACE up promisc on
  down ip link set $IFACE down promisc off

To check your Bridge Connection

brctl show

To check your routing

route -n
ip route

If you are connecting to a different subnet then you must setup nat routing.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o br0 -j MASQUERADE

Don't forget to open N2N port.

iptables -I INPUT -p tcp --dport 443 -j ACCEPT

Edited 7 time(s). Last edit at 03/13/2015 10:57PM by Almaz.

postup your /interfaces file and the output of

ip a

route -n

route

obfuscate the mac addresses (consistently) as you see fit and we will have a looksie

Gravel, I will post your request in a sec:

Just noticed this. I went to bed last night frustrated, and didn't stop some of my tcpdump and pings, and this morning I found something interesting. It's not that traffic is not being sent out of the kirkwood device, it is being sent out with a MASSIVE delay. On the tcpdump for the working laptop node, I saw a bunch of ping requests from the kirkwood device, but they were recieved on the laptop over a minute after being generated on the kirkwood device. So traffic was making it out, but by the time it did, and a reply was generated on the laptop, I had long since pressed CTRL-C to stop the ping (let alone the TTL on the packet had expired).

Interestingly as well, a few pings overnight made it out and back within the TTL, as I found this on my kirkwood when I woke up:

PING 10.20.30.109 (10.20.30.109) from 10.20.30.108 n2n0: 56(84) bytes of data.
64 bytes from 10.20.30.109: icmp_req=47223 ttl=64 time=1.96 ms
^C
--- 10.20.30.109 ping statistics ---
76149 packets transmitted, 4 received, 99% packet loss, time 76148016ms
rtt min/avg/max/mdev = 1.967/1.967/1.967/0.000 ms

Here is the other end, on the working n2n node, the laptop running tcpdump showing 1 of the 4 that somehow made it out and was within the TTL to actually get a reply. Over 40k into the sequence.

11:13:34.334505 IP 10.20.30.108 > 10.20.30.109: ICMP echo request, id 2534, seq 47223, length 64
11:13:34.334569 IP 10.20.30.109 > 10.20.30.108: ICMP echo reply, id 2534, seq 47223, length 64

So....this is telling me what I kind of have suspected, that the setup is right but something very low level is causing a problem letting traffic exit the tun device on time, if at all. Very strange.

Also of note, when I start a ping from the kirkwood to the laptop, the tcpdump on the laptop immediately shows the arp request to get the MAC from the kirkwood, but doesn't show the ICMP traffic. Any other n2n node to any other, it looks like this (as it should)

19:49:38.971950 ARP, Request who-has 10.20.30.101 tell 10.20.30.109, length 28
19:49:38.974307 ARP, Reply 10.20.30.101 is-at e6:b5:a3:fd:03:f3 (oui Unknown), length 28
19:49:39.959014 IP 10.20.30.109 > 10.20.30.101: ICMP echo reply, id 25226, seq 1, length 64
19:49:40.960181 IP 10.20.30.101 > 10.20.30.109: ICMP echo request, id 25226, seq 2, length 64
19:49:40.960236 IP 10.20.30.109 > 10.20.30.101: ICMP echo reply, id 25226, seq 2, length 64
19:49:41.961369 IP 10.20.30.101 > 10.20.30.109: ICMP echo request, id 25226, seq 3, length 64
19:49:41.961427 IP 10.20.30.109 > 10.20.30.101: ICMP echo reply, id 25226, seq 3, length 64
19:49:42.963207 IP 10.20.30.101 > 10.20.30.109: ICMP echo request, id 25226, seq 4, length 64

------------

Here is the output of the requested commands

root@debian:/boot# cat /etc/network/interfaces 
auto lo eth0
iface lo inet loopback
iface eth0 inet dhcp
root@debian:/boot# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether MACHERE brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.151/24 brd 10.10.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 MACHERE/64 scope link 
       valid_lft forever preferred_lft forever
6: n2n0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether MACHERE brd ff:ff:ff:ff:ff:ff
    inet 10.20.30.108/24 brd 10.20.30.255 scope global n2n0
       valid_lft forever preferred_lft forever
    inet6 MACHERE/64 scope link 
       valid_lft forever preferred_lft forever
root@debian:/boot# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.10.1      0.0.0.0         UG    0      0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.20.30.0      0.0.0.0         255.255.255.0   U     0      0        0 n2n0
root@debian:/boot# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         DD-WRT          0.0.0.0         UG    0      0        0 eth0
10.10.10.0      *               255.255.255.0   U     0      0        0 eth0
10.20.30.0      *               255.255.255.0   U     0      0        0 n2n0
root@debian:/boot# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

My LAN is 10.10.10.0/24, while the N2N nodes are all in 10.20.30.0/24.



Edited 2 time(s). Last edit at 03/14/2015 07:51PM by tufkal.

Had spare 15 minutes and setup N2N in 2 locations just to check if it works, and it works fine. Confirmed N2N with Bodhi rootfs works great.



Edited 1 time(s). Last edit at 03/15/2015 12:12PM by Almaz.

OK, well I'm going to put a fresh rootfs on mine, can you outline what steps you took that are different from mine? I literally run that script I listed above on first boot, and then reboot.

What steps do you take differently?

And thanks for taking the time to try it on your hardware to help me figure it out, I appreciate it!



Edited 1 time(s). Last edit at 03/15/2015 01:17PM by tufkal.

The answer is in this thread.

Almaz Wrote:
-------------------------------------------------------
> The answer is in this thread.


I assume you got it working by installing bridge-utils, and bridging your interfaces. That's not how N2N works. If that's how you did it, it's a routing workaround. I have 7 other devices that don't even have that package (or even iptables in some cases) installed, and it works perfectly. N2N when launched does the routes, the arp table, the interface, and everything else on the fly. There is not reason to bandaid it with a bridged interface.

It all goes back to the same question. Why does it work on every other debian based distribution I try, on any hardware platform, but not this one?

On any other machine from first boot I run the script I outlined above, reboot, and on another machine the pings start seeing replies as it boots back up. It's that simple. It won't do that on this rootfs/kernel, and I want to figure out why.

Can I make this one work with a workaround, sure but that won't help me understand whats going on. I don't want it to just work, I want to learn why it isn't working, and possibly contribute to bodhi's work if I can find out why. This has turned into a network, kernel, and linux learning experience for me now~

@tutkal,

If you do what Almaz suggested, I am sure it will work. At the end of the day, once it is working, we all will learn something. That's I think the best contribution, because others will then know where to go for solution. After that, there is plenty of time to figure out the differences.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Without snat or proper routing it will NOT work in any debian or any other linux distros. That's how network works in linux & windows. It doens't matter if you use bridging method or routing method but somehow packets must know where to go. There is nothing wrong with Kernel or Bodhi rootfs. You never even showed what type of NAT routing you have in other debian boxes and I'm guessing you don't even know how to check it in the first place.



Edited 3 time(s). Last edit at 03/15/2015 09:09PM by Almaz.

The other boxes have no special routing, no iptables even installed, and were given the same script on first boot. You can go ahead and install wheezy on VM or baremetal and setup a working N2N node without any change to the network setup or routing. No package installs, no IP settings, hell I didnt even change resolv.conf. Almost every one of them has it's main interface in default DHCP, literally nothing has been touched and it works. You install the OS, on first boot you install the needed packages for the make, you wget it, make it, run it, it works. Except here, on this device, with this kernel and rootfs.

If everyone would stop assuming they know more than everyone else, and follow the steps I layed out you will see they work on a regular machine, and not on this device. Don't analyze my process, or amend it with your own knowledge, just either follow my steps to see for yourself, or believe me that I have done this for years, many many times, with no problems until I tried on this device.

To be clear, these are the steps again:

apt-get -q update
apt-get -y -q install build-essential libssl-dev subversion uml-utilities nano
cd ~
svn co https://svn.ntop.org/svn/ntop/trunk/n2n/n2n_v2
cd n2n_v2
make
make install
rm /etc/rc.local
cat <<EOT >> /etc/rc.local
#!/bin/sh -e
##
##-Uncomment this for a client node
##edge -d n2n0 -a static:10.2.3.XXX -c tufnet -k secret -l supernodeip:1201
exit 0
EOT
chmod +x /etc/rc.local
echo ***Edit /etc/rc.local to choose an IP and adjust password, then reboot.

As long as the kernel has the tun.ko driver enabled or as a module, the binary takes care of the rest. The binary create the routes, the interface settings, adds entries to the arp table, etc automatically. No additional work is needed by the end user beyond running the binary.

If my script is too complicated, simply follow the quckstart guide on the author's webpage: http://www.ntop.org/products/n2n/ My script is just automation of that process.

Again, I'm giving you actual results of installs on kirkwood and non kirkwood hardware, done using the steps above, which I have used for a very long time. I am actually installing Debian, and reimaging my kirkwood flash drive, doing these tests on multiple pieces of hardware in my basement, and in VMs on my desktop.

I don't expect anyone to teardown whatever they have on their kirkwood device to test this for me, but since I am doing exactly that (and on several other machines) I would hope you would at least accept my results.

The fact is if you setup 9 x86/x64 machines and 1 kirkwood device running this rootfs side by side, and had them all run the exact same keystrokes from first boot (following my script or the quickstart on authors webpage), the kirkwood will fail and the other 9 will work.

I could just stop and use a different device in this setup (RPi, ITX Atom, etc) but I'm really interested in this built from scratch kernel and rootfs that bodhi built, and this kirkwood device I stumbled upon, I want to understand why a process I have run on dozens of other machines fails here.

So please, don't point fingers at me, tell me what I do or do not know how to do something, because I'm not talking in theory. I have the machines here in front of me, this is what they are doing, I'm actually testing them myself and giving you the results. When I say i'm running that script off first boot and nothing else, I am literally not pressing any other keys or typing any other commands. It simply works, except here. If you want to help me, I will run any tests on them you can think of to help narrow down what is causing the problem if you need more data.

just spitballing here....

OK - so we are all in agreement that at some level, the installation does, either on its own or as part of an up-script on the alternate debian systems...............on the fly nat/snat/proxy configs.

so im wondering if netfilter is enabled or necesary either as a module is enable.

this will help in the hunting down of stuff

http://www.cyberciti.biz/faq/display-iptables-router-nat-connections-using-netstat-nat/

http://www.binarytides.com/linux-netstat-command-examples/

@tufkal
the output you gave from the commands i listed above, looks like i would expect from a standard output....

and i think one of your comments earlier may have hit the nail on the head.

"As long as the kernel has the tun.ko driver enabled or as a module"
quote : As long as the kernel has the tun.ko driver enabled or as a module, the binary takes care of the rest. The binary create the routes, the interface settings, adds entries to the arp table, etc automatically. No additional work is needed by the end user beyond running the binary. :quote

@bodhi, does your kernel have this option set? if it does then we should check its actually loaded on the "offending" system.

@tufkal - can you do an lsmod and check if its loading and functional??



Edited 1 time(s). Last edit at 03/16/2015 09:32AM by Gravelrash.

Kernel does have tun.ko module. I just noticed one of my pogoplugs with OpenVPN already have preloaded tun module. Another Pogoplug without OpenVPN (not using any vpn) tun module is not preloaded. Anyhow, the module can be loaded manually just run the following command

modprobe tun

i have a feeling - could be wrong, that if the O.P. loads the tun.ko module before running the initialisation script for his setup. that this would work......