[PATCH] wifi: mac80211: make VHT opmode NSS ignore a debug message

[PATCH] wifi: mac80211: make VHT opmode NSS ignore a debug message

[Johannes Berg]

From: Johannes Berg <johannes.berg@intel.com>

There's no need to always print it, it's only useful for
debugging specific client issues. Make it a debug message.

Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/linux-wireless/20250529070922.3467-1-pmenzel@molgen.mpg.de/
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 net/mac80211/vht.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index c5c5d16ed6c8..b099d79e8fbb 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -672,8 +672,9 @@ u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
 				sta_opmode.changed |= STA_OPMODE_N_SS_CHANGED;
 			}
 		} else {
-			pr_warn_ratelimited("Ignoring NSS change in VHT Operating Mode Notification from %pM with invalid nss %d",
-					    link_sta->pub->addr, nss);
+			sdata_dbg(sdata,
+				  "Ignore NSS change to invalid %d in VHT opmode notif from %pM",
+				  nss, link_sta->pub->addr);
 		}
 	}
 
-- 
2.50.0

Re: [PATCH] wifi: mac80211: make VHT opmode NSS ignore a debug message

[Paul Menzel]

Dear Johannes,


Thank you for your patch, and sorry for not replying in the other thread.

Am 08.07.25 um 12:58 schrieb Johannes Berg:
> From: Johannes Berg <johannes.berg@intel.com>
> 
> There's no need to always print it, it's only useful for
> debugging specific client issues. Make it a debug message.

Excuse my ignorance, but I wonder if it’s a firmware bug (of the access 
point), if this situation occurs?

Also, I do have a problem with that Telekom Speedport 3, that sometimes 
– despite still connected Wi-Fi – no network connection is possible, and 
re-connecting fixes it. It happens much later to the message, so I 
assume it’s unrelated, but no warnings would give me more confidence 
into the Telekom router.

> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Link: https://lore.kernel.org/linux-wireless/20250529070922.3467-1-pmenzel@molgen.mpg.de/
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
>   net/mac80211/vht.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> index c5c5d16ed6c8..b099d79e8fbb 100644
> --- a/net/mac80211/vht.c
> +++ b/net/mac80211/vht.c
> @@ -672,8 +672,9 @@ u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
>   				sta_opmode.changed |= STA_OPMODE_N_SS_CHANGED;
>   			}
>   		} else {
> -			pr_warn_ratelimited("Ignoring NSS change in VHT Operating Mode Notification from %pM with invalid nss %d",
> -					    link_sta->pub->addr, nss);
> +			sdata_dbg(sdata,
> +				  "Ignore NSS change to invalid %d in VHT opmode notif from %pM",
> +				  nss, link_sta->pub->addr);

As with my original patch, would printing the current “NSS value” be 
useful? At least for me, who does not know how to get that value from a 
running system.

>   		}
>   	}
>   


Kind regards,

Paul

Re: [PATCH] wifi: mac80211: make VHT opmode NSS ignore a debug message

[Johannes Berg]

Hi,

> > There's no need to always print it, it's only useful for
> > debugging specific client issues. Make it a debug message.
> 
> Excuse my ignorance, but I wonder if it’s a firmware bug (of the access 
> point), if this situation occurs?
> 
> Also, I do have a problem with that Telekom Speedport 3, that sometimes 
> – despite still connected Wi-Fi – no network connection is possible, and 
> re-connecting fixes it. It happens much later to the message, so I 
> assume it’s unrelated, but no warnings would give me more confidence 
> into the Telekom router.

Either way it's a bug on the other side. It's basically saying that it
wants to change the NSS (number of spatial streams) to a higher number
than it ever advertised support for.

If you get it on the client side while connected to an AP then yeah,
that seems like an AP firmware bug.

It doesn't seem that it'd be related in this case. Though I guess with
my patch we'd stop printing the message and erroneously give you more
confidence ;-)

It just doesn't seem useful to print the message - there's nothing you
can do about it, it basically means we ignore it and keep transmitting
with a lower NSS (which is fine anyway, it's subject to rate control and
the AP cannot have any expectation on how many streams we really use),
and so it's not actionable to the user in any way.

> > -			pr_warn_ratelimited("Ignoring NSS change in VHT Operating Mode Notification from %pM with invalid nss %d",
> > -					    link_sta->pub->addr, nss);
> > +			sdata_dbg(sdata,
> > +				  "Ignore NSS change to invalid %d in VHT opmode notif from %pM",
> > +				  nss, link_sta->pub->addr);
> 
> As with my original patch, would printing the current “NSS value” be 
> useful? At least for me, who does not know how to get that value from a 
> running system.

We could, though I later realized you printed the wrong value (if
anything, should have "link_sta->capa_nss"), but it's easy to tell what
that value is from the association and/or beacon, so it didn't really
seem all that useful. Perhaps more to be said for simply disconnecting
in this case in strict mode, or something, so it's noticeable to people
working on this/testing it.

johannes

Re: [PATCH] wifi: mac80211: make VHT opmode NSS ignore a debug message

[Paul Menzel]

Dear Johannes,


Am 08.07.25 um 13:42 schrieb Johannes Berg:

>>> There's no need to always print it, it's only useful for
>>> debugging specific client issues. Make it a debug message.
>>
>> Excuse my ignorance, but I wonder if it’s a firmware bug (of the access
>> point), if this situation occurs?
>>
>> Also, I do have a problem with that Telekom Speedport 3, that sometimes
>> – despite still connected Wi-Fi – no network connection is possible, and
>> re-connecting fixes it. It happens much later to the message, so I
>> assume it’s unrelated, but no warnings would give me more confidence
>> into the Telekom router.
> 
> Either way it's a bug on the other side. It's basically saying that it
> wants to change the NSS (number of spatial streams) to a higher number
> than it ever advertised support for.
> 
> If you get it on the client side while connected to an AP then yeah,
> that seems like an AP firmware bug.
> 
> It doesn't seem that it'd be related in this case. Though I guess with
> my patch we'd stop printing the message and erroneously give you more
> confidence ;-)
> 
> It just doesn't seem useful to print the message - there's nothing you
> can do about it, it basically means we ignore it and keep transmitting
> with a lower NSS (which is fine anyway, it's subject to rate control and
> the AP cannot have any expectation on how many streams we really use),
> and so it's not actionable to the user in any way.

In some cases, people can contact the router manufacturer asking to look 
into their firmware.

>>> -			pr_warn_ratelimited("Ignoring NSS change in VHT Operating Mode Notification from %pM with invalid nss %d",
>>> -					    link_sta->pub->addr, nss);
>>> +			sdata_dbg(sdata,
>>> +				  "Ignore NSS change to invalid %d in VHT opmode notif from %pM",
>>> +				  nss, link_sta->pub->addr);
>>
>> As with my original patch, would printing the current “NSS value” be
>> useful? At least for me, who does not know how to get that value from a
>> running system.
> 
> We could, though I later realized you printed the wrong value (if
> anything, should have "link_sta->capa_nss"),

Sorry for mixing this, and thank you for spotting this.

> but it's easy to tell what that value is from the association and/or
> beacon, so it didn't really seem all that useful. Perhaps more to be
> said for simply disconnecting in this case in strict mode, or
> something, so it's noticeable to people working on this/testing it.
Maybe. I have never heard of strict mode. ;-) For the ignorant like me, 
having more details in the log message would help, as it’s not so easy 
for me to capture and interpret the beacon. ;-)

Anyway, you are the expert, so the patch looks fine.


Kind regards,

Paul

Re: [PATCH] wifi: mac80211: make VHT opmode NSS ignore a debug message

[Johannes Berg]

Hi,

> > It just doesn't seem useful to print the message - there's nothing you
> > can do about it, it basically means we ignore it and keep transmitting
> > with a lower NSS (which is fine anyway, it's subject to rate control and
> > the AP cannot have any expectation on how many streams we really use),
> > and so it's not actionable to the user in any way.
> 
> In some cases, people can contact the router manufacturer asking to look 
> into their firmware.

Yeah, maybe? But like I said, it also shouldn't have much consequences -
it's perhaps saying "I now can receive up to 8 streams" but only
supports 4, so that's physically impossible. Maybe we could allow 4 in
that case, but right now we're careful and just ignore that instruction.
And in most cases the client only will have two anyway. Not that I know
the numbers for your case :)

> > but it's easy to tell what that value is from the association and/or
> > beacon, so it didn't really seem all that useful. Perhaps more to be
> > said for simply disconnecting in this case in strict mode, or
> > something, so it's noticeable to people working on this/testing it.
> Maybe. I have never heard of strict mode. ;-)

You probably wouldn't want to use it :) but we want to behave more
strictly when we're testing with APs etc. before they ship to customers,
we can get these kinds of issues fixed.

>  For the ignorant like me, 
> having more details in the log message would help, as it’s not so easy 
> for me to capture and interpret the beacon. ;-)

Well, if we made each of these messages tell a story about how to figure
out what could be wrong, that'd probably be too verbose ;-)

You can see the values with just

$ iw wlan0 scan dump

and looking for your AP's data. You'd have to understand that too, but
honestly just knowing say "8 > 4" doesn't really help much either, you
still have to understand where the 4 comes from and that requires
looking at the details like that.


Anyway ... I'll just put in this patch I think :)

johannes