How to force EAP-Identity Request sending after EAP START

[Alan DeKok]

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.

  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.