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
