Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
Hi Dan, 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... iirc, we currently we hardcode wext in NM code. How about adding a keyfile config that users could use to switch to nl80211 until we feel confident that it's good enough for everyone? commit d27df100b587dd95f3256a8baf9db0c5d4380089 in wpa_supplicant allows you to do that by editing the service file. that is funny, when I asked for a global command line switch for choosing a different driver, the argument was that the application adding the interface is suppose to do it by itself. Now we can do it in the service file. Never the less ConnMan got its own switch to choose which driver will be used. Does help a lot in testing and is way easier since you don't have to restart wpa_supplicant all the time. In reality, NM upstream will just switch over one day and distros that use shitty and/or proprietary drivers will need to either (a) fix them, or (b) patch NM to use wext locally. That's how progress gets made. my goal is to run completely without wext driver in wpa_supplicant and WEXT disabled in the kernel. However so far it caused some issues. I think that most of them got fixed, but I never got around fully verifying it. In the Moblin 2.0 timeframe we had for some time nl80211,wext as driver selection, but unfortunately that never worked out. I hope for Moblin 2.2 we are able to get this up and running. One big missing piece is of course a new stable release of wpa_supplicant that contains all the fixes. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
On Mon, Nov 02, 2009 at 11:40:33AM -0800, Dan Williams wrote: 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... iirc, we currently we hardcode wext in NM code. How about adding a keyfile config that users could use to switch to nl80211 until we feel confident that it's good enough for everyone? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
On Mon, 2009-11-09 at 13:50 +0100, Alexander Sack wrote: 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... iirc, we currently we hardcode wext in NM code. How about adding a keyfile config that users could use to switch to nl80211 until we feel confident that it's good enough for everyone? commit d27df100b587dd95f3256a8baf9db0c5d4380089 in wpa_supplicant allows you to do that by editing the service file. johannes signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
Hi Johannes, 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... iirc, we currently we hardcode wext in NM code. How about adding a keyfile config that users could use to switch to nl80211 until we feel confident that it's good enough for everyone? commit d27df100b587dd95f3256a8baf9db0c5d4380089 in wpa_supplicant allows you to do that by editing the service file. that is funny, when I asked for a global command line switch for choosing a different driver, the argument was that the application adding the interface is suppose to do it by itself. Now we can do it in the service file. Never the less ConnMan got its own switch to choose which driver will be used. Does help a lot in testing and is way easier since you don't have to restart wpa_supplicant all the time. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
On Mon, 2009-11-09 at 14:09 +0100, Marcel Holtmann wrote: Hi Johannes, 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... iirc, we currently we hardcode wext in NM code. How about adding a keyfile config that users could use to switch to nl80211 until we feel confident that it's good enough for everyone? commit d27df100b587dd95f3256a8baf9db0c5d4380089 in wpa_supplicant allows you to do that by editing the service file. that is funny, when I asked for a global command line switch for choosing a different driver, the argument was that the application adding the interface is suppose to do it by itself. Now we can do it in the service file. Never the less ConnMan got its own switch to choose which driver will be used. Does help a lot in testing and is way easier since you don't have to restart wpa_supplicant all the time. In reality, NM upstream will just switch over one day and distros that use shitty and/or proprietary drivers will need to either (a) fix them, or (b) patch NM to use wext locally. That's how progress gets made. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
On Mon, 2009-11-02 at 11:40 -0800, Dan Williams wrote: -- 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. Are you sure? Weird ... we've had it set at -110 practically forever in mac80211-based drivers. 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. We do that -- I think the problem here is not the max_qual value but that you're not getting a qual value since -Dnl80211 doesn't construct that. What effectively happens is that you're trying to discover device capabilities based on wext, but then use the information provided by nl80211, which while effectively the same information comes in a different format. When using nl80211, you really should discover whether the device uses dBm or RSSI values by the kind of attribute it gave you in the scan result. So IMHO the solution is to move all that what kind of crap am I getting detection into driver_wext and only export the sanitised values from wpa_supplicant. johannes PS: Please trim your quoting, it should be easy enough to kill everything after your signature. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
On Mon, 02 Nov 2009 17:02:44 -0800 Dan Williams d...@redhat.com wrote: On Mon, 2009-11-02 at 23:53 +, Brian Morrison wrote: On Tue, 03 Nov 2009 01:07:22 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: 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. It appears as kernel developers want to drop quality calculations altogether, and report everything in dBms (right?) But quality does not necessarily track signal level. Consider the case where a second AP is on the same frequency but weaker than the AP that is associated with. The quality of the connection is the difference in signal levels (roughly the SNR) which is not the same as the signal level of the stronger AP. You're only associated to one AP at a time on the same wlan device. Thus whatever signal quality any other AP has doesn't matter. The only signal level or quality that matters is the one for the link through which your packets go. When the driver roams APs, the quality should update to reflect the signal strength and quality of the new AP, no matter what channel it's on. I'm only talking about a single AP Dan, but if another AP is transmitting on the same frequency and there is a simultaneous transmission with the associated AP then the quality is poorer than if there is clear air. CCA doesn't always work you know. The quality metric should be returned by the modem, RSSI is usually not calculated by the modem but is instead generated from signal levels in various parts of the receiver. I'm only suggesting that things may not be what they seem. -- Brian Morrison I am not young enough to know everything Oscar Wilde ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
On Mon, 2009-11-02 at 11:40 -0800, Dan Williams wrote: 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... Glad to hear that! I use driver_nl80211 and I have 3 problems. 1 - noise levels, this what I reported here. 2 - problems with wpa_supplicant that does no deauth on disconnect, this can be easily worked around in supplicant code, but I feel some disagreement between kernel and wpa_supplicant developers. 3 - seems that ibss is broken (even with all recently posted patches on linux-wireless, wpa_supplicant still hangs while it attempts to create the network. In fact I only tested creation of the network, not if anybody could join it. Speaking of joing the IBSS, NM did forever support the WPA encryption, however, its isn't set in the beacon that is broadcast (in fact I only see probe requests, not real beacons...) Thus any attempt to join such network results in NM asking for wep keys. It would be very nice to have WPA/2 IBSS, as this is the only real encryption possible. 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. This is very good point, a question for kernel developers, why it was set as such? How about setting it to ? 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. It appears as kernel developers want to drop quality calculations altogether, and report everything in dBms (right?) This is also a consistent I think. 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. It does, but driver_nl80211 doesn't use wext that is. Also a recent conversation on linux-wireless indicated that noise level is a property of the wireless card, so I think we won't see them in scan results any time soon. Best regards, Maxim Levitsky ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
On Tue, 03 Nov 2009 01:07:22 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: 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. It appears as kernel developers want to drop quality calculations altogether, and report everything in dBms (right?) But quality does not necessarily track signal level. Consider the case where a second AP is on the same frequency but weaker than the AP that is associated with. The quality of the connection is the difference in signal levels (roughly the SNR) which is not the same as the signal level of the stronger AP. -- Brian Morrison I am not young enough to know everything Oscar Wilde ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
On Tue, 2009-11-03 at 01:07 +0200, Maxim Levitsky wrote: On Mon, 2009-11-02 at 11:40 -0800, Dan Williams wrote: 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... Glad to hear that! I use driver_nl80211 and I have 3 problems. 1 - noise levels, this what I reported here. 2 - problems with wpa_supplicant that does no deauth on disconnect, this can be easily worked around in supplicant code, but I feel some disagreement between kernel and wpa_supplicant developers. 3 - seems that ibss is broken (even with all recently posted patches on linux-wireless, wpa_supplicant still hangs while it attempts to create the network. In fact I only tested creation of the network, not if anybody could join it. Speaking of joing the IBSS, NM did forever support the WPA encryption, however, its isn't set in the beacon that is broadcast (in fact I only see probe requests, not real beacons...) Thus any attempt to join such network results in NM asking for wep keys. That's a mac80211/supplicant problem, I believe. NM just sends the config to the supplicant, and given that config, it's the supplicant and driver's problem to set up the right network. You can see the config that NM sends in /var/log/messages or /var/log/daemon.log, wherever your distro directs the 'daemon' syslog facility. Dan It would be very nice to have WPA/2 IBSS, as this is the only real encryption possible. 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. This is very good point, a question for kernel developers, why it was set as such? How about setting it to ? 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. It appears as kernel developers want to drop quality calculations altogether, and report everything in dBms (right?) This is also a consistent I think. 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. It does, but driver_nl80211 doesn't use wext that is. Also a recent conversation on linux-wireless indicated that noise level is a property of the wireless card, so I think we won't see them in scan results any time soon. Best regards, Maxim Levitsky ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
On Mon, 2009-11-02 at 23:53 +, Brian Morrison wrote: On Tue, 03 Nov 2009 01:07:22 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: 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. It appears as kernel developers want to drop quality calculations altogether, and report everything in dBms (right?) But quality does not necessarily track signal level. Consider the case where a second AP is on the same frequency but weaker than the AP that is associated with. The quality of the connection is the difference in signal levels (roughly the SNR) which is not the same as the signal level of the stronger AP. You're only associated to one AP at a time on the same wlan device. Thus whatever signal quality any other AP has doesn't matter. The only signal level or quality that matters is the one for the link through which your packets go. When the driver roams APs, the quality should update to reflect the signal strength and quality of the new AP, no matter what channel it's on. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Incorrect signal levels reported using wpa_supplicant's driver_nl80211
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? 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) * 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 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
