How to force EAP-Identity Request sending after EAP START
aland at deployingradius.com
Fri May 1 18:02:12 CEST 2020
On May 1, 2020, at 11:48 AM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users at 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.
> 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 = "126.96.36.199-172.20.182.6:4500-1588347078"
> (0) Calling-Station-Id = "172.20.182.6:4500"
> (0) Called-Station-Id = "188.8.131.52"
> (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.
I've pushed a fix, which will be in the next release.
More information about the Freeradius-Users