EAPOL Key Timeout
-
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 :}
Since you're on _wlan3, are you using multiple virtual BSSIDs?
Yes, _wlan1 is WPA2 EAP/TLS with Radius
_wlan2 is UnprotectedWhich frequency are you using?
2.4Ghz Channel 11
Are you on a DFS channel?
No, the radio runs on 2.4Ghz
802.11g Channel 11, no OFDM -
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-timeoutpciconf -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 = networkSo 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 -
@mastablastaz I know its long ago, but I currently have the same issue on 2.3.5 (there is no newer version for i386 architecture) with multiple wireless networks on the same card:
vendor = 'Qualcomm Atheros' device = 'AR5212/5213/2414 Wireless Network Adapter'with 3 networks: 1) AP (native), 2) client, 3) AP (guest network).
While 1) and 2) work, 3) shows the described behaviour. Have you found a solution or workaround?Thanks.
-
Still running an ALIX board?
I would put OpenWRT on there to be honest. Get real driver support at the same time.
-
Yes, I still have two alix2d3 runnig, very reliable, until recently with pfsense 2.2.6, the config became rather complex over the years, and there were never hardware or driver issues... I'll have a look on OpenWRT though.
-
Mmm, it won't be an easy config conversion but you would at least get current code, security fixes etc.
And, yes, the ALIX was/is pretty much indestructible!
