netdev - Re: [PATCH v2] mac80211: add assoc beacon timeout logic

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: <CAMP44s1orLwg4v8UPM_1c-PspKQd5run_wAwHj-8oKmj2uqUgw@mail.gmail.com>
Date:	Thu, 14 Nov 2013 04:44:49 -0600
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	linux-wireless Mailing List <linux-wireless@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v2] mac80211: add assoc beacon timeout logic

On Wed, Nov 13, 2013 at 12:30 PM, Johannes Berg
<johannes@...solutions.net> wrote:
> On Mon, 2013-11-11 at 12:06 -0600, Felipe Contreras wrote:
>
>> > The not receiving part is a bug. I think you're probably receiving
>> > beacons once associated though?
>>
>> Nope. Never.
>
> That's odd, firmware bug? But it's still odd since windows works?
>
>> Moreover, if continuing the association without beacons has a legal a
>> problem, that problem would exist for drivers that don't have the
>> IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC flag, wouldn't it? How exactly
>> would trying to associate with need_beacon break the law, but not if
>> !need_beacon?
>
> Well, it's actually somewhat unlikely you'd break the law, although
> possible, since eventually you'd get disconnected from the AP anyway?

I get disconnected from the AP due to other bugs, you are making the
assumption that it's because of the lack of beacons.

I saw this the last time I experienced a disconnect:

Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: fail to flush all
tx fifo queues Q 2
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Current SW read_ptr
213 write_ptr 214
Nov 13 16:29:48 nysa kernel: iwl data: 00000000: 00 00 20 00 00 00 00
00 00 00 00 00 00 00 00 00  .. .............
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(0) = 0x8000302e
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(1) = 0x801020d5
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(2) = 0x80201016
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(3) = 0x803000fb
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(4) = 0x00000000
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(5) = 0x00000000
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(6) = 0x00000000
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(7) = 0x00709010
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 0 is active and
mapped to fifo 3 ra_tid 0x0000 [252,252]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 1 is active and
mapped to fifo 2 ra_tid 0x0000 [23,23]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 2 is active and
mapped to fifo 1 ra_tid 0x0000 [213,214]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 3 is active and
mapped to fifo 0 ra_tid 0x0000 [47,47]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 4 is active and
mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 5 is active and
mapped to fifo 4 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 6 is active and
mapped to fifo 2 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 7 is active and
mapped to fifo 5 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 8 is active and
mapped to fifo 4 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 9 is active and
mapped to fifo 7 ra_tid 0x0000 [17,17]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 10 is active and
mapped to fifo 5 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 11 is inactive
and mapped to fifo 1 ra_tid 0x0000 [163,163]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 12 is inactive
and mapped to fifo 3 ra_tid 0x0006 [236,236]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 13 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 14 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 15 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 16 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 17 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 18 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 19 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]

> In any case - your argumentation above isn't true because every device
> listens for beacons, and if none are received then it should eventually
> disconnect. That should be true even with your hack here.

Should it? I don't see that happening. Where exactly in the code is that check?

> In any case, I'm not really comfortable connecting to an AP that we
> never ever receive beacons from.

Well, we are *already* doing that for every driver, except the ones
that do IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC, which are few.

Cheers.

-- 
Felipe Contreras
--
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