Bridging guest on mac os x host vlan cause reception of malformed packets on gest NIC

[Luca Ghedini]

On Mac OS X 10.5.8 with a primary NIC named en0 and a virtual NIC named vlan3 accessing tagged traffic on en0

Guest is linux, eth0 is bridged to vlan3

Sniffing traffic with tcpdump on both host (vlan3) and guest (eth0) shows that some of the packets reaching guest contains additional 4 bytes after source/dest MAC address replicating the last 4 bytes of the source MAC.

[Ramshankar Venkataraman]

Could you dump the packets to an output file, then compress and attach the files that shows a sample of such corruption?

[Luca Ghedini]

arp packet as seen from the host machine

[Luca Ghedini]

the same arp packet as seen from the guest machine, red line show the bug

[Luca Ghedini]

the last version seems to present the same behavior

[Giovanni Toraldo (gionn)]

Maybe #6284 is related to this bug.

[Luca Ghedini]

Replying to gionn:

Maybe #6284 is related to this bug.

i don't think so. I my bug seem the problem seems related to the presence of the 2 byte extension in the ethernet header....

[Luca Ghedini]

the bug is still present in 3.2.8

[Luca Ghedini]

the bug is still present il 4.0 release

[Luca Ghedini]

the bug is still present using mac os x 10.6.x

[Aleksey Ilyushin]

How did you bridge to vlan3? VirtualBox does not support attaching to vlan interfaces. They are listed as interfaces available for attaching in bridged networking but they do not follow the name convention (BSD_name: OS_X_name) so VirtualBox fails to attach to such interfaces upon VM startup.

Or did you actually attach to en0?

[Luca Ghedini]

i just edit the xml config file for the machine , adding

<Adapter slot="0" enabled="true" MACAddress="08002796F281" cable="true" speed="0" type="virtio">

<DisabledModes>

<NAT>

<DNS pass-domain="true" use-proxy="false" use-host-resolver="false"/> <Alias logging="false" proxy-only="false" use-same-ports="false"/>

</NAT>

</DisabledModes> <BridgedInterface name="vlan0: Ethernet"/>

</Adapter>

[Aleksey Ilyushin]

I cannot reproduce the problem, the packets in the guest appear exactly as on host's vlan interface. What is the purpose of attaching to vlan interface anyway? Wouldn't it be more appropriate to attach to en0 instead and configure vlan in the guest?

[Luca Ghedini]

Replying to aleksey:

I cannot reproduce the problem, the packets in the guest appear exactly as on host's vlan interface.

You are attach the guest to a vlan (on mac os x) and all is it ok? i can reproduce the problem on different mac (10.5/10.6) with different release of virtual box e different flavor of linux guest

What is the purpose of attaching to vlan interface anyway? Wouldn't it be more appropriate to attach to en0 instead and configure vlan in the guest?

the porpuose:

i run 6 labs with 600 client (xp/7/linux) i wish to reproduce (on virtual box) a "mini lab". In the real world the pc client inside the lab get the network traffic untagged.

more:

on vindowze the use on tagged traffic is not so easy: it's depends heavily on the release of network driver.

[Aleksey Ilyushin]

Replying to ghedo:

You are attach the guest to a vlan (on mac os x) and all is it ok?

That depends on what you mean by ok. I do get ARP packets in guest exactly the same as on host's vlan interface, but I cannot ping remote hosts on the same VLAN. I see ARP request sent to remote host, but reply never reaches vlan interface where it could be picked up by VirtualBox, although the reply appears on host's en0. The host drops the reply without passing it to vlan interface. Do you get different results? If yes, could you send me two packet capture files: one taken from vlan3 and another from internal packet capture. You can enable internal capture with

VBoxManage modifyvm <vmname> --nictrace1 on --nictracefile1 <name_of_your_choice>

You can reach me at aleksey dot ilyushin at oracle dot com.

i run 6 labs with 600 client (xp/7/linux) i wish to reproduce (on virtual box) a "mini lab". In the real world the pc client inside the lab get the network traffic untagged.

Due to host's behavior I mentioned above I doubt that attaching to vlan interface will be of any practical value for your purposes.

[Aleksey Ilyushin]

Is the issue still present in 4.0.12 or 4.1?

[Frank Mehnert]

No response, closing.

[Luca Ghedini]

the bug is still present in 4.1.6 r74713

[Luca Ghedini]

the command VBoxManage modifyvm kdc --nictrace1 on --nictracefile1 /tmp/kdctrace does not produce no output. A standard tcpdump file taken on a linux guest and on a real client on vlna3 could help ?

[DWPoon]

Me too. Reproduced on VirtualBox 6.0.6, and confirmed by comparing the nictrace on the VM to a Wireshark capture on the tagged VLAN interface. I suspect that the place to start looking is src/VBox/HostDrivers/VBoxNetFlt/darwin/VBoxNetFlt-darwin.cpp, but I am unfortunately ​unable to start a VM on my self-built VirtualBox to help troubleshoot.

[DWPoon]

That extra four bytes would be the ​802.1Q header, which should be edited out when copying an Ethernet frame from a tagged interface to an untagged interface.

[DWPoon]

​mbuf_clear_vlan_tag() should be called somewhere? Perhaps in vboxNetFltDarwinMBufFromSG()?