[collectd] Wireless plugin patch for collectd 3.11.5

[Florian Forster]

Hi again,

On Sat, Sep 01, 2007 at 02:44:13PM +0200, Silvio Klaic wrote:
> There are two models for conversing dBm to percentage, quadratic and
> linear.

my point exactly: With power (i. e. dBm) you know where you stand. Your
conversion function assumes -50dBm to be 100%, that article about the
ipw2000 driver assumes -20dBm as 100%, so confusion is inevitable.

Please don't get me wrong, I don't want to badmouth your code - I'm just
thinking aloud what the best solution would be..

I've been reading a little in the sourcecode of the higher level
wireless stuff in the Linux kernel (the part the takes care of
/proc/net/wireless) and the wireless-tools package. It turns out that
you can get all these statistics using ioctl's. I'll look into that
sometime and hopefully ditch all that /proc-parsing crap.

Anyway, judging from the code there's a bitmask bundled with the
`quality' structure with tells you if the driver actually provides these
values and if they're in dBm or not. Also, you can get a `range' which
basically tells you the maximum value for signal and noise levels -
`iwconfig' displays them for example.
The genius who came up with the /proc/net/wireless layout, however,
didn't include any of this. The dot behind the values tells you that
this value has been updated since the file was last read, which is oh so
useful. And the status is ``driver dependent'', i. e. useless.

You can get some wireless `event' using netlink sockets, too - but that
isn't documented of course..

> I'm more interested where are values returned from /proc/net/wireless
> in negative form. As far I know, all new linux distribution (to be
> more precisely kernel versions 2.4.x and above) display values from
> /proc/net/wireless in range 0-255.

The Linux sources I happen to have at hand (version 2.6.15) do the
following:
-- 8< --
 seq_printf(seq, "%6s: %04x  %3d%c  %3d%c  %3d%c  %6d %6d %6d "
   "%6d %6d   %6d\n",
   dev->name, stats->status, stats->qual.qual,
   stats->qual.updated & IW_QUAL_QUAL_UPDATED
   ? '.' : ' ',
   ((__s32) stats->qual.level) -
   ((stats->qual.updated & IW_QUAL_DBM) ? 0x100 : 0),
   stats->qual.updated & IW_QUAL_LEVEL_UPDATED
   ? '.' : ' ',
   ((__s32) stats->qual.noise) -
   ((stats->qual.updated & IW_QUAL_DBM) ? 0x100 : 0),
   stats->qual.updated & IW_QUAL_NOISE_UPDATED
   ? '.' : ' ',
   stats->discard.nwid, stats->discard.code,
   stats->discard.fragment, stats->discard.retries,
   stats->discard.misc, stats->miss.beacon);
-- >8 --

I was just looking at the current development repository to lookup which
coding monkey is responsible for that spaghetti code, but - fear not -
the wireless networking code seems to have completely changed in the
meantime. *sigh* Anyway, there appears to be a /sys interface in the not
so far future..

Oh well, the interesting line is this one:
-- 8< --
 ((__s32) stats->qual.level) - ((stats->qual.updated & IW_QUAL_DBM) ?  0x100 : 0)
-- >8 --
`stats->qual.level' is an 8bit unsigned int, i. e. in the range 0-255.
It's casted to a 32bit signed int and - if the driver marked it as being
in dBm, 256 is subtracted (oh, YES!, 0x100 is so much shorter and easier
to read than 256! What a genius!). So it appears that this design
decision has not yet reached the actual drivers which provide these
values.. Subtracting 256 is absolutely right - but it should be the
kernel doing this..

Note to self: This is what happends when you add functionality and the
old functionality is *not* the default behavior..

Sorry if I sound cynical at this point. Code like the one above is
getting to me..

> Original code uses negative values directly and it didn't work for me
> (didn't store values for signal and noise). That's the reason why I
> modified that code and wrote this one.

It appears your driver is broken.. Are you using that rt2500 driver from
the link you posted in your mail? I've attached an untested patch
against the CVS snapshot that should fix this issue. I'm afraid,
however, that with the transition to mac80211 this fix will be obsolete
soon..

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rt2500-signal.patch
Type: text/x-diff
Size: 1285 bytes
Desc: not available
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20070901/a123ae10/attachment.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20070901/a123ae10/attachment.pgp