Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux