Created attachment 247911 [details] Kernel log when connection hangs My Intel 8260AC card frequently fails to connect to my DIR-860L AP (SSID: Zeus 802.11ac). When it does establish a connection, it often hangs - sometimes it takes half an hour, sometimes no more than a few minutes. System is a Dell XPS 13 9350, running Debian Stretch x86_64. In attachment the kernel logs. Frequently recurring messages are 'No association and the time event is over already...' and 'aborting authentication with aa:bb:cc:xx:xx:xx by local choice (Reason: 3=DEAUTH_LEAVING)'. I tried disabling powersaving and falling back to 802.11n, switching the wireless off and on again from the settings panel in the UI, restarting Network-Manager, but that doesn't change anything. Scoured the web for newer firmwares to test, but I cannot find anything newer than iwlwifi-8265-22.ucode, despite the 4.9 iwlwifi driver looking for .25 and .26, and 4.8 looking for .23 and .24. Tested with Debian's stock kernels - 4.7, 4.8 - and their 4.9 RC7 from Experimental. All exhibit the same behaviour. I have a fallback Atheros-based AP (WNDR3700, SSID: Zeus 802.11n). I have tested the following situations: * DIR-860L + Google Nexus 7 2013: works fine; * DIR-860L + Sony Xperia Z3 Compact: works fine; * DIR-860L + Dell XPS 13 with Intel 8260AC: breaks as described above. * WNDR3700 + Google Nexus 7 2013: works fine; * WNDR3700 + Sony Xperia Z3 Compact: works fine; * WNDR3700 + Dell XPS 13 with Intel 8260AC: works fine.
Created attachment 247921 [details] Re-authentication attempts after connection hung
Edit: the log containing 'No association and the time event is over already...' didn't contain any references to the AC AP so I have removed it. Will upload a new one when the issue pops up again.
Created attachment 250291 [details] Time event is over already connection failure Can someone take a look at this please? I will attach a log with the 'time event is over already' all over the place, just took me 10' and a reboot to authenticate to the AP. Thanks!
Could you please use your device as a sniffer and get an air sniffer capture of your channel? This kind of problems can arise when the beacon of the AP is dropped by our firmware because the beacon is corrupted. Other devices (your Sony and Nexus) can be less sensitive than us. This is just a theory based on other bugs we already had in the past, but recording the beacon of your AP can teach us a lot here. If that doesn't help, we'll need to go for firmware debugging.
Created attachment 250741 [details] Wireshark log Thanks Emmanuel. I have put my card in monitor mode, wireshark capture in attachment. AP's MAC is E4:6F:13:2E:BF:2A, I don't see it anywhere in the output, but I'm not familiar with Wireshark so... Let me know if i need to check or filter for anything.
Are you sure you are on the same channel as the AP? How did you put the device in monitor mode? You first need to stop the supplicant otherwise it will only be a managed interface with a sniffer virtual monitor interface attached to it.
Ok - I looked at your sniffer capture and it looks like your device was properly configured as a sniffer, but I am not sure about the channel. In your capture, I can't really see ANY beacons from your Access Point which can hint me that you are sniffing on the wrong channel. Please attach to here the output of: sudo iw wlan0 scan and tell us what is your SSID. If you want, you can encrypt the data using the keys described here: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#privacy_aspects
Created attachment 250751 [details] Wireshark log with channel set Thank you, I did forget to set the channel indeed. Now with the right channel set I see a lot of traffic to/from the D-Link. I have attached the encrypted wireshark log. Thanks for the GPG link, I figured obfuscating the MACs wouldn't help debugging, didn't know we could upload encrypted files :-).
Ok - looked at this. The beacon looks sane. Can you record a tracing record of a failure? Thanks.
I should have time to test the coming days, I'll report back.
Stijn, did you get a chance to get the traces Emmanuel asked for?
Hi Luca, I did. Embarrassingly enough, while I've had this issue for months, I cannot reproduce it anymore at the moment. Router has been powercycled a few times now, but authentication still works like it should. I'm keeping an eye on it, but so far it seems to work fine...
OK. Closing for now.
Created attachment 252701 [details] Problematic authentication capture So, as luck would have it... I flashed & rebooted my AP today and have problems authenticating again. Capture in attachment.
I looked at the sniffer capture. You seem to have captured the Sony device you were mentioning with the AP which indeed connects to the AP despite a few hiccups. 1) the AP seems to be sending ACKs instead of BACKs during a BA session which your Sony device doesn't really like in the first try (it sends a BAR in packet 782). But the AP doesn't get the hint and continues to misbehave in packet 787 which is a regular ACK and not a BACK. This time though, the Sony device doesn't get angry at the AP and doesn't send the BAR. 2) the AP sends an SMPS action frame (packet 788). While this is totally fine from a technical point of view, this frame is surprising and I have never seen it coming from an AP. Of course not to say that SMPS is disabled whereas it has been disabled in the association response frame. Besides this, your AP seems to be sending beacons very nicely. Unfortunately, I can't deduce much from this since this is the working case. Can you record tracing from the non-working case? Thanks.
OK. It seems in monitor mode I cannot connect to an AP, so I'd have to find a third device I can put in monitor mode right, so I can sniff the channel while my laptop connects to the AP, right?
Right. But before you do that, please add power_scheme=1 as a module parameter to iwlmvm and run trace-cmd to record tracing while you associate to the AP on the system that has the Intel device. This can happily be done while you use your device in managed mode.
Hi guys, I'll close this for now since the issue doesn't seem to pop up anymore. Thanks for your help!
Ok - see you again, when you'll reboot the AP :)