On Sun, 12 Sep 2010 19:30:05 +0200 yy <[email protected]> wrote:
> 2010/9/12 Lucio De Re <[email protected]>:
> > My thinking is that 9vx could start up as root
> > to install the TAP device (nothing else so far has alerted me to a need
> > for root permissions), then switch user to the selected one (if it exists,
> > "nobody" may be needed if there is no equivalent in the host repertoire)
> > once setting up is complete.
>
> The advantage of the tap device is precisely that it does not need
> root permissions. You need those permissions to manage the devices,
> but that will be normally done by tunctl or openvpn. Those are the
> programs that have to worry about being run as root, not 9vx. In other
> words: you need to be root to create the tap device, but not to use
> it.
On a mac you don't need root perms to open a tap device.
(using Mattias Nissler's tuntap package). On FreeBSD you can
set sysctl
net.link.tap.user_open=1
to allow a nonroot process to open a tap device. On linux
you have tunctl.
But I agree you don't need 9vx to plan root games. You can
wrap a script around it.
> > And if anybody can arrange a short lesson on using networking under 9vx,
> > that would also be greatly appreciated.
You have a number of choices.
- If you only want to initiate connects from within 9vx to
the outside world 9vx's original choice is good enough.
- If you want to provide one or more services in 9vx that
others can connect to, you can perhaps just setup port
forwarding (like in ssh). The idea is to open a listening
socket on host when a 9vx process opens a listening port.
- If you want to fire up multiple 9vx instances, set up nfs
or some such services the host may also provide, provide
multiple network interfaces, or play with networking within
9vx, then you need a "full fledged host" that does its
own network processing.
Here you have two choices:
- open a host interface in "promiscuous" mode and filter
packets based on dest mac address (which is sort of like
bridging).
- use a tap device. Basically 9vx has to open host's
/dev/tapN. This should map to an ether interface within
9vx. Packets sent from 9vx appear as *input packets* on
the host network interface tapN. Packets output to (or
relayed to) host netif tapN appear as input data on
/dev/tapN. To send/recv packets to/from a real network
you have three choices (to be done on the host side):
- bridge to a phys device
- route (the host will forward. If you need dhcp in 9vx the
host must provide or relay dhcp)
- NAT (the host will do address translation)
Each has its pros and cons. Bridging, if it can be made
to work, is the simplest. But AFAIK you can't do bridging
on a host connected only via a wireless connection (at
least I don't know how to do that). MacOS ifconfig man
page, which seems to be cribbed from FreeBSD, talks about
bridging related subcommands and if_bridge(4) but to my
knowledge there is no built in bridging support in it.
But vmware and VirtualBox seems to allow bridging so
there must be a way....
*BSD and linux provide bridging.
