Re: kern/60055: bridge doesn't work well with urtwn(4)

["Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60055; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/60055: bridge doesn't work well with urtwn(4)
Date: Wed, 4 Mar 2026 12:49:22 -0000 (UTC)

 gnats-admin%NetBSD.org@localhost ("imuwoto%gmail.com@localhost via gnats") writes:
 
 >for some reasons, adding urtwn0 as a physical port of a bridge(4) didn't work.
 >other members of the bridge: vether0, tap (for qemu/nvmm)
 >namely a host on the urtwn0's segment <-> tap/vether couldn't communicate.
 
 You cannot bridge wifi.
 
 To participate in a bridge, the interface needs to transmit with multiple
 MAC addresses, depending on what packet the sender belongs too.
 
 But in wifi, the MAC address is part of the client identification. The
 accesspoint won't accept packets from a different MAC address, even
 when the interface could chose one.
 
 wifi interfaces that know hostap mode do support multiple MAC
 addresses and there is also a modified wifi protocol (used for
 bridging access points) that allows such packets. But it's
 not supported by many regular clients.
 
 You may tunnel traffic through L2TP if you have another machine
 on the wired network. That's how I usually solve the problem when
 running guests on a wifi-only notebook. Another is to run guests
 in their own network and make the host a NAT router.