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
like this:

 * 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
   changes cell.

 * 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
   ieee80211_nodes.

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.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933