Re: debugging a Wifi association problem
El día jueves, julio 18, 2019 a las 12:41:42p. m. +0200, Matthias Apitz escribió: > I compiled net/tcpdump to look into that and it supports: > > # /usr/local/sbin/tcpdump -ni wlan0 -y IEEE802_11_RADIO > > and the OpenBSD man page explains what IEEE802_11_RADIO is. I think, > ... This morning I captured the IEEE802_11_RADIO traffic with the above tcpdump cmd and used wireshark to filter out the trafic for the connecting phone. Details below. There are only "Probe Request" broadcasts or "Authentication" requests to the my AP (MAC addr 00:1c:4a:06:17:f5) from the phone, but the AP never answers. Only sometimes another AP (SSID=FRITZ!Box 7530) gives an answer which the phone ignores. Why the AP with MAC addr 00:1c:4a:06:17:f5 does not answer? Any ideas? matthias remarks to the capture file IEEE802_11_RADIO.out time of capture: 07:57:00 T+00 start of capture 07:57:10 T+10 Wifi enabled in phone (i.e. SSID tarara "green") 07:57:38 T+38 network manager asks again for psk 07:58:00 T+60 psk entered and pressed "connect" 07:58:30 T+90 network manager asks again for psk AP SSID: tarara, MAC: 00:1c:4a:06:17:f5 MAC addr of phone: 4c:74:03:65:46:a9 filter: wlan_radio contains 65:46:a9 1754 38.060131 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=3, FN=0, Flags=, SSID=Broadcast 1758 38.149385 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=10, FN=0, Flags=, SSID=Broadcast 1759 38.149399 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=11, FN=0, Flags=, SSID=Broadcast 1760 38.159666 98:9b:cb:0c:47:1a Bq_65:46:a9 802.11 455 Probe Response, SN=3623, FN=0, Flags=R..., BI=100, SSID=FRITZ!Box 7530 OK 1767 38.276541 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=20, FN=0, Flags=, SSID=Broadcast 1768 38.277267 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=21, FN=0, Flags=, SSID=Broadcast 1770 38.301422 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=22, FN=0, Flags=, SSID=Broadcast 1771 38.301433 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=23, FN=0, Flags=, SSID=Broadcast 1773 38.345753 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=24, FN=0, Flags=, SSID=Broadcast 1774 38.346243 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=25, FN=0, Flags=, SSID=Broadcast 1906 41.638487 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1907 41.639535 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1908 41.640593 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1909 41.641950 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1910 41.647066 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1911 41.656295 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1912 41.663298 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1913 41.663832 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags= 1914 41.665392 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1915 41.667056 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1916 41.667621 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1917 41.669059 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1918 41.670645 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1920 41.677283 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1921 41.678070 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=28, FN=0, Flags= 1922 41.678655 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=28, FN=0, Flags=R... 1923 41.679609 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=28, FN=0, Flags=R... 1924 41.681081 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=28, FN=0, Flags=R... 1925
Re: debugging a Wifi association problem
-L List the known data link types for the interface and exit. # tcpdump -ni wlan0 -L Data link types for wlan0 (use option -y to set): EN10MB (Ethernet) IEEE802_11_RADIO (802.11 plus radiotap header) чт, 18 июл. 2019 г. в 13:41, Matthias Apitz : > El día jueves, julio 18, 2019 a las 12:04:27p. m. +0200, Matthias Apitz > escribió: > > > El día miércoles, julio 17, 2019 a las 11:45:49p. m. -0700, Adrian Chadd > escribió: > > > > > Hi! > > > > > > So, you don't set the monitor flag like you do on linux. you create a > > > monitor VAP instead or you just use tcpdump with the right flags. > > > > > > Try: > > > > > > tcpdump -ni wlan0 -y IEEE802_11_PROTO > > > > > > That'll put the NIC into monitor mode on the current channel, even in > > > station mode, and let you do normalt raffic as well as get promiscuous > > > traffic into tcpdump. > > > > Thanks, but: > > > > root@c720-r342378:~ # uname -a > > FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC amd64 > > root@c720-r342378:~ # tcpdump -ni wlan0 -y IEEE802_11_PROTO > > tcpdump: invalid data link type IEEE802_11_PROTO > > I compiled net/tcpdump to look into that and it supports: > > # /usr/local/sbin/tcpdump -ni wlan0 -y IEEE802_11_RADIO > > and the OpenBSD man page explains what IEEE802_11_RADIO is. I think, > Adrian, this was what you have in mind, correct? > > matthias > > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > ___ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org > " > ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
El día jueves, julio 18, 2019 a las 12:04:27p. m. +0200, Matthias Apitz escribió: > El día miércoles, julio 17, 2019 a las 11:45:49p. m. -0700, Adrian Chadd > escribió: > > > Hi! > > > > So, you don't set the monitor flag like you do on linux. you create a > > monitor VAP instead or you just use tcpdump with the right flags. > > > > Try: > > > > tcpdump -ni wlan0 -y IEEE802_11_PROTO > > > > That'll put the NIC into monitor mode on the current channel, even in > > station mode, and let you do normalt raffic as well as get promiscuous > > traffic into tcpdump. > > Thanks, but: > > root@c720-r342378:~ # uname -a > FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC amd64 > root@c720-r342378:~ # tcpdump -ni wlan0 -y IEEE802_11_PROTO > tcpdump: invalid data link type IEEE802_11_PROTO I compiled net/tcpdump to look into that and it supports: # /usr/local/sbin/tcpdump -ni wlan0 -y IEEE802_11_RADIO and the OpenBSD man page explains what IEEE802_11_RADIO is. I think, Adrian, this was what you have in mind, correct? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
On Thu, 18 Jul 2019 08:20:33 +0200 Matthias Apitz wrote: > El día miércoles, julio 17, 2019 a las 11:13:14p. m. +0200, Vladimir Botka > escribió: > > > > > FreeBSD is not needed to analyse the the problem. > > Use whatever system is able > > to set wifi card into the "monitor" mode and sniff the packets first. The > > link below is complete how to do it > > https://wiki.wireshark.org/CaptureSetup/WLAN > > When you got the data analyse it with wireshark. The captured data might > > grow > > fast. > > > > > > I only have FreeBSD laptops (and an older Ubuntu) and the question was > > > not if FreeBSD is needed, but if FreeBSD is *able* to capture Wifi. > > > > Yes. FreeBSD is able to capture Wifi. Find below the link to the BSD > > chapter. > > https://wiki.wireshark.org/CaptureSetup/WLAN#A.2ABSD > > # wireshark -i wlan0 -I > The capture session could not be initiated on interface 'wlan0' (That > device doesn't support monitor mode). # ifconfig wlan0 monitor > does not help and does nos say anything. > > # ifconfig wlan0 > wlan0: flags=48843 metric 0 > mtu 1500 ... > Any ideas? You've successfully set MONITOR mode of wlan0. Use tcpdump to capture packets. https://www.freebsd.org/cgi/man.cgi?tcpdump(1) When you got the data analyse it with wireshark. The captured data might grow fast. Cheers, -vlado pgpqIOw5I1E59.pgp Description: OpenPGP digital signature
Re: debugging a Wifi association problem
Hi! So, you don't set the monitor flag like you do on linux. you create a monitor VAP instead or you just use tcpdump with the right flags. Try: tcpdump -ni wlan0 -y IEEE802_11_PROTO That'll put the NIC into monitor mode on the current channel, even in station mode, and let you do normalt raffic as well as get promiscuous traffic into tcpdump. -adrian ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
El día miércoles, julio 17, 2019 a las 11:13:14p. m. +0200, Vladimir Botka escribió: > > I only have FreeBSD laptops (and an older Ubuntu) and the question was > > not if FreeBSD is needed, but if FreeBSD is *able* to capture Wifi. > > Thanks > > matthias > > Yes. FreeBSD is able to capture Wifi. Find below the link to the BSD chapter. > https://wiki.wireshark.org/CaptureSetup/WLAN#A.2ABSD > When I start capturing with # wireshark -i wlan0 -I it says: The capture session could not be initiated on interface 'wlan0' (That device doesn't support monitor mode). Please check that you have the proper interface or pipe specified. also setting before # ifconfig wlan0 monitor does not help and does nos say anything. # ifconfig wlan0 wlan0: flags=48843 metric 0 mtu 1500 ether 90:48:9a:92:9e:43 inet 192.168.2.105 netmask 0xff00 broadcast 192.168.2.255 groups: wlan ssid tarara channel 6 (2437 MHz 11g) bssid 00:1c:4a:06:17:f5 regdomain 108 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 20 bmiss 7 scanvalid 60 protmode CTS wme burst roaming MANUAL media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated nd6 options=2b # pciconf -lv ... ath0@pci0:1:0:0:class=0x028000 card=0xe058105b chip=0x0034168c rev=0x01 hdr=0x00 vendor = 'Qualcomm Atheros' device = 'AR9462 Wireless Network Adapter' class = network Any ideas? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
On Wed, 17 Jul 2019 20:53:24 +0200 Matthias Apitz wrote: > El día miércoles, julio 17, 2019 a las 08:26:02p. m. +0200, Vladimir Botka > escribió: > > > > I installed wireshark-2.6.5_2 in my FreeBSD (CURRENT from December last > > > year). I tried to enable from > > > View --> [x] Wireless Toolbar > > > but this gives an error about "Failed to initialize ws80211" in the GUI > > > and I can not set the channel or Frequency. Is this not possible with > > > FreeBSD? > > > > FreeBSD is not needed to analyse the the problem. > > Use whatever system is able > > to set wifi card into the "monitor" mode and sniff the packets first. The > > link below is complete how to do it > > https://wiki.wireshark.org/CaptureSetup/WLAN > > When you got the data analyse it with wireshark. The captured data might > > grow > > fast. > > I only have FreeBSD laptops (and an older Ubuntu) and the question was > not if FreeBSD is needed, but if FreeBSD is *able* to capture Wifi. > Thanks > matthias Yes. FreeBSD is able to capture Wifi. Find below the link to the BSD chapter. https://wiki.wireshark.org/CaptureSetup/WLAN#A.2ABSD Cheers, -vlado pgp3dAVnF2Bh7.pgp Description: OpenPGP digital signature
Re: debugging a Wifi association problem
El día miércoles, julio 17, 2019 a las 08:26:02p. m. +0200, Vladimir Botka escribió: > > I installed wireshark-2.6.5_2 in my FreeBSD (CURRENT from December last > > year). I tried to enable from > > View --> [x] Wireless Toolbar > > but this gives an error about "Failed to initialize ws80211" in the GUI > > and I can not set the channel or Frequency. Is this not possible with > > FreeBSD? > > FreeBSD is not needed to analyse the the problem. I only have FreeBSD laptops (and an older Ubuntu) and the question was not if FreeBSD is needed, but if FreeBSD is *able* to capture Wifi. > Use whatever system is able > to set wifi card into the "monitor" mode and sniff the packets first. The > link below is complete how to do it > https://wiki.wireshark.org/CaptureSetup/WLAN > When you got the data analyse it with wireshark. The captured data might grow > fast. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
On Wed, 17 Jul 2019 19:35:32 +0200 Matthias Apitz wrote: > El día miércoles, julio 17, 2019 a las 09:05:43a. m. +0200, Vladimir Botka > escribió: > > On Wed, 17 Jul 2019 07:38:26 +0200 > > Matthias Apitz wrote: > > > > > ... The association requests are always rejected with a package > > > CTRL-EVENT-ASSOC-REJECT with 'status_code=1'... > > > Do we have any tool in FreeBSD to monitor/debug this problem between the > > > device in question and the AP? Any other ideas? > > > > Best practice is to sniff packets and see what's going on. > > http://www.wireless-nets.com/resources/tutorials/sniff_packets_wireshark.html > > I installed wireshark-2.6.5_2 in my FreeBSD (CURRENT from December last > year). I tried to enable from > View --> [x] Wireless Toolbar > but this gives an error about "Failed to initialize ws80211" in the GUI > and I can not set the channel or Frequency. Is this not possible with > FreeBSD? FreeBSD is not needed to analyse the the problem. Use whatever system is able to set wifi card into the "monitor" mode and sniff the packets first. The link below is complete how to do it https://wiki.wireshark.org/CaptureSetup/WLAN When you got the data analyse it with wireshark. The captured data might grow fast. Cheers, -vlado pgpP_8DQ34idM.pgp Description: OpenPGP digital signature
Re: debugging a Wifi association problem
El día miércoles, julio 17, 2019 a las 09:05:43a. m. +0200, Vladimir Botka escribió: > Hello, > > On Wed, 17 Jul 2019 07:38:26 +0200 > Matthias Apitz wrote: > > > ... The association requests are always rejected with a package > > CTRL-EVENT-ASSOC-REJECT with 'status_code=1'... > > Do we have any tool in FreeBSD to monitor/debug this problem between the > > device in question and the AP? Any other ideas? > > Best practice is to sniff packets and see what's going on. > http://www.wireless-nets.com/resources/tutorials/sniff_packets_wireshark.html > Hello Vladimir, I installed wireshark-2.6.5_2 in my FreeBSD (CURRENT from December last year). I tried to enable from View --> [x] Wireless Toolbar but this gives an error about "Failed to initialize ws80211" in the GUI and I can not set the channel or Frequency. Is this not possible with FreeBSD? In this case I'd have to look for a Linux laptop or even a Windows one (which I'd hate). Thanks for a hint. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
Hello, On Wed, 17 Jul 2019 07:38:26 +0200 Matthias Apitz wrote: > ... The association requests are always rejected with a package > CTRL-EVENT-ASSOC-REJECT with 'status_code=1'... > Do we have any tool in FreeBSD to monitor/debug this problem between the > device in question and the AP? Any other ideas? Best practice is to sniff packets and see what's going on. http://www.wireless-nets.com/resources/tutorials/sniff_packets_wireshark.html Cheers, -vlado pgpq9psFbWO4j.pgp Description: OpenPGP digital signature
debugging a Wifi association problem
Hello, I have at home the problem that all my Wifi devices (four FreeBSD laptops, one Ubuntu laptop and three Ubuntu mobile phones) can connect fine to my AP. Only one can't anymore (it worked fine in the past but since some months can't associate anymore). The association requests are always rejected with a package CTRL-EVENT-ASSOC-REJECT with 'status_code=1'. The device in question can connect to any other AP I know of in public or in my company, but not to the two AVM FRITZ!Box WLAN 3170 and 7430 (I bought the 7430 only to verify the problem, both AVM devices reject the association). Do we have any tool in FreeBSD to monitor/debug this problem between the device in question and the AP? Any other ideas? I have here a debug log of the wpa_supplicant collected in the device itself, maybe some expert has an idea what the problem could be. Thanks. 1548368340.906062: wlan0: Starting AP scan for wildcard SSID 1548368340.906260: wlan0: Determining shared radio frequencies (max len 1) 1548368340.906338: wlan0: Shared frequencies (len=0): completed iteration 1548368340.906410: wlan0: Add radio work 'scan'@0xb8a29310 1548368340.906475: wlan0: First radio work item in the queue - schedule start immediately 1548368340.906584: wlan0: Starting radio work 'scan'@0xb8a29310 after 0.99 second wait 1548368340.906834: wlan0: nl80211: scan request 1548368340.906930: nl80211: Scan SSID - hexdump_ascii(len=0): [NULL] 1548368340.908515: Scan requested (ret=0) - scan timeout 30 seconds 1548368340.908740: nl80211: Event message available 1548368340.908840: nl80211: Drv Event 33 (NL80211_CMD_TRIGGER_SCAN) received for wlan0 1548368340.908912: wlan0: nl80211: Scan trigger 1548368340.908981: wlan0: Event SCAN_STARTED (47) received 1548368340.909053: wlan0: Own scan request started a scan in 0.000342 seconds 1548368340.911945: dbus: flush_object_timeout_handler: Timeout - sending changed properties of object /fi/w1/wpa_supplicant1/Interfaces/1 1548368341.325323: RTM_NEWLINK: ifi_index=10 ifname=wlan0 wext ifi_family=0 ifi_flags=0x1003 ([UP]) 1548368341.325791: RTM_NEWLINK: ifi_index=10 ifname=wlan0 wext ifi_family=0 ifi_flags=0x1003 ([UP]) 1548368341.325972: nl80211: Event message available 1548368341.326090: nl80211: Drv Event 34 (NL80211_CMD_NEW_SCAN_RESULTS) received for wlan0 1548368341.326164: wlan0: nl80211: New scan results available 1548368341.326226: nl80211: Scan probed for SSID '' 1548368341.326302: nl80211: Scan included frequencies: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 1548368341.326366: wlan0: Event SCAN_RESULTS (3) received 1548368341.326436: wlan0: Scan completed in 0.417385 seconds 1548368341.327931: nl80211: Received scan results (6 BSSes) 1548368341.328181: wlan0: BSS: Start scan result update 17 1548368341.328675: BSS: last_scan_res_used=6/32 1548368341.328775: wlan0: New scan results available (own=1 ext=0) 1548368341.338042: WPS: AP[0] d4:21:22:e0:24:8b type=0 tries=0 last_attempt=-1 sec ago blacklist=0 1548368341.338203: WPS: AP[1] e0:28:6d:26:32:9d type=0 tries=0 last_attempt=-1 sec ago blacklist=0 1548368341.338272: WPS: AP[2] cc:ce:1e:b1:69:38 type=0 tries=0 last_attempt=-1 sec ago blacklist=0 1548368341.338334: WPS: AP[3] 10:b1:f8:fb:fb:38 type=0 tries=0 last_attempt=-1 sec ago blacklist=0 1548368341.338396: WPS: AP[4] 7c:ff:4d:7c:5c:29 type=0 tries=0 last_attempt=-1 sec ago blacklist=0 1548368341.338529: WPS: AP[5] 24:69:a5:5d:cb:5e type=0 tries=0 last_attempt=-1 sec ago blacklist=0 1548368341.338762: WPS: AP[6] 30:d3:2d:74:86:41 type=0 tries=0 last_attempt=-1 sec ago blacklist=0 1548368341.338873: wlan0: Radio work 'scan'@0xb8a29310 done in 0.432282 seconds 1548368341.338945: wlan0: Selecting BSS from priority group 0 1548368341.339039: wlan0: 0: 00:1c:4a:06:17:f5 ssid='tarara' wpa_ie_len=24 rsn_ie_len=20 caps=0x411 level=-42 1548368341.339112: wlan0:selected based on RSN IE 1548368341.339194: wlan0:selected BSS 00:1c:4a:06:17:f5 ssid='tarara' 1548368341.339303: wlan0: Considering connect request: reassociate: 0 selected: 00:1c:4a:06:17:f5 bssid: 00:00:00:00:00:00 pending: 00:00:00:00:00:00 wpa_state: SCANNING ssid=0xb8a28738 current_ssid=(nil) 1548368341.339377: wlan0: Request association with 00:1c:4a:06:17:f5 1548368341.339437: wlan0: Re-association to the same ESS 1548368341.339495: WPA: Unrecognized EAPOL-Key Key Data IE - hexdump(len=8): 00 06 74 61 72 61 72 61 1548368341.339565: WPA: Unrecognized EAPOL-Key Key Data IE - hexdump(len=3): 03 01 03 1548368341.339625: WPA: Unrecognized EAPOL-Key Key Data IE - hexdump(len=14): 05 0c 00 03 00 00 00 00 00 00 00 00 00 00 1548368341.339707: WPA: Unrecognized EAPOL-Key Key Data IE - hexdump(len=3): 2a 01 04 1548368341.339766: WPA: RSN IE in EAPOL-Key - hexdump(len=22): 30 14 01 00 00 0f ac 02 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 1548368341.339863: WPA: WPA IE in EAPOL-Key - hexdump(len=26): dd 18 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 00 00
