On Wed, Nov 13, 2013 at 12:30 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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 linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
