Forum: GNU Radio TunTap device problem in GRC

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
28a4af15b4d496d7900593255ea9c8a3?d=identicon&s=25 Ed Criscuolo (Guest)
on 2008-10-17 22:02
(Received via mailing list)
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<x> and /dev/tap<x> devices
right away, and doesn't seem to have the /dev/net/tun
master device. (Michael Dickens, 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
4252201ac30d6dd44d8090ce1070e35f?d=identicon&s=25 Josh Blum (Guest)
on 2008-10-17 23:24
(Received via mailing list)
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 ;)
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
781e96b7bd64e8833d71e3914cb1594a?d=identicon&s=25 Michael Dickens (Guest)
on 2008-10-18 00:33
(Received via mailing list)
On Oct 17, 2008, at 4:01 PM, Ed Criscuolo wrote:
> (Michael Dickens, 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.
28a4af15b4d496d7900593255ea9c8a3?d=identicon&s=25 Ed Criscuolo (Guest)
on 2008-10-18 05:20
(Received via mailing list)
Josh Blum 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<x> character device, and the associated tun<x> 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<x> 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
4252201ac30d6dd44d8090ce1070e35f?d=identicon&s=25 Josh Blum (Guest)
on 2008-10-18 05:39
(Received via mailing list)
>
> 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...
Dbdc5157899fcad4f0afbd8fd5875688?d=identicon&s=25 Berndt Josef Wulf (Guest)
on 2008-10-18 05:43
(Received via mailing list)
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
28a4af15b4d496d7900593255ea9c8a3?d=identicon&s=25 Ed Criscuolo (Guest)
on 2008-10-18 12:54
(Received via mailing list)
Josh Blum 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
This topic is locked and can not be replied to.