From owner-freebsd-net@FreeBSD.ORG Fri Sep 25 02:55:12 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D676B106568D for ; Fri, 25 Sep 2009 02:55:12 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8A9A18FC19 for ; Fri, 25 Sep 2009 02:55:12 +0000 (UTC) Received: from Macintosh-4.local ([10.0.0.198]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n8P2tB9Z079637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Sep 2009 19:55:11 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4ABC310F.7080900@freebsd.org> Date: Thu, 24 Sep 2009 19:55:11 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: David Horn References: <25ff90d60909241144i321c39bdj71e1d1b7e0ba51e8@mail.gmail.com> In-Reply-To: <25ff90d60909241144i321c39bdj71e1d1b7e0ba51e8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: wpa_supplicant signal quality vs level X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 02:55:12 -0000 David Horn wrote: > I have noticed that 'wpa_cli scan_results' always reported a signal > level of 0 for every bssid found during a scan. I found this a bit > odd (especially since ifconfig wlan0 list scan reported good signal > level data) > > FreeBSD 8.0-RC1 r197417 amd64 > > Looking at the /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c > source, I found: > > in wpa_driver_bsd_get_scan_results() > > wsr->qual = sr->isr_rssi; > wsr->level = 0; /* XXX? */ > > This hardcodes the signal level to 0, and sets the signal quality to > the rssi value. > > Looking around at the source, it seems that wpa_supplicant does not > ever use the quality variable, but instead looks at the level variable > in wpa_scan_result_compar (). Correct. There is no notion of signal _quality_ in freebsd because it's a nebulous value defined by each vendor using a heuristic algorithm that reflects their idea of what "good" is. Because various parts of the code use qual to compare the signal strength of stations we use the one suitable value we do have. > > In an attempt to try to figure out what signal level vs signal quality > in wpa_supplicant context means, I found this: > http://lists.shmoo.com/pipermail/hostap/2006-December/014831.html, and > a feb-2009 change to scan_helpers.c (which drivers_freebsd.c seems to > be partially based upon) > http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=e1b525c3560614cc56c85b7d060f540900c4da34 > > So, it seems that some wpa_supplicant drivers use quality, and some > use level. Since quality(wsr->qual) does not seem to be used in > current wpa_supplicant in freebsd, should it instead look like ?: > (attached as an SVN diff with some debug as well) > > wsr->ssid_len = sr->isr_ssid_len; > wsr->freq = sr->isr_freq; > wsr->noise = sr->isr_noise; > - wsr->qual = sr->isr_rssi; > - wsr->level = 0; /* XXX? */ > + wsr->qual = 0; /* XXX? */ > + wsr->level = sr->isr_rssi; > wsr->caps = sr->isr_capinfo; > wsr->maxrate = getmaxrate(sr->isr_rates, sr->isr_nrates); > vp = ((u_int8_t *)sr) + sr->isr_ie_off; > > > Should we just set qual to 0, or should we set qual to > rssi/rssi_max*100 (if we can determine rssi_max for a particular wlan > interface) > > In any case, do you want me to file a PR on this ? I believe this issue is purely cosmetic in that you see 0's in the scan results display. If you want to fill that data in with something be my guest but unless the values correspond to the data actually used to make decision it's just going to cause confusion. It might be simpler to just strip the value from the scan results print out. Sam