On 01/05/2017 12:38 PM, Johannes Berg wrote:
+linux-wireless, where this should've gone
nice. thanks and apologies.
I am running a single wlan0 interface in managed mode (no aliases,
no other wireless interfaces).
The association with the AP still hasn't happened.
I noticed that if trying to change the frequency to one of the valid
values, the driver returns EBUSY.
The call stack is
cfg80211_wext_siwfreq
-->cfg80211_mgd_wext_siwfreq
--->cfg80211_set_monitor_channel (notice call to set 'monitor'
channel
in managed mode)
----> fails with EBUSY
Is therefore the expected behavior to fail under the above
circumstances
(managed mode && single wlan0 interface && no association)?
And if it is, please could you clarify when would it be valid to
change the frequency in managed mode?
Frankly, I don't remember - all of this is plastered all over with
backward compatibility hooks etc.
yes, that is also what it seems to me: plenty of sedimentation in that
code path.
How are you running into this? Why are you even trying to do this? You
really shouldn't use wireless extensions any more.
I am not sure it matters - if I understood your reply, there is no valid
use case to change the frequency in that mode (and all that code should
be removed); it seems to me that it is also your view that userspace
(iwconfig) should be fixed accordingly to not call the extensions?
please let me know if I misunderstood your answer.
I am just trying to understand how the current code is supposed to work
by exercising widely available user-space tools while debugging the kernel.
I noticed the error (EBUSY) just using the wireless tools package as per
its man pages.
$ iwconfig wlan0 freq <frequency>
So, what other tool should we use instead of iwconfig (if the use case
is valid)?
Also, there shouldn't be much reason to be setting the channel anyway,
unless you want to trigger a connection specifically on that channel,
but then when you use nl80211 you get that included in the CONNECT
command there.
Finally, I suspect that this particular backward compatibility hook
can't really work anyway and could be removed, but I'm not sure that
would have the effect you want either.
Actually the frequency gets programmed without errors when reverting
your commit http://tinyurl.com/ho4urp8 (which comes as a surprise as well).
It seems there is some more users doing the same for research purposes.
https://github.com/seemoo-lab/bcm-rpi3/blob/master/kernel/net/wireless/chan.c#L855
johannes
