On Wed, 2009-02-18 at 10:13 -0500, Dan Williams wrote: > > /* cfg80211 requires this, and enforces 0..100 */ > > if (local->hw.flags & IEEE80211_HW_SIGNAL_UNSPEC) > > range->max_qual.level = 100; > > else if (local->hw.flags & IEEE80211_HW_SIGNAL_DBM) > > range->max_qual.level = -110; > > else > > range->max_qual.level = 0; > > > > Note the dBm branch -- clearly wrong. Did anyone care? Clearly not. > > Almost; I was partially wrong as well. The comments from wireless.h > imply that max_qual.level in the dBm case can be < 0. Remember that > these values are *s8*, and thus max_qual.level can be < 0 and greater > than -127 at least. Ok, I wasn't looking at the header file, only your explanation. > This of course doesn't allow RSSI-based levels of > 127, but whatever. > To get the definitive determination of RSSI vs. dBm for level, you use > (updated & IW_QUAL_DBM). > > The understanding of max_qual.level == 0 means dBm was probably from > conversations with Jean and that's apparently not borne out by the > evidence from wireless.h, unless there's something else I'm not reading. > > NM doesn't handle IW_QUAL_DBM. It should. > > > Therefore, here's what I'm going to do: > > 1) always set IW_QUAL_QUAL_INVALID, even in max_qual (fixes bug #1) > > 2) set max_qual.level to 0 for dBm instead of -110 (fixes bug #2) > > > > patch below. > > I think leaving max_qual.level == -110 is OK in mac80211 actually. It's > NM that's got the problem by not respecting IW_QUAL_DBM. Yeah, but now we've got three or four bugs that together mean we broke NM. We can't really wait for NM *and* wpa_supplicant to get their fixes... Should we just calculate a qual.qual value anyway? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
