On Mon, Mar 25, 2013 at 09:04:14AM -0700, Linus Torvalds wrote: > Ok, I've collected a successful trace with wpa_supplicant, and added > it to the bugzilla entry.
Thanks. This log does actually show a retry of the EAPOL-Key message 1/4 about a second after the first attempt and that was the area I wanted to get more details on to allow this to be compared to the one with NM where EAPOL-Key message 3/4 does not come from the AP. Based on this, it is now less clear to me why the NM case would have behaved differently. > 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... I'm not really familiar with debugging with NM enabled, but it could be possible that the instructions for the older wpa_supplicant on https://live.gnome.org/NetworkManager/Debugging could be adopted for this. The key here would be to get -K added wpa_supplicant command line since exposing of the keys cannot be enabled dynamically at runtime. It could be possible to do that by editing one of these files: /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service I had both on my desktop; don't know which one is used now, but I'd assume it is the first one since that uses a newer D-Bus interface. Adding -dK to the Exec item there would hopefully add those to the wpa_supplicant command line. "sudo killall wpa_supplicant" should force wpa_supplicant to be restarted with the updated command line. (And yes, you probably want to remove that -K from the command line after having collected the logs to avoid future passwords for any other network getting written into a log file..) -- Jouni Malinen PGP id EFC895FA _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
