bridged-to-wifi adapter escapes the packets with guest dst-mac
|Reported by:||aleksey.shipilev||Owned by:|
|Guest type:||Linux||Host type:||Linux|
This is how it works. A simple network:
(server) ---eth--- (router) ---wlan--- (laptop) . . .... bridge ....
- Connect the laptop to wireless:
HWaddr: f8:16:54:d3:13:87 ipv4: 192.168.79.75
- On laptop, start VirtualBox with Debian guest. Set the networking as "Bridged" via wlan0. The guest will be configured with this:
HWaddr: 08:00:27:bb:4b:cb ipv4: 192.168.79.76
- Do the arping from server, figure out both host and guest share the host mac.
arping(192.168.79.75) = f8:16:54:d3:13:87 arping(192.168.79.76) = f8:16:54:d3:13:87
- In guest, start "iperf -s". On host, start "iperf -c 192.168.79.76". This will yield around 90-100 Mbps of traffic in my setup.
- Look into the router statistics (Mikrotiks are very good at introspection). See the baffling thing: 90-100 Mbps comes from wlan, and then replicates on every single bridge port, including the Ethernet port on which the server is connected. If you look at tcpdump on server, you will see the packets that do not belong to server at all, but are the part of unicast between the host (laptop) and guest there:
23:11:42.080835 f8:16:54:d3:13:87 (oui Unknown) > 08:00:27:bb:4b:cb (oui Unknown), ethertype IPv4 (0x0800), length 2962: 192.168.79.75.56815 > 192.168.79.76.5001: Flags [.], seq 4516312:4519208, ack 1, win 229, options [nop,nop,TS val 48947332 ecr 109821], length 2896
- iperf is a one-sided test, so you can try the different direction. Start "iperf -s" on host, "iperf -c 192.168.79.75" in guest. You will have around 500-600 Mbps (!!!). Router statistics will show minimal traffic on the bridge now, and server tcpdump yields a few packets with "length 0" now:
23:17:43.182499 f8:16:54:d3:13:87 (oui Unknown) > 08:00:27:bb:4b:cb (oui Unknown), ethertype IPv4 (0x0800), length 66: 192.168.79.75.5001 > 192.168.79.76.55686: Flags [.], ack 125813305, win 24576, options [nop,nop,TS val 49037609 ecr 200144], length 0
I speculate the issue is that the router's bridge has no idea where 08:00:27:bb:4b:cb (guest mac) lives, and therefore it ends up broadcasting it to everyone, desperately waiting for reply, that will never come with guest mac as src mac. This effectively:
a) leaks the unicast host-guest packets into the external network
b) bottlenecks the host-guest link to the external link bandwidth (notice the asymmetry above: 100 Mbps host-guest, and 500 Mbps guest-host)
c) in some cases, like mine, DoSes the external network.
Therefore, I believe this is a major defect that should be fixed.
I further speculate this is because VirtualBox's bridge adapter sends the packets with "dst mac" == "guest mac" both to the guest and into the external network, that has no other alternative than to broadcast it.