NetBSD Problem Report #60055

From www@netbsd.org  Wed Mar  4 12:02:34 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R13" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 1EC011A9239
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  4 Mar 2026 12:02:34 +0000 (UTC)
Message-Id: <20260304120233.2510A1A923C@mollari.NetBSD.org>
Date: Wed,  4 Mar 2026 12:02:33 +0000 (UTC)
From: imuwoto@gmail.com
Reply-To: imuwoto@gmail.com
To: gnats-bugs@NetBSD.org
Subject: bridge doesn't work well with urtwn(4)
X-Send-Pr-Version: www-1.0
X-From4GNATS: "imuwoto@gmail.com via gnats" <gnats-admin@NetBSD.org>

>Number:         60055
>Category:       kern
>Synopsis:       bridge doesn't work well with urtwn(4)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 04 12:05:00 +0000 2026
>Last-Modified:  Wed Mar 04 20:20:04 +0000 2026
>Originator:     YAMAMOTO Takashi
>Release:        NetBSD current
>Organization:
>Environment:
amd64
>Description:
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.

* almost same configuration using wm0 instead of urtwn0 worked well.
* urtwn0 itself works well if i use it without bridge.

>How-To-Repeat:

>Fix:

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
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 ("imuwoto@gmail.com 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.

From: Takashi Yamamoto <imuwoto2@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	imuwoto@gmail.com
Subject: Re: kern/60055: bridge doesn't work well with urtwn(4)
Date: Wed, 4 Mar 2026 22:10:22 +0900

 hi,

 On Wed, Mar 4, 2026 at 9:50=E2=80=AFPM Michael van Elst via gnats
 <gnats-admin@netbsd.org> wrote:
 >
 > The following reply was made to PR kern/60055; it has been noted by GNATS=
 .
 >
 > From: mlelstv@serpens.de (Michael van Elst)
 > To: gnats-bugs@netbsd.org
 > 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 ("imuwoto@gmail.com 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 communica=
 te.
 >
 >  You cannot bridge wifi.
 >
 >  To participate in a bridge, the interface needs to transmit with multipl=
 e
 >  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.
 >

 thank you for explanation.

 the following sentence in bridge(4) made me think it was supposed to work.
 what does it actually mean?

      A bridge can be used to provide several services, such as a simple
      802.11-to-Ethernet bridge for wireless hosts, and traffic isolation.

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

 gnats-admin@NetBSD.org ("Takashi Yamamoto via gnats") writes:

 > the following sentence in bridge(4) made me think it was supposed to work.
 > what does it actually mean?
 > 
 >      A bridge can be used to provide several services, such as a simple
 >      802.11-to-Ethernet bridge for wireless hosts, and traffic isolation.

 It probably refers to running an interface as access point (hostap mode)
 for other wireless hosts.

Home	PR Database Search