TunTap device problem in GRC

Has anybody had any luck using the Tun/Tap device in GRC?

I’ve tried it with GRC 0.70 and 0.69 under Fedora 8, and
GRC 0.69 under Mac OSX and had no luck, even when running
everything as root.

Under OSX 10.4, I installed Mattias Nissler’s tun/tap driver
( http://tuntaposx.sourceforge.net/ ) dated 2008-Aug-4. It
creates all the /dev/tun and /dev/tap devices
right away, and doesn’t seem to have the /dev/net/tun
master device. (Michael D., have you had any experience
with the tun/tap driver on OSX?) Trying to use the
/dev/tun0 in place of /dev/net/tun predictably failed,
producing

 ifs = ioctl(tun_fd, TUNSETIFF, struct.pack("16sH",

virtual_device_filename, mode))
IOError: [Errno 25] Inappropriate ioctl for device


Under Fedora 8, with either GRC 0.69 or 0.70, things
went a little better, but not much. With the following
flow graph


| | | Tun/Tap | | |
| Vector |----->| Dev = /dev/net/tun |—>| File |
| Source | | Virt Dev = tun%d | | Sink |
| | | IP addr = 10.0.0.1 | | |


things ran without error and the net pseudo-device “tun0”
was created, but an ifconfig showed that no IP address
was assigned to it. I successfully used ifconfig to
assign address 10.0.0.1 to it, and sent packets to
that address, but nothing was captured in the file.
And another ‘ifconfig tun0’ showed that no new TX bytes
had been sent out the interface.

Is there an error in GRC that results in the IP address
not being assigned? And why didn’t my packets get there
when there WAS an address assigned?

@(^.^)@ Ed

I pasted the relevant code below so we can reference its mystery hex
number.

The tun tap block in grc takes code from the tun tap example to open a
tun tap file descriptor. The file descriptor is fed into a file
descriptor source and sink. From the outside of the tun tap block, we
see the input to the file descriptor sink and the output of the file
descriptor source.

GRC will try to exec ifconfig on the tun tap device name, if an ip
address is specified. You can manually run ifconfig as well. I dont
think this is the problem.

Should this work in linux? Maybe.

Should this work in mac os? Possibilities are even worse: those hard
coded hex values, they probably have header file constants that change
numeric value from linux to freebsd.

This could be helpful:
http://alex.king.net.nz/tuntap.html

Relevant Code from 0.70:

#######################################################################################

TUN/TAP

#######################################################################################

IFF_TUN = 0x0001 # tunnel IP packets
IFF_TAP = 0x0002 # tunnel ethernet frames
IFF_NO_PI = 0x1000 # don’t pass extra packet info
IFF_ONE_QUEUE = 0x2000 # beats me :wink:
DEFAULT_TUN_DEVICE = ‘/dev/net/tun’
DEFAULT_VIRTUAL_DEVICE = ‘tun%d’
DEFAULT_IP_ADDR = ‘10.0.0.1’

def open_tun_interface(tun_device_filename=DEFAULT_TUN_DEVICE,
virtual_device_filename=DEFAULT_VIRTUAL_DEVICE):
“”“!
Open a virtual ethernet interface via the Tun/Tap framework.
An alternative function can be found: “from eunuchs.tuntap import
opentuntap”
@param tun_device_filename the path to the tun device
@param virtual_device_filename the name of the virtual device (to be
created)
@return a file descriptor to rw the device, name of the virtual device
(created)
“””
from fcntl import ioctl
mode = IFF_TAP | IFF_NO_PI
TUNSETIFF = 0x400454ca
tun_fd = os.open(tun_device_filename, os.O_RDWR)
ifs = ioctl(tun_fd, TUNSETIFF, struct.pack(“16sH”,
virtual_device_filename, mode))
ifname = ifs[:16].strip(“\x00”)
return tun_fd, ifname

class TunTapHelper(gr.hier_block2):
“”“Make the tun tap hier2 block.”“”
def init(self, item_size, tun_fd):
“”“!
TunTapHelper constructor.
@param item_size the size in bytes of the IO data stream
@param tun_fd the file descriptor for the virtual device
“””
#create hier block
gr.hier_block2.init(
self, ‘tun_tap’,
gr.io_signature(1, 1, item_size),
gr.io_signature(1, 1, item_size)
)
#I/O blocks
sink = gr.file_descriptor_sink(item_size, tun_fd)
source = gr.file_descriptor_source(item_size, tun_fd)
#connect
self.connect(self, sink)
self.connect(source, self)

def TunTap(sb):
gr.file_descriptor_sink, gr.file_descriptor_source #uses
type = Enum(all_choices, 1)
sb.add_input_socket(‘in’, Variable(type))
sb.add_output_socket(‘out’, Variable(type))
sb.add_param(‘Type’, type, False, type=True)
sb.add_param(‘Tun Device’, String(DEFAULT_TUN_DEVICE))
sb.add_param(‘Virtual Device’, String(DEFAULT_VIRTUAL_DEVICE))
sb.add_param(‘IP Address’, String(DEFAULT_IP_ADDR))
sb.set_docs(‘’’
Foward data between gnuradio and a virtual ethernet interface.

Tun Device: File path to the tun device.

Virtual Device: Desired name for the virtual ethernet device.
“%d” will give the device a number starting at zero.

IP Address: IP address for the virtual device, leave blank and device
will not be configured.
‘’')
def make(fg, type, tun, virt, ip_addr):
item_size = type.parse().get_num_bytes()
tun_fd, ifname = open_tun_interface(tun.parse(), virt.parse())
#try to set the ip address
ip_addr = ip_addr.parse()
if ip_addr: os.system(‘ifconfig %s %s’%(ifname, ip_addr))
return TunTapHelper(item_size, tun_fd)
return sb, make

On Oct 17, 2008, at 4:01 PM, Ed Criscuolo wrote:

(Michael D., have you had any experience
with the tun/tap driver on OSX?)

Nope; never heard of it. I’ll look at it, but no promises.

Looks like it should. Yet, when I run it in linux, the tun0 network
device gets created without the IP address, but manually running
the same ifconfig command works. At least as far as asigning the
address.

GRC expects to have root access in this case, you may be running grc as
user, and ifconfig with sudo.

Looks like we either need an abstraction layer, or something
that converts the OSX semantics to the Linux API.

Can you make a ticket with any osx specific findings? I will do
something about this tun/tap for the grc trunk in a few…

On Saturday 18 October 2008 13:49:23 Ed Criscuolo wrote:

GRC will try to exec ifconfig on the tun tap device name, if an ip
Should this work in mac os? Possibilities are even worse: those hard
thru /dev/tun15. You have to open the specific one to get the associated
Looks like we either need an abstraction layer, or something
that converts the OSX semantics to the Linux API.

OSX and NetBSD seem to be very similar in behaviour see below:

barossa: {10} ifconfig tun0 create
barossa: {11} ifconfig tun0 10.0.0.1 10.0.0.2
barossa: {12} ifconfig tun0
tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
inet 10.0.0.1 -> 10.0.0.2 netmask 0xff000000

cheerio Berndt

Josh B. wrote:

address is specified. You can manually run ifconfig as well. I dont
think this is the problem.

Should this work in linux? Maybe.

Looks like it should. Yet, when I run it in linux, the tun0 network
device gets created without the IP address, but manually running
the same ifconfig command works. At least as far as asigning the
address.

Should this work in mac os? Possibilities are even worse: those hard
coded hex values, they probably have header file constants that change
numeric value from linux to freebsd.

Quite likely. In addition, I’ve found that the tun/tap driver works
differently on OSX. In Linux, there’s a “master” tun device called
/dev/net/tun. Opening this returns a unique fd and creates both the
/dev/tun character device, and the associated tun network device.

In the Mac OSX tun/tap driver, there is no master /dev/net/tun device.
Instead, the driver precreates all the character devices from /dev/tun0
thru /dev/tun15. You have to open the specific one to get the associated
net device created.

In addition, the ifconfig command works differently on OSX than
on Linux. The OSX tun network devices are created as
point-to-point devices, and the OSX ifconfig command REQUIRES
the IP address of the far side of the link. And the syntax is
different. Linux uses the keyword “pointopoint”, while OSX
just uses two addresses, eg - “ifconfig tun0 10.0.0.1 10.0.0.2”.

Looks like we either need an abstraction layer, or something
that converts the OSX semantics to the Linux API.

@(^.^)@ Ed

Josh B. wrote:

Nope, I’m running it as root. When I run as a user, I get
an “Operation not permitted” on the ioctl, before GRC even
gets to the ifconfig invocation.

Looks like we either need an abstraction layer, or something
that converts the OSX semantics to the Linux API.

Can you make a ticket with any osx specific findings? I will do
something about this tun/tap for the grc trunk in a few…

Will do.

@(^.^)@ Ed