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

[Ed Criscuolo]

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.

@(^.^)@  Ed