Re: [9fans] 9vx/vx32 - Out of ignorance

[Bakul Shah <bakul+plan9@bitblocks.com>]

On Sun, 12 Sep 2010 19:30:05 +0200 yy <yiyu.jgl@gmail.com>  wrote:
> 2010/9/12 Lucio De Re <lucio@proxima.alt.za>:
> > 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.