From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Sun, 12 Sep 2010 19:30:05 +0200." References: <20100912161716.GB3919@fangle.proxima.alt.za> From: Bakul Shah Date: Sun, 12 Sep 2010 12:27:07 -0700 Message-Id: <20100912192707.9169F5B18@mail.bitblocks.com> Cc: lucio@proxima.alt.za Subject: Re: [9fans] 9vx/vx32 - Out of ignorance Topicbox-Message-UUID: 565413a4-ead6-11e9-9d60-3106f5b1d025 On Sun, 12 Sep 2010 19:30:05 +0200 yy wrote: > 2010/9/12 Lucio De Re : > > 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.