netdev - Re: Wireless scanning while turning off the radio problem..

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: <CANUX_P3kv5ofQJLGyEvRSgetHg=TJsaVennLJWq3ummgRJHWgg@mail.gmail.com>
Date:	Sun, 18 Jan 2015 21:13:13 +0200
From:	Emmanuel Grumbach <egrumbach@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Arend van Spriel <arend@...adcom.com>,
	Johannes Berg <johannes@...solutions.net>,
	David Miller <davem@...emloft.net>,
	Linux Wireless List <linux-wireless@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: Wireless scanning while turning off the radio problem..

On Sun, Jan 18, 2015 at 8:52 PM, Emmanuel Grumbach <egrumbach@...il.com> wrote:
> On Sun, Jan 18, 2015 at 8:40 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>> On Mon, Jan 19, 2015 at 5:48 AM, Arend van Spriel <arend@...adcom.com> wrote:
>>>
>>> So as you indicated you were in location where none of your configured
>>> networks were available. Flipping the rfkill switch in that situation is the
>>> way to trigger the issue.
>>
>> So you certainly seem to be able to explain the behavior I saw under
>> the circumstances they happened.
>>
>> I suspect the best thing to do is to just apply your patch. I may not
>> be able to really test it much for the next few days anyway. Emmanuel?
>>
>
> Sorry - I was a bit busy.
> The patch seems wrong, we can't really call that function from the
> rfkill interrupt - it will blow up.
> The good news is that I could reproduce the bug based on what Arend
> pointed. I totally missed the fact
> that it was scheduled scan - thanks Arend for that.
>
> So the system I have here doesn't have HW rfkill so I had to implement
> a hook that fakes it,
> but I can't reproduce the problem.
> I'll come up with a patch.


Ok - Here is the patch:

diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c
b/drivers/net/wireless/iwlwifi/mvm/ops.c
index 384eefd..bbd8054 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -867,6 +867,9 @@ static bool iwl_mvm_set_hw_rfkill_state(struct
iwl_op_mode *op_mode, bool state)
        if (calibrating)
                iwl_abort_notification_waits(&mvm->notif_wait);

+       if (state)
+               mvm->scan_status = IWL_MVM_SCAN_NONE;
+
        /*
         * Stop the device if we run OPERATIONAL firmware or if we are in the
         * middle of the calibrations.


I will send that for internal review, because I am not all that much
familiar with this and I want the guy who wrote that code to take a
look before I send a pull request, but that should help.

In any case, Linus, until you get the fix (which should be sent to
upstream in 12 hours) you can restart the whole wifi stack instead of
rebooting:

sudo modprobe -r iwlwifi
sudo modprobe iwlwifi
sudo killall wpa_supplicant


that should bring your wifi back without the need to reboot.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html