Subject: Re: atheros cards - no signal level info or am i doing something wrong?
To: None <current-users@NetBSD.org>
From: David Young <firstname.lastname@example.org>
Date: 01/16/2004 04:25:18
On Thu, Jan 15, 2004 at 08:58:54AM -0800, Sam Leffler wrote:
> On Wednesday 14 January 2004 09:22 am, David Young wrote:
> > On Wed, Jan 14, 2004 at 11:43:22AM +0100, Wojciech Puchar wrote:
> > > i started atheros card (ath driver) fine. it works OK but receiver signal
> > > level info gives always 0dB signal level and -149dB signal quality and
> > > noise.
> > -149 noise is an artifact of early mistakes in programming wiconfig; you
> > can interpret it as "0". AFAIK, the Atheros hardware does not provide
> > any noise figure. I don't precisely know why the signal level is 0,
> > but see below.
> There is code around to collect rssi from received frames and use it to
> calculate a "receiver signal level". But as David says interpreting it based
> on Prism operating parameters is going to be confusing. If you look at the
> madwifi code for Linux (http://madwifi.sourceforge.net) you'll find code to
> approximately convert from the rssi (given as dbm relative to the noise
> floor) to the prism-style signal quality metrics. I've got this code in
> uncommitted changes for FreeBSD.
> > > is it bug or lack of code?
> > It depends what mode you run the interface in. You will probably not
> > get an intelligible signal level report in ad hoc mode or in AP mode.
> The numbers are real regardless of mode. The question is what to return for a
> single value when operating in adhoc or ap operation. The existing code
> averages over all stations when asked for a signal quality and operating in
> adhoc or ap mode.
Someday I would like for such per-node info to be available through a
character device which provides a message interface between a wireless
interface and userland. Daemons and utilities will use it for stuff
* Inter-Access Point Protocol (IAPP) daemon for roaming. Works w/ other
IAPP daemons to ensure bridging/IP-forwarding tables are updated
and auth/accounting context is brought over when a mobile unit
* Authentication: a daemon intervenes in authentication exchanges,
contacting a RADIUS server and sending yay/nay response back to kernel.
* AP scanning: an interface will dump an ieee80211_nodes
to the character device on demand; it will send notification of new
Something else I want to see, which is a little more controversial,
is per-client/peer virtual interfaces. There are lots of reasons why
they are a good idea, but I will not go into that here.
David Young OJC Technologies
email@example.com Urbana, IL * (217) 278-3933