eap id bug

[Alan DeKok]

DALE REAMER <dale_reamer at prodigy.net> wrote:
> When using freeradius with wpa_supplicant I have noticed freeradius
> does not bump the EAP id when sending back the Access-Accept
> packet. wpa_supplicant notices this and has a work around. Will the
> WPA drop this packet (it is important because it has the keys in the
> attributes). Has anyone reported this bug?

  It's not a bug in FreeRADIUS.  See the following dicussion on the
EAP working group, which is defining these standards.

http://mail.frascone.com/pipermail/eap/2004-December/003069.html
...
> Section 4.1 is about Requests and Responses, it does not cover
> EAP-Success. However, now that I looked again more closely, there is
> actually text in section 4.2 that seems to cover this:
>
>   Identifier
>
>      The Identifier field is one octet and aids in matching replies to
>      Responses.  The Identifier field MUST match the Identifier field
>      of the Response packet that it is sent in response to.
>
> (this is for Success and Failure)
>
> In other words, there are existing EAP authenticators that do not match
> the behavior defined in RFC 3748 and draft-ietf-eap-statemachine-05.txt.
> RFC 2284 seemed to have the same text, so this is not even a new
> requirement.

  For a suggest fix, that would apply to wpa_supplicant, see:

http://mail.frascone.com/pipermail/eap/2004-December/003071.html

> OK. In order to limit the effect, the workaround could be changed to be
> (reqId == lastId) || (reqId == (lastId + 1) & 0xff) which seems to cover
> all the EAP implementations I have seen in RADIUS authentication
> servers. 

  Hope this helps.

  Alan DeKok.