Thanks. What I did was to go the link you gave and from that information set the wpa_supplicant.conf to eap_workaround=0. Now I am connecting to the network. Since freeradius implements the protocol correctly it might be a good to turn off the workarounds; worked for me. dale_reamer@prodigy.net Alan DeKok <aland@ox.org> wrote:DALE REAMER 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