Re: SIOCSIWFREQ while in NL80211_IFTYPE_STATION

On 01/05/2017 12:38 PM, Johannes Berg wrote:

+linux-wireless, where this should've gone

nice. thanks and apologies.

quoted

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