EAPOL Key Timeout



  • Dear folks, on pfsense 2.3.5_1 with a Compex Atheros card, I am unable to use a WPA-PSK setup.

    AA:AA:AA:AA:AA:AA = Client
    BB:BB:BB:BB:BB:BB = PFSense

    The logs show the following:

    Jan 17 12:08:15 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: PTKSTART: Retry limit 4 reached
    Jan 17 12:08:15 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: EAPOL-Key timeout
    Jan 17 12:08:14 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: sending 1/4 msg of 4-Way Handshake
    Jan 17 12:08:14 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: EAPOL-Key timeout
    Jan 17 12:08:13 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: sending 1/4 msg of 4-Way Handshake
    Jan 17 12:08:13 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: EAPOL-Key timeout
    Jan 17 12:08:12 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: sending 1/4 msg of 4-Way Handshake
    Jan 17 12:08:12 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: EAPOL-Key timeout
    Jan 17 12:08:11 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: sending 1/4 msg of 4-Way Handshake
    Jan 17 12:08:11 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA IEEE 802.1X: unauthorizing port
    Jan 17 12:08:11 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: start authentication
    Jan 17 12:08:11 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA WPA: event 1 notification
    Jan 17 12:08:11 hostapd ath0_wlan3: STA AA:AA:AA:AA:AA:AA IEEE 802.11: associated

    However, tcpdump shows that the client is acutally reaplying on the inferface

    tcpdump: listening on ath0_wlan3, link-type EN10MB (Ethernet), capture size 65535 bytes
    12:35:01.053827 90:a4:de:DD:EE:FF > AA:AA:AA:AA:AA:AA, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v2, len 95
    12:35:01.062013 AA:AA:AA:AA:AA:AA > BB:BB:BB:BB:BB:BB, ethertype EAPOL (0x888e), length 135: EAPOL key (3) v1, len 117
    12:35:02.055923 90:a4:de:DD:EE:FF > AA:AA:AA:AA:AA:AA, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v2, len 95
    12:35:02.058724 AA:AA:AA:AA:AA:AA > BB:BB:BB:BB:BB:BB, ethertype EAPOL (0x888e), length 135: EAPOL key (3) v1, len 117
    12:35:03.058374 90:a4:de:DD:EE:FF > AA:AA:AA:AA:AA:AA, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v2, len 95
    12:35:03.063017 AA:AA:AA:AA:AA:AA > BB:BB:BB:BB:BB:BB, ethertype EAPOL (0x888e), length 135: EAPOL key (3) v1, len 117
    12:35:04.060143 90:a4:de:DD:EE:FF > AA:AA:AA:AA:AA:AA, ethertype EAPOL (0x888e), length 113: EAPOL key (3) v2, len 95
    12:35:04.062959 AA:AA:AA:AA:AA:AA > BB:BB:BB:BB:BB:BB, ethertype EAPOL (0x888e), length 135: EAPOL key (3) v1, len 117

    Hostapd version reports 2.0; this setup works on 2.0.1 with hostapd 0.6.8.

    The generated hostapd config file looks as follows:

    interface=ath0_wlan3
    driver=bsd
    logger_syslog=-1
    logger_syslog_level=0
    logger_stdout=-1
    logger_stdout_level=0
    dump_file=/tmp/hostapd_ath0_wlan3.dump
    ctrl_interface=/var/run/hostapd
    ctrl_interface_group=wheel
    #accept_mac_file=/tmp/hostapd_ath0_wlan3.accept
    #deny_mac_file=/tmp/hostapd_ath0_wlan3.deny
    #macaddr_acl=
    ssid=Lalaland
    debug=
    wpa=2
    wpa_key_mgmt=WPA-PSK
    wpa_pairwise=CCMP
    wpa_group_rekey=60
    wpa_gmk_rekey=3600
    wpa_strict_rekey=
    wpa_passphrase=aaaa1111
    

    Could anyone please shed some light on this?



  • 11:11:11:11:11:11 is a multicast address
    Don't use this for anything ever unless you know what you are doing.



  • Thank you, edited bogus MACs to not reflect multicast address.



  • Really?
    Obfuscating MAC addresses?



  • Since you're on _wlan3, are you using multiple virtual BSSIDs?
    Which frequency are you using?
    Are you on a DFS channel?



  • Thanks, froeschli :}

    @GruensFroeschli:

    Since you're on _wlan3, are you using multiple virtual BSSIDs?

    Yes, _wlan1 is WPA2 EAP/TLS with Radius
    _wlan2 is Unprotected

    @GruensFroeschli:

    Which frequency are you using?

    2.4Ghz Channel 11

    @GruensFroeschli:

    Are you on a DFS channel?

    No, the radio runs on 2.4Ghz
    802.11g Channel 11, no OFDM


  • Rebel Alliance Global Moderator

    Why do people continue to fight this.. The wireless support in freebsd is just crap… I you want wifi, get an AP or APs and be done with it... All the time spent looking into this stuff is waste of time for the cost of an AP.. so less than $100 for something decent that does vlans, etc. etc. Does AC at both 2.4 and 5, etc.  And even supports DFS channels as well.  Plus all kinds of other bells and whistles airtime fairness..

    Vs whatever bs you can get freebsd to do with some wifi card.

    There is one thing if you want to do this as a hobby - is that the case and you want to just do it because "you can"?



  • I tend to agree with johnpoz.

    If you want to continue to debug this:
    Log in via SSH, kill the hostapd process and start it again by hand.
    Add -ddd as argument, to get more debug output.

    I do know that with multiple virtual interfaces, in certain combination the EAPOL frames are sent on the wrong interface.



  • Thanks for the -ddd hint.
    I just ran and will analyze the output.

    I suspect something awry "internally" due to the EAPOL replies seen on the "wire".

    I also agree with both of you, but there are good (and some historical) reasons here; however it's not just one pfsense that happens to be access point too, it's a number of outstations…



  • Unfortunately, the -ddd output create no additional info.
    I suppose it makes sense, because hostapd never sees the reply packet.

    It is visible on tcpdump on interface ath0_wlan3, but not on bridge2 or vr0_vlan4.
    Maybe that is why hostapd never sees the message?

    Filtering disable, as well as setting net.link.bridge.pfil_member / net.link.bridge.pfil_bridge make no difference either.

    Somehow the bridge "swallows" the EAPOL packages.

    Any idea why that would be?



  • this is also a issue on openwrt/dd-wrt with atheros drivers. and only affects legacy devices.

    the only real fix here is use the official binary drivers from atheros, for wrt to only real fix is to reflash it with oem firmware.

    my advice is, just buy a AP, that will save you a lot of headache. not unless your upgrade all your client devices with a newer chipset which also fixes the EAPOL issue.



  • Thanks remlei, I came across that, too.

    I think if we can't make this work on 2.3 we'll have to stay with 2.0/ 2.1 until we can upgrade the hardware at remote sites.

    If we stumble into a solution we'll of course post here.



  • I think I also have this issue:
    https://forum.netgate.com/topic/134089/2-3-5-not-able-to-connect-via-wpa2-handshake-1-4-eapol-key-timeout

    pciconf -lv

    ath0@pci0:0:17:0: class=0x028000 card=0x2096168c chip=0x0029168c rev=0x01 hdr=0x00
    vendor = 'Qualcomm Atheros'
    device = 'AR922X Wireless Network Adapter'
    class = network

    So I believe the issue occurs on an Atheros wifi card when having multiple virtual network interfaces on the same network port.
    The first one (hardware network port) will work. The others won't work


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy