Sending Packets to tap0 interface

Question

I've been trying to send packets to a tap interface using python. I'm monitoring the tap interface using wireshark and no packets are being received. I'm doing this as an exercise mainly to help my understanding of vpns, ethernet bridging and socket programming in python.

My System Setup is as follows:

Ubuntu Desktop 11.10
Python 2.7
eth0 ip: 192.168.1.6
tap0 ip: 10.0.0.1

I first setup the tap as follows:

sudo openvpn --mktun --dev tap0
sudo ifconfig tap0 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255 promisc up

This starts the tap0 interface and creates a kernel routing rule to 10.0.0.1/24 via tap0.

Here is the route table:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        *               255.255.255.0   U     0      0        0 tap0
192.168.1.6     *               255.255.255.0   U     1      0        0 eth0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Next I start python interactive and create a simple UDP socket.

import socket
s = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
s.sendto('helloworld',('10.0.0.2',12345))

I run the sendto command with Wireshark monitoring on tap0. Now, there is no host at 10.0.0.2 on my network, but I should at least see some outgoing traffic on the tap0 interface. I have replicated this in windows and it seems to work ok.

I can only think that the problem lies somewhere in the setup of the tap0 interface under linux. That or my mediocre understanding of this stuff.

Thanks

Solution

The tap is meant for bridged tunneling under OpenVPN - you're supposed to junction it into a bridge such as br0 using brctl.

The idea is you can put tap0 and eth0, for example, into a bridge br0 - then broadcast traffic traverses across this bridge. (Broadcast traffic coming in from tap0 will be forwarded to eth0 and vice versa whereas in a routed, standard situation it would not.) Your OpenVPN tunnel via tap0 is then "switched" into eth0 instead of "routed" into it. The entire br0 gets an IP and you deal with br0 instead of eth0 or tap0.

Completely possible to have a bridge with only one interface and add/remove additional interfaces with brctl as needed.

So either put tap0 into a bridge and deal with the bridge interface instead, or use tun interfaces.

It's also possible iptables rules are interfering.

Update - look here: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ - particularly this excerpt:

The difference between a tap interface and a tun interface is that a tap interface outputs (and must be given) full ethernet frames, while a tun interface outputs (and must be given) raw IP packets (and no ethernet headers are added by the kernel). Whether an interface functions like a tun interface or like a tap interface is specified with a flag when the interface is created.

So looks like if you don't send full ethernet frames to tap0 it won't work as your expect because of this above.

Comments

[Paul]

Hmm, you'll see an arp request at the most, but you should see it. Do you see anything in wireshark when you ping 10.0.0.1? Have you confirmed wireshark is working by seeing if you see data on eth0?

[Pete]

I have tried this exact same experiment at work on a Fedora15 box. It works. ARP packets are sent on the interface. Any idea if this could be a ubuntu or later linux kernel issue?

[Paul]

Perhaps, but we need to check the basics first.

[Pete]

I have had some success on Fedora15 (still none on ubuntu desktop). I have tried bridging to eth0 and immediately data starts flowing. What I don't understand is how a bridge can have an IP address if it is the software analog to a switch.

[LawrenceC]

On a hardware switch, the ports on the switch don't have IPs, but the ports on the devices connected at the other end do. The bridge itself doesn't have an IP but the exposed endpoints which are virtual interfaces on your machine do.

[LawrenceC]

Actually I just confused myself by writing this and then reading my posted answer. Disregard that previous comment. I probably could stand to learn more about the details of Linux bridging - but I did get a bridged OpenVPN working and the above is how I did it.