On Wed, Feb 18, 2009 at 05:57:39AM +0100, Marcel Holtmann wrote: > > Would setting qual->updated |= IW_QUAL_QUAL_INVALID; work for you? If > > some app doesn't handle that, it's totally, completely broken. > > does wpa_supplicant handle this value correctly? I actually never > checked that. No, it doesn't use qual->updated at all. Then again, neither does it rely on qual->qual either. The signal level (qual->level) is used first and only if that is not available, qual->qual will be used in sorting the results. > However I think it is bad practice to abandon a value that has been > previously set by mac80211 and remove it without any further warning. If > a driver never set the value before it is a different story than > mac80211 deciding to not set it any more from one kernel version to > another one. It would be interesting to know which applications depend only on qual->qual values being there and cannot use qual->level. Anyway, I would agree that it would be reasonable to fill in something in the qual->qual field for now. It should be enough to do this in the wext compat code (i.e., not changing anything in mac80211 and only touching #ifdef CONFIG_WIRELESS_EXT blocks in net/wireless/scan.c). This would provide somewhat useful value for applications that depend on a value that was not really guaranteed to be there in the first place. I think I would include the IW_QUAL_QUAL_INVALID flag anyway and just target the broken apps with this workaround. -- Jouni Malinen PGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
