linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: "hostap@lists.shmoo.com" <hostap@lists.shmoo.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	networkmanager-list <networkmanager-list@gnome.org>
Subject: Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
Date: Mon, 02 Nov 2009 11:40:33 -0800	[thread overview]
Message-ID: <1257190833.1027.4.camel@localhost.localdomain> (raw)
In-Reply-To: <1256953837.9681.13.camel@maxim-laptop>

On Sat, 2009-10-31 at 03:50 +0200, Maxim Levitsky wrote:
> Sorry for cross-posting, but this issue really spans all three systems.
> 
> I anylized why I get 100% quality on all access points except currently
> connected, when I used driver_nl80211 of wpa_supplcant.
> 
> First, when NetworkManager plans to switch to this driver?

Soon.  We've got some patches for this, but we'll also need tons of
testing.  The WEXT stuff is pretty baked while nl80211 is still under
some flux.  But of course the only way we bake nl80211 is by switching
to it...

> For me it gives me faster association speeds, especially when I toggle
> wireless with rfkill button.
> 
> 
> this is what happens on the kernel side:
> --> n80211 encodes only dBm data. It does so in, nl80211_send_bss.
> 	(or it can encode unspecified data, which has little use...)
> 
> --> kernel also gives maximum ranges in, cfg80211_wext_giwrange, which is used by NM:
> 	range->max_qual.updated = IW_QUAL_NOISE_INVALID | IW_QUAL_DBM | IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED ;
> 	range->max_qual.level = -110;
> 	range->max_qual.qual = 70;
> Thus it reports that it can't report noise.
> 
> 
> driver_nl80211 side:
> 
> --> sends data as is, done in bss_info_handler:
> 	r->level = nla_get_u32(bss[NL80211_BSS_SIGNAL_MBM]);
> 	r->level /= 100; /* mBm to dBm */
> 	r->flags |= WPA_SCAN_LEVEL_DBM | WPA_SCAN_QUAL_INVALID;
> 
> Again explicitly says that has no quality data, sends only dBm or unspecified data;
> 
> 
> 
> NM side:
> 
> --> three strategies used (in wireless_qual_to_percent)
> 	--> quality: (used with driver_wext), not reported by nl80211
> 
> 	--> dbm: used only if:
> 		* valid and zero max_qual->level (but now set to -110....) 

IIRC non-zero max_qual->level was the indication that the driver wanted
to use RSSI, not dBm.  Since the real "max" dBm is around 0 (ie, that's
the highest signal strength you'll ever really see), max_qual->level
meant the driver was reporting signal strength in dBm.  max_qual->level
== -110 is kinda wrong, because that's the _minimum_ level, not the max.
The noise floor is almost always around -100 dBm so setting
max_qual->level is pretty useless.

This is *exactly* why 'qual' is there: so that the driver itself can
figure out what the hell it's signal level is, and so that NM doesn't
have to go around assuming stuff.

For WEXT reporting, mac80211 should really be constructing a 'qual'
instead of leaving it 0.  Then we don't have ambiguities with dBm, RSSI,
unspec, etc.

Dan

> 		* valid level (OK)
> 		* valid positive max_qual->noise OR valid positive current noise (noise set to invalid and not reported even by my driver...)
> 
> 	--> RSSI: (device reports numbers from 0 to max_qual.level):
> 		* nonzero valid max_qual->level, and it is assumed to be positive too...
> 		* valid level
> 		
> 
> currently RSSI path is taken and results in 100% quality.
> 
> 
> I think that dBm strategy should be revised, and in addtion to that.
> 
> Of course whole NM currently depends on WEXT, for exmple it would get signal level for current AP via WEXT, and thus use quality level
> as reported by driver. 
> 
> Thus there are differences between NM dBm quality calculation and driver ones, and therefore NM will report different quality levels... sigh...
> 
> 
> Best regards,
> 	Maxim Levitsky
> 
> 
> PS: I want signal quality bars back in NM....
> 
> --
> 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


  reply	other threads:[~2009-11-02 19:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-31  1:50 Incorrect signal levels reported using wpa_supplicant's driver_nl80211 Maxim Levitsky
2009-11-02 19:40 ` Dan Williams [this message]
2009-11-02 23:07   ` Maxim Levitsky
2009-11-03  0:53     ` Dan Williams
2009-11-03  8:06   ` Johannes Berg
2009-11-09 12:50   ` Alexander Sack
2009-11-09 12:54     ` Johannes Berg
2009-11-09 13:09       ` Marcel Holtmann
2009-11-10  6:27         ` Dan Williams
2009-11-10  8:41           ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1257190833.1027.4.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=hostap@lists.shmoo.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    --cc=networkmanager-list@gnome.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).