[Bug 264238] wpa_supplicant fails to associate to open unprotected 802.11n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #139 from J.R. Oldroyd --- Would a wireshark or tcpdump with radiotap on to view the beacon management frames be of any use here? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264238] wpa_supplicant fails to associate to open unprotected 802.11n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #140 from Cy Schubert --- No, tcpdump will dump no packets, even in monitor mode, during scan and association. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264238] wpa_supplicant fails to associate to open unprotected 802.11n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #141 from J.R. Oldroyd --- (In reply to Cy Schubert from comment #140) Won't the beacons be the same both before and after association as far as the WPA IEs are concerned? So dump the radiotap after association using the working wpa-supplicant and have a look where these IEs are. At least it would show what bssids the ap is sending and their security setup. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264238] wpa_supplicant fails to associate to open unprotected 802.11n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #142 from Adrian Chadd --- So, the way this works is: * during scan the net80211 stack just stores the beacons itself as scan results * then it passes them up to wpa_supplicant via an ioctl * then wpa_s uses the initial scan results to issue a "join this BSS as a station" ioctl * <--- this is where we know the IEs are wrong * then net80211 will do the join request, either via directly asking the wifi firmware to do the join, or by crafting auth/assoc frames and sending them to the AP to do the joining Now, the IE contents between beacon, auth and assoc can be different as different subsets of info are required in each. But the only info used by wpa_s when joining a network is the contents of the scan result entry. Ok, so! Some NICs, like the intel NICs, don't send up beacon frames. Instead, they actually do the scanning /in firmware/, and then they send up scan results. That way the firmware can do stuff like background scanning without the driver/stack needing to buffer traffic - it's all done in firmware. Other NICs, like rtwn, ath, etc - they're fully softmac NICs, and everything is done in the driver/stack. When you do a scan, the driver/stack will change channels, configure to receive beacon frames from all MACs, and listen for a bit. Ok, so given that! * For iwn, iwm, etc - they're the smart ones, tcpdump won't get the beacons. You only get what the firmware returns. * For ath, rtwn, etc - they're softmac, tcpdump in 80211 monitor mode will see beacons. ok, so!! :-P * For AR9285, rtwn, etc you can run tcpdump -ni wlan0 -y IEEE802_11_RADIO during a scan, and it SHOULD show the beacons coming in as it does a scan. You can try it, see what happens. * For iwn, iwm, etc - tcpdump won't help, and we'll have to use driver debugging to dump the scan results messages as they come in to see what's in there. (For this reason I keep atheros NICs around for doing monitor mode sniffing, since sometimes firmware/drivers on smart / fullmac devices get things subtly weirdly wrong. :-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264238] wpa_supplicant fails to associate to open unprotected 802.11n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #143 from J.R. Oldroyd --- (In reply to Adrian Chadd from comment #142) Very useful info, thanks. Except, I would point out that at the moment, I am on: iwm0: and I can dump my beacons after association using tcpdump. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264238] wpa_supplicant fails to associate to open unprotected 802.11n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #144 from Adrian Chadd --- yup, once you've associated you can dump beacons on your current channel. :-) You just can't get a dump of all the beacons on all the channels during scan! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264238] wpa_supplicant fails to associate to open unprotected 802.11n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #145 from Bjoern A. Zeeb --- (In reply to Adrian Chadd from comment #144) While diverting from the actual topic; on Intel that still depends on what you tell the firmware even after assoc (also depends on PS and other things). FW/driver way too clever ... and as it turns out sometimes stumbles over its own feet. But yes -- if you want to get radiotap with those, use a 3rd device the listen to what you want/need which can get it to you unfiltered. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264238] wpa_supplicant fails to associate to open unprotected 802.11n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #146 from Cy Schubert --- Created attachment 234903 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234903&action=edit Proof of Concept solution Please try this proof of concept solution. It's a bit of a hack but if it works (it works on my buggy Netgear) @adrian, @bz and I can discuss how to make this permanent). Also make sure to apply https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234807&action=edit along with it. Let me know if this works for you too. As I said, it's a bit of a hack until the root cause can be found but as a proof of concept, if it works for you as it did for me, we'll know we're heading in the right direction. -- You are receiving this mail because: You are on the CC list for the bug.
