lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0400fa9ddfcb235aa6f80290f95fceb2d1a3ab12.camel@sipsolutions.net>
Date: Tue, 21 Oct 2025 16:27:04 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Aditya Kumar Singh <aditya.kumar.singh@....qualcomm.com>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH wireless-next] wifi: mac80211_hwsim: advertise
 puncturing feature support

On Tue, 2025-10-21 at 11:26 +0530, Aditya Kumar Singh wrote:
> On 10/20/2025 7:55 PM, Johannes Berg wrote:
> > On Fri, 2025-10-17 at 09:32 +0530, Aditya Kumar Singh wrote:
> > > If userspace provides a puncturing bitmap via the NL80211_ATTR_PUNCT_BITMAP
> > > attribute, the kernel with mac80211_hwsim driver currently rejects the
> > > command with the error: "driver doesn't support puncturing", because the
> > > driver does not advertise support for this feature.
> > > 
> > > At present, the following hwsim test cases utilize puncturing, but the
> > > bitmap is not sent to the kernel. Instead, the puncturing information is
> > > conveyed only through the beacon data:
> > >   * eht_5ghz_80mhz_puncturing_override_1
> > >   * eht_5ghz_80mhz_puncturing_override_2
> > >   * eht_5ghz_80mhz_puncturing_override_3
> > > 
> > > A future change in hostapd will begin configuring the puncturing bitmap
> > > explicitly, which will cause these test cases to fail unless the driver
> > > advertises support.
> > > 
> > > To address this, update mac80211_hwsim driver to advertise puncturing
> > > feature support.
> > 
> > This might be a good time to introduce better checks vs. what we have
> > now in hwsim_chans_compat(), which just uses the control channel rather
> > than any actual bandwidth/puncturing/etc.
> 
> Comparing those will be equivalent to comparing chandefs instead of 
> control channel right? And we already have a helper 
> cfg80211_chandef_compatible() to do that. So we just need to pass 
> chandefs and call that helper? Or hwsim should be more stricter and just 
> use cfg80211_chandef_identical() (this helper is not exported yet!) ?

I guess it shouldn't be either of those, since if you transmit at a
higher bandwidth, even if cfg80211_chandef_compatible() returns true, it
still shouldn't work? But that's also a rate scaling thing with the
bandwidth actually used.

>   >
> > It'd also make the tests actually test more. What do you think?
> 
> That's true. You want those changes also along with this patch or you'd 
> take this one as it is and take those separately?

Well given what we have now it doesn't really matter I guess, just
thought about it here because of the context.

johannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ