Received-SPF: pass (google.com: domain of linux-wireless+bounces-4793-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <bb884b84dbaa1c97f9d3a1e610f98ec6e069a706.camel@sipsolutions.net>
Subject: Re: BE200 - 6.5 backports - disabled EHT issue
From: Johannes Berg <johannes@sipsolutions.net>
To: Janusz Dziedzic <janusz.dziedzic@gmail.com>, linux-wireless
	 <linux-wireless@vger.kernel.org>
Date: Fri, 15 Mar 2024 19:04:07 +0100
In-Reply-To: <CAFED-j=3_xLuJFp5R_gThMtv2C6r6WzRxzrY3_wjFTn=XJQLwg@mail.gmail.com>
References: 
	<CAFED-j=3_xLuJFp5R_gThMtv2C6r6WzRxzrY3_wjFTn=XJQLwg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

>=20
> I see this one do this:
>  if (!ieee80211_verify_sta_eht_mcs_support(sdata, sband, eht_oper))
>       *conn_flags |=3D IEEE80211_CONN_DISABLE_EHT;
>=20
> Testing on openwrt and using backports.
> Is there some patch I can easy cherry-pick to fix it?
> So far just disable ieee80211_verify_sta_eht_mcs_support() check and
> BE200 works in EHT mode correctly.

Then either the code there or the AP is broken?

That function checks that the client supports the MCSes that the AP
requires. If it lets you connect without them, then it's broken. If the
checks there are wrong, the code is broken :)

I guess you can capture the assoc response frame and we can check
manually.

johannes