Re: [Discuss-gnuradio] TunTap device problem in GRC
Josh Blum wrote: 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TunTap device problem in GRC
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 character device, and the associated tun 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 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 mtu 1500
inet 10.0.0.1 -> 10.0.0.2 netmask 0xff00
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TunTap device problem in GRC
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... @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TunTap device problem in GRC
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 character device, and the associated tun 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 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TunTap device problem in GRC
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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TunTap device problem in GRC
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
Ed Criscuolo wrote:
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 and /dev/tap 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_dev
[Discuss-gnuradio] TunTap device problem in GRC
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 and /dev/tap 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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
