Re: Missing link quality with wireless-testing

[Dan Williams <dcbw@redhat.com>]

On Wed, 2009-02-18 at 07:48 -0500, Dan Williams wrote:
> On Wed, 2009-02-18 at 14:33 +0200, Jouni Malinen wrote:
> > On Wed, Feb 18, 2009 at 07:18:43AM -0500, Dan Williams wrote:
> > 
> > > With WEXT, there are three ways to calculate pretty bars.  They *all*
> > > require max_qual values returned from the GIWRANGE handler, because
> > > otherwise you have no f**king clue what the upper or lower bounds are.
> > 
> > > QUAL.LEVEL in dBm
> > > --------------
> > > 
> > > Requires:
> > >   - max_qual.level == 0 (ie, dBm values)
> > 
> > That is an area where NM (= 0) and mac80211 (= -110) do not agree.
> 
> Then mac80211 is not conforming to WEXT...  unless it's setting
> IW_QUAL_DBM in the updated field, which it probably is.
> 
> Before we added IW_QUAL_DBM, the switch between dBm and RSSI was
> max_qual.level; if it was 0, level was in dBm, because no cards in use
> in Linux at that time could support a signal of more 0 dBm.  Thus, if it
> was over 0, the value was in RSSI.
> 
> Here's the relevant bit of wireless.h:
> 
>         /* Quality range (link, level, noise)
>          * If the quality is absolute, it will be in the range [0 ; max_qual],
>          * if the quality is dBm, it will be in the range [max_qual ; 0].
> 
> That doc never got updated for IW_QUAL_DBM either.

And yeah, the NM method isn't entirely consistent with this comment in
wext.h either; however, it's pretty unclear how to actually figure out
from max_qual whether the driver is reporting absolute or dBm unless you
use IW_QUAL_DBM.

Dan

> > > NM is probably fine here with qual == 0 because I doubt the GIWRANGE
> > > handler is returning a valid max_qual.qual > 0 anymore with Johannes'
> > > patch.  Could be wrong though.
> > 
> > Well, it is not fine, but not only for that reason.. max_qual.qual is
> > still set to 100 and the IW_QUAL_QUAL_INVALID is not used for it.
> > However, even if I set IW_QUAL_QUAL_INVALID and remove "quality" from
> > wpa_supplicant dbus interface, I still get NM showing perfect 100%
> > signal all the time regardless of how close to losing the connection the
> > card really is..
> > 
> > I gave up on trying to understand all the cases, but my assumption is
> > that the remaining issue is in the disagreement on max_qua.level for the
> > dBm case. However, I'm not sure whether fixing that would automatically
> > resolve the issues with wext (it might be enough for the current nl80211
> > version with wpa_supplicant from git head).
> 
> NM doesn't really handle IW_QUAL_DBM (added in WE-19).  Mainly because
> stuff worked without it, and it wasn't implemented in drivers until
> quite recently.  NM should handle IW_QUAL_DBM.
> 
> > > Ah right; the dbus interface shouldn't be appending "quality" to the
> > > dict if the driver doesn't provide valid quality (ie, max_qual.updated
> > > has the QUAL_INVALID bit set).  Same thing for noise and level.
> > 
> > The unknown values are not included anymore in wpa_supplicant 0.7.x.
> 
> Just pulled; it doesn't show up in master.  Do you have a separate git
> repo for 0.7.x?
> 
> Dan
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html