EAPOL Key Timeout

GruensFroeschli

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.

namezero111111

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…

namezero111111

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?

remlei

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.

namezero111111

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.

mastablastaz

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

lada04

@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.

stephenw10

Still running an ALIX board?

I would put OpenWRT on there to be honest. Get real driver support at the same time.

lada04

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.

stephenw10

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!

https://openwrt.org/toh/pcengines/alix