netdev - Re: SIOCSIWFREQ while in NL80211_IFTYPE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f8e8b557-3e7b-cc1a-c31a-91f9d754e683@linaro.org>
Date:   Thu, 5 Jan 2017 15:38:29 +0100
From:   Jorge Ramirez <jorge.ramirez-ortiz@...aro.org>
To:     Johannes Berg <johannes@...solutions.net>, netdev@...r.kernel.org,
        Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: SIOCSIWFREQ while in NL80211_IFTYPE_STATION

On 01/05/2017 03:06 PM, Johannes Berg wrote:
>> 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);
> All of wext *is* being removed - slowly :)
> It's not longer default in the kernel configuration now.

ah thanks for the info. I should have checked!

>
> IIRC, there actually was a valid use case here - to set the frequency
> before you set the SSID - to be able to force a connection on that
> channel with wext.

ok, yes I thought this would make sense.

>
>> it seems to me that it is also your view that userspace (iwconfig)
>> should be fixed accordingly to not call the extensions?
> iwconfig should just be deleted and iw be used :-)

understood.

>
>> 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.
> Heh, ok.
>
>> Actually the frequency gets programmed without errors when reverting
>> your commit http://tinyurl.com/ho4urp8 (which comes as a surprise as
>> well).
> Well, it's not my commit, but that makes sense. I suppose we should
> treat this as a regression, but reverting that doesn't seem like the
> right fix. Actually, I'm not convinced we should do monitor channel
> change anyway when you set the frequency with wext, so we can probably
> just remove that call there - want to send a patch to that effect?

do you mean this?

[jramirez@...oo ~ (debian-qcom-dragonboard410c-16.09-local $)]$ git diff
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index a4e8af3..c56bac5 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -106,30 +106,7 @@ int cfg80211_mgd_wext_siwfreq(struct net_device *dev,
                         goto out;
         }

-
         wdev->wext.connect.channel = chan;
-
-   /*
-    * SSID is not set, we just want to switch monitor channel,
-    * this is really just backward compatibility, if the SSID
-    * is set then we use the channel to select the BSS to use
-    * to connect to instead. If we were connected on another
-    * channel we disconnected above and reconnect below.
-    */
-   if (chan && !wdev->wext.connect.ssid_len) {
-           struct cfg80211_chan_def chandef = {
-                   .width = NL80211_CHAN_WIDTH_20_NOHT,
-                   .center_freq1 = freq,
-           };
-
-           chandef.chan = ieee80211_get_channel(&rdev->wiphy, freq);
-           if (chandef.chan)
-                   err = cfg80211_set_monitor_channel(rdev, &chandef);
-           else
-                   err = -EINVAL;
-           goto out;
-   }
-
         err = cfg80211_mgd_wext_connect(rdev, wdev);
   out:
         wdev_unlock(wdev);



I tested the change above: we can now modify the channel/frequency when 
the SSID is not set in managed mode.
When the SSID is set however iwconfig does not report any error but 
channel/frequency doesn't change.

if you think this is acceptable I can submit a patch


> johannes