linux-kernel - Re: [PATCH] wifi: mwifiex: Ensure all STA and AP use the same channel

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZtGnWC7SPHt7Vbbp@pengutronix.de>
Date: Fri, 30 Aug 2024 13:04:56 +0200
From: Sascha Hauer <s.hauer@...gutronix.de>
To: Kalle Valo <kvalo@...nel.org>
Cc: Brian Norris <briannorris@...omium.org>,
	Francesco Dolcini <francesco@...cini.it>,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH] wifi: mwifiex: Ensure all STA and AP use the same channel

On Fri, Aug 30, 2024 at 12:49:34PM +0300, Kalle Valo wrote:
> Sascha Hauer <s.hauer@...gutronix.de> writes:
> 
> > The mwifiex chips support simultaneous Accesspoint and station mode,
> > but this only works when all are using the same channel. The downstream
> > driver uses ECSA which makes the Accesspoint automatically switch to the
> > channel the station is going to use.  Until this is implemented in the
> > mwifiex driver at least catch this situation and bail out with an error.
> > Userspace doesn't have a meaningful way to figure out what went wrong,
> > so print an error message to give the user a clue.
> >
> > Without this patch the driver would timeout on the
> > HostCmd_CMD_802_11_ASSOCIATE command when creating a station with a
> > channel different from the one that an existing accesspoint uses.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@...gutronix.de>
> > Cc: stable@...r.kernel.org
> 
> Does this mean that iface combination definitions are wrong? For example:
> 
> static const struct
> ieee80211_iface_combination mwifiex_iface_comb_ap_sta_drcs = {
> 	.limits = mwifiex_ap_sta_limits,
> 	.num_different_channels = 2,
> 	.n_limits = ARRAY_SIZE(mwifiex_ap_sta_limits),
> 	.max_interfaces = MWIFIEX_MAX_BSS_NUM,
> 	.beacon_int_infra_match = true,
> };

I wasn't aware of DRCS as it's disabled by default in the mwifiex
driver. From a quick test I can say that indeed with DRCS two channels
are supported. It seems we have to relax the same channel enforcement
when DRCS is enabled.

This brings up the question why DRCS is disabled by default. Wouldn't it
make sense to always enable it when available?

Related: num_different_channels is exposed to userspace, but outside the
MAC80211 layer there is nothing in the kernel that enforces this
restriction.  Am I missing something or is this just an open patch
opportunity?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |