From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Date: Mon, 25 Mar 2013 09:04:14 -0700 Subject: [ath9k-devel] ath9k not connecting to one particular network.. In-Reply-To: <20130325113001.GA26285@jouni.qca.qualcomm.com> References: <20130325101251.GA8819@jouni.qca.qualcomm.com> <20130325113001.GA26285@jouni.qca.qualcomm.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Mon, Mar 25, 2013 at 4:30 AM, Jouni Malinen wrote: > > This looks very basic case taken into account the AP configuration (just > WPA2-Personal/CCMP) and passphrase that should not allow much of a > chance for typos or encoding issues (non-ASCII..). Hmm. I'm certain I didn't mistype it, and I did it several times (with "show text"), and it really is a very simple 8-character passphrase ("condo000"). But it is certainly possible that the key got corrupted in between the GUI element and the actual PSK key. When I do it manually, there's only the "wpa_passphrase" thing that writes out the PSK key, and there is much less room for that to get screwed up somewhere. > However, I cannot > find anything obvious from the debug log. For some reason, the AP just > rejects EAPOL-Key message 2/4 from the station. In most cases, this is > because of a typo in the PSK/passphrase, but it sounds quite unlikely > here unless NM somehow configured this differently (which would also be > surprising if it applies only for this specific network). Yeah, as mentioned, I can literally switch between the two wireless networks here in the room, and they are both WPA2. My phone just has a much more complex passphrase. > Since it looks like the particular passphrase is of not much need for > protection, it could be useful if you could collect wpa_supplicant debug > logs with -K added to the command line (-ddKt for the manual test and > something similar with NM, I'd assume). This -K adds passwords and keys > into the log so it is not something that is enabled by default, but it > sounds like this is fine here and it will include the details that would > be needed to check what exactly are the differences in the 4-way > handshake between NM and manual wpa_supplicant configuration cases. Ok, I've collected a successful trace with wpa_supplicant, and added it to the bugzilla entry. I do not know how to get NM to expose the PSK key it is using, though. So the NM-generated failing log doesn't have that information, and unless somebody tells me the magic dbus sequence to enable it, I likely won't get it... LInus