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]

Date:	Mon, 19 Jan 2015 04:53:24 +1200
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Emmanuel Grumbach <egrumbach@...il.com>,
	Arend van Spriel <arend@...adcom.com>
Cc:	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 11:24 PM, Emmanuel Grumbach <egrumbach@...il.com> wrote:
>
> we have different scan flows based on the firmware version you have,
> so it would help if you could tell me what firmware you have.

Sure. It's the larest one I could find

   iwlwifi 0000:01:00.0: loaded firmware version 23.11.10.0 op_mode iwlmvm

with the actual firmware file being 'iwlwifi-7260-10.ucode' from the
current linux-firmware tree.

Iin a different email Arend van Spriel <arend@...adcom.com> wrote:
>
> The function iwl_trans_pcie_stop_device() put device in low-power and
> resets the cpu on the device.  So iwl_op_mode_hw_rf_kill ends up in
> iwl_mvm_set_hw_rfkill_state which schedules cfg80211_rfkill_sync_work
> and returns true if firmware is running.  The patch below might work.

Any suggestions for how to best try to trigger this for testing?
Looking at my logs, it turns out that I actually got this three times,
but they were all on the same boot, and I think the first case might
just have triggered the later ones.

The trigger was turning off wifi from the wifi settings app due to
being in an airplane when they were closing the doors. I don't *think*
there was actually any wifi around at the time, which may or may not
have made the scanning take longer and made it easier to trigger.

But I've done it before (although this machine has been upgraded to
F21 reasonably recently, and I did update the ucode file before the
trip). And I did it afterwards to test. And it happened that one time
(and then apparently kept happening during suspend/resume/shutdown,
but as mentioned, I blame that on some sticky problem from the first
time, and those events in turn happened because I couldn't get
wireless to work afterwards).

IOW, I'm not at all sure I can recreate it, so your "analyzing the
source code for how this could happen" may be the only good way..

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