On May 1, 2020, at 11:48 AM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Thanks a lot Alan, sometime ago I commented some options in eap.conf to leave just eap-mschapv2, and also applied filter attr_filter.access_challenge.post-auth to remove some attributes in access-challenge. Also think I enabled eap in authorize/auth (i think under /etc/raddb/sites-enabled/inner-tunnel). I do not think I did more. EAP was working, EAP-start is a new use case I need to support.
OK.
I have removed the access-challenge filter to check but have the same result. The full debug of the access-attmpt (0) Received Access-Request Id 5 from 10.0.87.205:64385 to 192.168.99.9:1812 length 152 (0) User-Name = "swan" (0) Acct-Session-Id = "172.172.172.40-172.20.182.6:4500-1588347078" (0) Calling-Station-Id = "172.20.182.6:4500" (0) Called-Station-Id = "172.172.172.40" (0) NAS-Port-Id = "tunnel-1.public:40" (0) NAS-Identifier = "vBNG" (0) EAP-Message = 0x
Yeah, that's a problem. The EAP peer MUST NOT send an empty EAP-Message attribute. See RFC 3579 Section 3.1. It should instead send 2 byte EAP start message. Or, more commonly, an EAP Identity. Which is what 99.999% of EAP peers do. It's not clear why you need to support EAP-Start. Perhaps explaining that may help.
Not sure if you refer to this debug.
Yes. I've pushed a fix, which will be in the next release. Alan DeKok.