As some context to this issue:
Testing using a known working .ovpn file and connecting to the same known working access server (2.7.4).
This was successfully tested using a different architecture to confirm works on a 2.1.4 client connecting to he same 2.7.4 server.
All ovpn clients are built statically, and include OpenSSL/LZO libraries.
The specific issue is when running on the mipsel device under Linux Kernel (3.3).
As the device doesn't have the TUN/TAP drivers compiled into the kernel, it was necessary to cross compile the tun/tap to mipsel, to generate a loadable tun.ko module using the correct kernel source.
The tun.ko built fine and installs using insmod on the device.
Did all the standard ...
mkdir /dev/net
mknod -m 0600 /dev/net/tun c 10 200 1
so far so good..
When running up ovpn client, the connection successfully completes, tun0 is up and connects. All routes are enabled.
However, the following is seen each time a subsequent packet is in flow.
write to TUN/TAP : Invalid argument (code=22)
Also noticed packets are dropped.
Having added kernel logging to the tun.c file, it was noticed that the error 22 (EINVAL) comes from the fact that the first byte in the 'header' is neither 0x40 or 0x60 (so not ipv4/ipv6). In fact the first byte value appears to be 'random'.
Excerpt from drivers/net/ tun.c@kernel 3.3 below:
Code: Select all
if (tun->flags & TUN_NO_PI) {
switch (skb->data[0] & 0xf0) {
case 0x40:
pi.proto = htons(ETH_P_IP);
break;
case 0x60:
pi.proto = htons(ETH_P_IPV6);
break;
default:
tun->dev->stats.rx_dropped++;
kfree_skb(skb);
return -EINVAL;This has been tested both with and without lzo compression, but still results in same issue. (i.e. numerous searches seem to imply compression or issues across client/server compression settings could be relevant). I have for now removed the issue of compression settings from the equation based on configuration changes/tests at both ends. Again, this works using same settings/versions on a different architecture, so currently at a loss.
If any one has any valued experience in the tun/tap interface usage, or could suggest a reason why the packets are dropped in this way, would be very much appreciated.