DALE REAMER <[EMAIL PROTECTED]> 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html