A problem has been found in recent kernels where multiple
calls using SIOCGIWSTATS return the same, identical value.
This behaviour is observable both using 'iwconfig <dev>'
and wavemon info screen, where it was reported in [1].
It looks as if this is a WEXT issue, since on the same
system multiple 'iw dev <devname> station dump' calls
return different signal level values.
I can confirm the behaviour on davem 4.1.0-rc6 net tree
at commit c46a024ea5, it has been reported on [1] for
fedora 21 with kernel-4.0.4-201/2 as well.
That report also stated that the behaviour does not occur
on kernel-3.19.7-200. Have not had time to bisect yet.
Thanks for any hints that can help resolve this.
[1] https://github.com/uoaerg/wavemon/issues/10
On Tue, 09 Jun 2015 09:33:08 +0200
Johannes Berg <[email protected]> wrote:
> > There is a similar behaviour for scan results: the signal levels reported
> > for stations remain the same for all subsequent calls. Previously these
> > also changed with time and position of receiver.
>
> You mean BSSes, not stations, right? This is very strange - it seems
> those should be two entirely different code paths in the kernel.
>
> What driver are you using? But then again, you said nl80211/iw works,
> right? Then the driver shouldn't matter.
>
> Do you think you'd be able to use tracing?
Many thanks for providing the patch. I just tried it and it fixed both problems
(access point signal level/quality and signal level reported for BSSes in scan
result). Not sure if trace results are still needed, but I can do that if needed.
Will also work on porting wavemon to nl80211 now.
Thanks again,
Gerrit
On Mon, 2015-06-08 at 19:58 -0600, Gerrit Renker wrote:
> I am primarily referring to the signal level. The first call returns a
> plausible value e.g. -78dB. All subsequent calls return the same value,
> regardless of receiver position (moving the laptop).
>
> It almost looks like a static value that gets initialized and then
> does not change.
>
> There is a similar behaviour for scan results: the signal levels reported
> for stations remain the same for all subsequent calls. Previously these
> also changed with time and position of receiver.
You mean BSSes, not stations, right? This is very strange - it seems
those should be two entirely different code paths in the kernel.
What driver are you using? But then again, you said nl80211/iw works,
right? Then the driver shouldn't matter.
Do you think you'd be able to use tracing?
trace-cmd report -e cfg80211 -e mac80211
would report the calls to/from the driver and could perhaps shed some
light. If you can record this, send me the resulting trace.dat file
(compressed) off-list.
johannes
> On Sat, 2015-06-06 at 20:37 -0600, Gerrit Renker wrote:
> > A problem has been found in recent kernels where multiple
> > calls using SIOCGIWSTATS return the same, identical value.
>
> Which "value"? I believe these return a number of different values. What
> are the returned values? Are they perhaps just 0?
>
I am primarily referring to the signal level. The first call returns a
plausible value e.g. -78dB. All subsequent calls return the same value,
regardless of receiver position (moving the laptop).
It almost looks like a static value that gets initialized and then
does not change.
There is a similar behaviour for scan results: the signal levels reported
for stations remain the same for all subsequent calls. Previously these
also changed with time and position of receiver.
> Is the application a 32-bit application running on a 64-bit machine
> perhaps?
Sorry forgot to mention: application and operating system both 64 bit,
the bug submitted to wavemon also mentioned 64 bit.
Thank you for the reply -- maybe this means that the root cause is in a
different part; I would not know which at the moment.
On Sat, 2015-06-06 at 20:37 -0600, Gerrit Renker wrote:
> A problem has been found in recent kernels where multiple
> calls using SIOCGIWSTATS return the same, identical value.
Which "value"? I believe these return a number of different values. What
are the returned values? Are they perhaps just 0?
Is the application a 32-bit application running on a 64-bit machine
perhaps? There have been bugs in that area in the past, though I don't
believe anything changed between 3.19 and 4.0. In fact, in wext nothing
really changed at all - only some internal maintenance (commit
319090bf6c75e3ad42a8c74973be5e78ae4f948f)
> This behaviour is observable both using 'iwconfig <dev>'
> and wavemon info screen, where it was reported in [1].
>
> It looks as if this is a WEXT issue, since on the same
> system multiple 'iw dev <devname> station dump' calls
> return different signal level values.
>
> I can confirm the behaviour on davem 4.1.0-rc6 net tree
> at commit c46a024ea5, it has been reported on [1] for
> fedora 21 with kernel-4.0.4-201/2 as well.
>
> That report also stated that the behaviour does not occur
> on kernel-3.19.7-200. Have not had time to bisect yet.
>
> Thanks for any hints that can help resolve this.
I have no idea, sorry.
johannes
On Tue, 2015-06-09 at 20:25 -0600, Gerrit Renker wrote:
> Many thanks for providing the patch. I just tried it and it fixed both problems
> (access point signal level/quality and signal level reported for BSSes in scan
> result). Not sure if trace results are still needed, but I can do that if needed.
No, I did the tracing myself - it showed strange behaviour that
eventually helped me pinpoint the problem :)
johannes