How can VirtualBox working with wifi bridge?

Question

Today I have installed VirtualBox on Debian 12 and using wifi bridge work, I can ping the vm using the same ip class of wlan0 wifi (88x2bu driver), but ip addr and ip link sh don't report interface

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether ******** brd ******
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether ************ brd ********** permaddr *******

, where is the bridge?

With other applications like kvm/qemu libvirt I ever failed to set any bridge with wlan (with ethernet is ok), how is possible that VirtualBox can use bridge and libvirt not? For libvirt I ever use the virbr solution: create a virbr interface that "point" to wlan something like this

    <name>wifibr</name>
  <uuid>***</uuid>
  <forward dev='wlan0' mode='route'>
    <interface dev='wlan0'/>
  </forward>
  <bridge name='virbr5' stp='on' delay='0'/>
  <mac address='****'/>
  <domain name='rosso.priv'/>
  <ip address='192.168.201.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.201.128' end='192.168.201.254'/>
    </dhcp>
  </ip>
  <dnsmasq:options>
    <dnsmasq:option value='dynamic-host=rosso.priv,0.0.0.0,wlan0'/>
  </dnsmasq:options>
</network>

Trying a bridge fail

brctl addif br0 wlan0
can't add wlan0 to bridge br0: Operation not supported

Question: how virtualbox bridge work? Is possible to make something similar with libvirt? I prefer to use my wlan0 ip class

Answer 1

Virtualbox doesn't do bridging in the same way. It uses a "net filter" interface to intercept packets.

From https://www.virtualbox.org/manual/ch06.html#network_bridged

With bridged networking, Oracle VM VirtualBox uses a device driver on your host system that filters data from your physical network adapter. This driver is therefore called a net filter driver. This enables Oracle VM VirtualBox to intercept data from the physical network and inject data into it, effectively creating a new network interface in software. When a guest is using such a new software interface, it looks to the host system as though the guest were physically connected to the interface using a network cable.

The host won't see this in normal tools ip -a, etc, because this is at a lower level; there is no interface associated with it.

From the virtualbox GUI you can select which interface will be bridged. This will also show in the .vbox configuration file for the VM

e.g.

    <Network>
        <Adapter slot="0" enabled="true" MACAddress="XXX">
          <DisabledModes>
            <NAT localhost-reachable="true"/>
            <InternalNetwork name="intnet"/>
            <NATNetwork name="NatNetwork"/>
          </DisabledModes>
          <BridgedInterface name="enp1s0"/>
        </Adapter>

Answer 2

is not possible to make something similar with libvirt?

Unfortunately, no. An important part of the VirtualBox method is that its filter driver not only implements Ethernet bridging, but also MAC address rewriting.

The real reason that prevents Wi-Fi 'client' interfaces from being bridged is that Wi-Fi only permits a client to send frames from its own MAC address¹ – the same "source MAC address" field serves two purposes in Wi-Fi, and identifies both the MAC sender (upper half of layer 2) and the physical Wi-Fi radio that is associated with a specific access point (lower half of L2). In short, the sender's MAC address is used to select the WPA decryption key, other Wi-Fi radio parameters, so it is not possible for your WLAN interface to arbitrarily send frames from the VM's MAC.

VirtualBox works around this by implementing essentially MAC-level NAT – its internal bridge implementation swaps the VM's MAC address with the host's in all frame headers, rewrites ARP queries and ICMPv6 Neighbor Discovery packets, and keeps track of IP addresses so that upon receiving a frame from the network (addressed to the host's MAC of course) it could swap in the correct VM's destination MAC again. (See Devices/Network/SrvIntNetR0.cpp.)

Linux, as far as I know, does not have a native equivalent to that; instead it just refuses bridging a Wi-Fi client interface.

(The recommended solution would be to get an Ethernet cable.)

---

¹ The 802.11 frame header is asymmetric – the "access point" side gets two address fields, the "client" side gets only one. A four-address mode that allows client-side bridging is possible and Linux even supports it, but most APs will reject such frames; it's very rare to have an AP that can be configured to accept 4addr frames.