discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] TunTap device problem in GRC


From: Berndt Josef Wulf
Subject: Re: [Discuss-gnuradio] TunTap device problem in GRC
Date: Sat, 18 Oct 2008 15:12:22 +1030
User-agent: KMail/1.9.10

On Saturday 18 October 2008 13:49:23 Ed Criscuolo wrote:
> Josh Blum wrote:
> > 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.
>
> 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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]