2015-06-07 02:47:16

by Gerrit Renker

[permalink] [raw]
Subject: [WEXT]: multiple calls for SIOCGIWSTATS return same value

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


2015-06-10 02:26:12

by Gerrit Renker

[permalink] [raw]
Subject: Re: [WEXT]: multiple calls for SIOCGIWSTATS return same value

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

2015-06-09 07:33:11

by Johannes Berg

[permalink] [raw]
Subject: Re: [WEXT]: multiple calls for SIOCGIWSTATS return same value

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


2015-06-09 01:59:13

by Gerrit Renker

[permalink] [raw]
Subject: Re: [WEXT]: multiple calls for SIOCGIWSTATS return same value

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

2015-06-08 07:18:08

by Johannes Berg

[permalink] [raw]
Subject: Re: [WEXT]: multiple calls for SIOCGIWSTATS return same value

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


2015-06-10 06:12:18

by Johannes Berg

[permalink] [raw]
Subject: Re: [WEXT]: multiple calls for SIOCGIWSTATS return same value

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