[Top][All Lists]
[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