Re: [patch] fix madwifi strength

[Dan Williams <dcbw redhat com>]

On Wed, 2006-01-25 at 10:46 -0500, Robert Love wrote:
> On Tue, 2006-01-24 at 19:21 +0100, Tim Niemueller wrote:
> 
> Hi, Tim.
> 
> > Since I have a Atheros card myself I'd be happy to take that patch! I
> > see Dan's point in keeping the code clean and non-specific to drivers.
> > But on the other hand we have to face reality and see that not all
> > drivers provide the same information. Here it may be a lack of a strong
> > definition of the semantics these values should have in the first place.
> > Many laptops nowadays use Atheros chip and NM could provide a better
> > experience by applying one of these patches.
> > 
> > Short: I vote for this to go into NM.
> 
> Fully agree.  But I also sympathize with Dan's no-hacks because
> drivers-should-not-suck argument.  So, it is his call.
> 
> I do say that I prefer the non-alt version of the patch.

Um, they are pushing raw dBm into the quality field.  The quality field
is WEXT defined as a driver-dependent quality, whose lower bound is 0,
and whose upper bound is max_qual->qual.  It must move in a linear
fashion.

But comments in the source indicate (to me) that set_quality() is using
dBm:

 * Units are in db above the noise floor. That means the
 * rssi values reported in the tx/rx descriptors in the
 * driver are the SNR expressed in db.

That's just plain wrong.  Decibels are NOT linear.

<wireless.h>
	__u8		qual;		/* link quality (%retries, SNR,
					   %missed beacons or better...) */
	__u8		level;		/* signal level (dBm) */
	__u8		noise;		/* noise level (dBm) */

Therefore, their driver quality is violating the spec.  They are
perfectly fine stuffing whatever the heck they want into the qual->level
field, and marking that as either dBm or RSSI.  That's how you do raw
hardware level with WEXT.  What you don't do is stuff those into
qual->qual.

qual->qual is for artificial, driver-dependent quality.  Why they don't
do something even half-smart, like ipw2x00 does, is beyond me.  Maybe
it's laziness, or maybe I haven't yelled at them yet.  They could at
least _try_ to conform.  Many, many more things factor into "quality"
than raw signal strength, like dropped packets, failed decryption, etc.
Tell them to fix the damn driver...

If you want, I'll tell them to do it, and I'll even write the patch for
it.  At some point we need to know some heads to get minimal conformance
to _something_.

Dan