Thanks a lot for the fix! I've added it to the kmod port in our testing repository and it will be included in the next update for vbox 4.1.14.
https://redports.org/changeset/13816 On Sun, May 26, 2013 at 6:17 PM, Landon Fuller <[email protected]> wrote: > Hello, > > This patch has been in the vbox kmod port for some time now, and I've been > running it without incident; however, I recently ran into a configuration > that the patch does not correctly handle: > - A single host interface (eg, em0) bridged to a VM > - VLANs also configured on the host interface (em0.vlan0, em0.vlan1) > > The packet flow in this situation should be: > - The ng filter is handed a packet from em0 > - The filter re-adds the VLAN header to the top of the packet and > strips the M_VLANTAG flag > - After passing to the virtual switch, the packet is re-injected into > the host via ether_demux(). > - ether_demux() extracts the embedded VLAN tag and hands the packet > off to vlan_input_p(). > > As it turns out, ether_demux() does not handle frames with embedded VLAN > tags, and at this point, the packet is dropped, rather than being routed to > the host's VLAN handling: > > http://lists.freebsd.org/pipermail/freebsd-net/2011-October/030201.html > > The result is as follows: > - Packets received via the host interface are handled correctly. > - Packets (including VLAN tagged packets) are passed to sub-VMs > correctly. > - Packets that *should* be handled by vlan* sub-interfaces on the > host are never received by those interfaces as they're dropped in > ether_demux(). > > This worked in my existing configuration because the host and the VMs > actually use two different VLAN trunks (em0 and em1), and so em0 packets > being dropped after injection into the virtual switch does not affect the > host's handling of packets on em1. > > I've attached an updated patch that should resolve this issue; I'm currently > testing it locally on my home deployment and so far it is working fine. The > patch simply restores the VLAN flags and stripped ethernet header after > injecting the packet into the virtual ethernet switch. With this change in > place, ether_demux() correctly hands the packet off to vlan_input_p(). > > Cheers, > Landon > > > > > On Apr 13, 2012, at 2:51 PM, Landon J Fuller <[email protected]> wrote: > >> Howdy, >> >> I was looking into trunking VLANs into a virtual machine via bridging, and >> noted that transmit of 802.1q tagged packets worked from the guest VM, but >> upon reception, the VLAN tag seemed to be stripped before the packets hit >> the guest's interface. >> >> Taking a look at the netgraph-based bridging implementation, it looks like >> the VLAN tag is not being re-inserted at the head of the ethernet frame >> prior to handing off the to VirtualBox, and VBox doesn't seem to have an >> equivalent 'ether_vtag' field in its INTNETSG struct to handle this. >> >> Thus, to preserve the VLAN tag, I modified vboxNetFltFreeBSDMBufToSG() to >> ether_vlanencap() to insert the VLAN tag before handing off to VBox. With >> this in place, I was able to successfully trunk VLANs to a virtual machine. >> >> Some caveats: >> - If using virtio-kmod's if_vtnet, you must set vlanhwfilter (or >> promisc) flags on the guest interface before virtualbox will pass the VLAN >> tagged packets through. Otherwise, the VBox virtio-net device implementation >> will filter out the incoming packets before handing them to the VM hardware. >> - VBox's em(4) host implementation does not appear to support >> 'hardware' VLAN tagging, but it does declare it. If using a em(4) >> virtualized NIC, you must set -vlanhwtag on the guest interface. >> >> I welcome someone(s) with more experience than I eyeballing the (tiny) >> attached patch. I'm also especially concerned as to whether this should be >> considered supported functionality in VBox, or I'm just getting lucky with >> the virtio-net code path. >> >> Thanks, >> Landon >> >> <patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c>_______________________________________________ >> [email protected] mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation >> To unsubscribe, send any mail to "[email protected]" > > > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "[email protected]" -- Bernhard Froehlich http://www.bluelife.at/ _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "[email protected]"
