[Discuss-gnuradio] Re: tun/tap OS X for tunneling

[Mark Kuhr]

Using the provided tuntaposx package (http://tuntaposx.sourceforge.net/index.xhtml 
), I finally got the error resolved.  I did not have to compile from  
the source code.  Basically, you just have to open the tap or tun  
interface for reading from python first, then you can see the device  
using "ifconfig -l" and assign it an address. The kext automatically  
creates the device when it is opened for reading.

As for getting it to work with GNU radio, I'm trying to get the  
tunnel.py example script to run for testing purposes. Without making  
changes to tunnel.py, I am currently receiving the "OError: [Errno 25]  
Inappropriate ioctl for device" error on this command:

ifs = ioctl(tun, TUNSETIFF, struct.pack("16sH", "gr%d", mode))

I'm guessing there is a difference in the ioctl implementation between  
linux and OS X.  I'm working through it and will post any progress.   
But if someone can point out what's wrong that would be helpful.

Mark


On Jan 6, 2009, at 8:22 AM, Michael Dickens wrote:

> Mark Kuhr <address@hidden> wrote:
> > Has anyone gotten tun/tap running on OS X 10.5 so they can tunnel  
> > packets to the USRP?
>
> tun/tap has been mentioned before on this list, but I know of noone  
> who's actively using it with GNU Radio on OSX; if anyone is, please  
> speak up!  Hence I'm going to try it out & see what it does.  Can  
> you / someone provide me with a quick example script to test the  
> functionality of a tun/tap device, with or without GNU Radio?
>
> Please note that the pre-compiled PKG version (not the source which  
> you would then compile) of tuntaposx is meant as a universal binary  
> for 10.4 or higher, but not specifically compiled for 10.5.  Given  
> that this is a kext, that might make a difference in correct  
> functionality (or not).
>
> I've submitted updates to MacPorts to correct the compile behavior  
> of "tuntaposx" source code, to allow it to compile correctly on, and  
> specifically for, 10.4 and 10.5 when using MacPorts.  I expect those  
> change to propagate through the system in the next couple of days.   
> If anyone wants these files (as an archive which can overwrite that  
> provided by MacPorts) for testing purposes, I'm happy to provide  
> them. - MLD