[PATCH] Setting quality in scan results

[Pavel Roskin]

On Thu, 22 Apr 2004, Matt Brown wrote:

> > What is supposed to be compared is the quality of different access points
> > in the scan results.  Suppose one access point has a strong signal but the
> > noise is high on the channel.  Another access point has a weaker signal,
> > but the channel is relatively noise-free.  Which one is better?  iwlist
> > always wants the driver to decide.  This is a design flaw in wireless
> > tools, but we have to deal with it.
>
> I guess, my concern is that I scan and select a network which appears to
> have a good quality. I then select that network and the quality that I
> am now observing is different to that which I saw on the scan. This
> could lead to confusion.
>
> From your explanation above it seems probable that this will happen
> anyway, so perhaps my concern is not valid.

For the comparison to be fair, you should compare scan results to other
scan results.  The current access point will appear in the scan results
too.

> > > > iwe.u.qual.updated is not used for scan results, but it's better not to
> > > > return a random number from the kernel to the userspace.
> > >
> > > I agree, but why not return 0 to indicate that quality results are not
> > > available during a scan.
> >
> > Do you mean iwe.u.qual.updated or iwe.u.qual.qual?  iwe.u.qual.updated
> > will be 0, it's in the patch.  Setting iwe.u.qual.qual to 0 would confuse
> > users and possibly some utilities as well.  It's better to return some
> > kind of quality data.
>
> Not sure, I'm not familiar with the internals of this stuff yet, I was
> thinking at a higher level.

iwe.u.qual.updated is unused by iwlist for scan results.  iwe.u.qual.qual
is what iwlist shows as "quality".

> My thinking as I was writing this email was that the scan data would
> usually be used by an application (or the wireless tools) to
> automatically pick the best network available. In this case you can
> leave it up to the application to calculate a quality value from the
> available signal and noise values. This was why I suggested setting the
> quality to 0 as a clear indication that it has not been set. I didn't
> really consider the case of users manually initiating a scan - I
> wouldn't think it would be done very often and only by power users, it's
> not a very friendly interface.

Then you are trying to redefine Wireless Extensions.  I'm not against it,
but such "activism" in drivers would be unhelpful.  What if Jean decides
that "no quality data" is -1 rather than 0?

> This approach has several advantages to my mind.
> - Confusion is avoided by not returning quality statistics derived from
> different algorithms.
> - The scan results to my mind are primarily intended for other
> applications.

The problem is, the requirement to return quality data for the scan
results is not just a bug in iwlist.  It's a limitation of the wireless
extensions API.  Not using iwlist won't fix the API problem.  The
application will need to know what each driver means when it returns the
scan data.

> - The quality value is being generated by an arbitrary algorithm, best
> to leave this to an application rather than a driver which should
> provide a general interface.

I agree.  But as long as the API requires us to return this data, it's
better to return useful data.

-- 
Regards,
Pavel Roskin