Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Nov 2009 19:28:09 +0100
From:      Juergen Lock <nox@jelal.kn-bremen.de>
To:        Juergen Lock <nox@jelal.kn-bremen.de>
Cc:        freebsd-net@FreeBSD.org, freebsd-emulation@FreeBSD.org, Doug Barton <dougb@FreeBSD.org>
Subject:   Re: bridging vs wifi, proxy arp broken on 8.0 rc? (was: Re: Bridged networking for virtualbox on -current?)
Message-ID:  <20091123182809.GA35896@triton8.kn-bremen.de>
In-Reply-To: <200911222316.nAMNGwfV068520@triton8.kn-bremen.de>
References:  <4B08DD0C.3080106@FreeBSD.org> <4B0963BF.1070908@shapeshifter.se> <4B0972B5.40903@FreeBSD.org> <200911222316.nAMNGwfV068520@triton8.kn-bremen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 23, 2009 at 12:16:58AM +0100, Juergen Lock wrote:
> In article <4B09992F.1080900@shapeshifter.se> you write:
> >Doug Barton wrote:
> >> Fredrik Lindberg wrote:
> >>> Doug Barton wrote:
> >>>> Is bridged networking for vbox supposed to work on -current? It says
> >>>> on the wiki that it does, but I tried it tonight and couldn't get it
> >>>> to work.
> >>>>
> >>>> I did see one page that suggested trying one of the Intel virtual
> >>>> nicks, which I did, no luck.
> >>>>
> >>>> If this is not supposed to work it would be nice to update the wiki, I
> >>>> spent quite a bit of time trying to get it to work that I hope was not
> >>>> wasted.
> >>>>
> >>> The short answer is that it should work.  The long answer is that
> >>> it depends, for example it doesn't play nice when trying to
> >>> bridge a virtual nic with an if_bridge interface.
> >>>
> >>> A slightly more verbose description of your environment and what
> >>> error messages you're seeing would probably help.
> >> 
> >> Thanks. I'm using an up to date -current, and my outgoing nic is
> >> wlan0. I followed the instructions on the wiki. I first tried the
> >> default nic in OSE then I tried the first Intel nic on the list (which
> >> required downloading drivers of course).
> >> 
> >
> >Which type of virtual interface you're using in virtualbox doesn't
> >matter. However, it hits me that I've actually never really tested
> >the bridging code with a wireless interface and it looks like you've
> >hit a bug.  I tried to use a wireless interface just now and it
> >doesn't work, need to look into why though.
> 
> The problem with bridging and wifi is that on wifi you usually can
> use only a single mac address...  There are ways around this (using
> nat or routing), and I actually played with the latter using qemu tap
> networking recently, but couldn't get the most ideal solution working
> the way I wanted on 8.0 rc - it only worked on 7-stable.  (using a
> sub-subnet of the lan interface for the tap interface + guest, and
> routing + proxy arp for the guest ip.)  I just wanted to try it again
> on the 8.0 rc box and now even setting up the prox arp entry fails
> with:
> 	arp: writing to routing socket: Invalid argument
> Commands I tried:
> 	arp -s <guest ip> <host nic's mac> pub only
> and
> 	arp -s <guest ip> auto pub only
> (both before even configuring the tap interface this time...)
> 
>  Mind you my 8.0 rc checkout is a little old (Sep 29) so maybe I should
> try updating first (I want to test 8-stable anyway one of these days) -
> but looking for `arp' in the relevant commitlogs also came up empty. :(
> 
>  (I'm Cc'ing -net just in case, please keep me on the Cc cause I'm
> not subscribed there...)

I meanwhile found a few arp related commits (it helps if you don't
forget to ignore case when searching for `arp'...  doh! :) - but I
now also grabbed stable/8 and head snapshot isos and tested that
arp command there, and found its still broken. :(  (The same command
without the `only' succeeds but can never work for _this_ use case,
right?)

 How I tested (head snapshot livefs in qemu:)

% qemu -m 256 -cdrom 9.0-HEAD-20091123-JPSNAP-i386-dvd1.iso -net nic,model=e1000 -net user -curses

 [In sysinstall select fixit -> cdrom/dvd, then:]

Fixit# mkdir /var/db
Fixit# dhclient em0
DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 8
DHCPOFFER from 10.0.2.2
DHCPREQUEST on em0 to 255.255.255.255 port 67
DHCPACK from 10.0.2.2
bound to 10.0.2.15 -- renewal in 43200 seconds.
Fixit# arp -s 10.0.2.65 auto pub only
using interface em0 for proxy with address 52:54:00:12:34:56
arp: writing to routing socket: Invalid argument
Fixit# ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 52:54:00:12:34:56
        inet6 fe80::5054:ff:fe12:3456%em0 prefixlen 64 scopeid 0x1
        inet 10.0.2.15 netmask 0xffffff00 broadcast 10.0.2.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
Fixit# 

 And as I said stable/8 and 8.0 rc also suffer from the same bug.

 (sysinstall doesn't seem to have a way to shutdown instead of reboot
by itself but you can just `killall qemu' here when finished; if you
want less violent redirect the monitor or omit -curses if you have X
and in the monitor do `system_powerdown' to press the virtual acpi
powerbutton and then hit return in sysinstall to confirm the `abort
installation' prompt that should come up.)

 Thanx,
	Juergen

PS:  (Coming back to the actual tap networking on wifi use case:)
Of course you could still use static routes on the other lan boxen that
need to talk to the guest, or only use one on one box (like your
router/ap) and setup proxy arp on that, but thats not nearly as nice
as doing proxy arp on the same box that runs the guest.  But of course
its too late for 8.0 now...

PPS: btw there is another use case besides wifi for doing it this way,
i.e. routing + (optionally) proxy arp instead of bridging:  when you
want to protect your lan from stupid guests causing arp trouble etc...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091123182809.GA35896>