<DIV>    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.</DIV>
<DIV> </DIV>
<DIV><A href="mailto:dale_reamer@prodigy.net">dale_reamer@prodigy.net</A></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR><BR><B><I>Alan DeKok <aland@ox.org></I></B> wrote:
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">DALE REAMER <DALE_REAMER@PRODIGY.NET>wrote:<BR>> When using freeradius with wpa_supplicant I have noticed freeradius<BR>> does not bump the EAP id when sending back the Access-Accept<BR>> packet. wpa_supplicant notices this and has a work around. Will the<BR>> WPA drop this packet (it is important because it has the keys in the<BR>> attributes). Has anyone reported this bug?<BR><BR>It's not a bug in FreeRADIUS. See the following dicussion on the<BR>EAP working group, which is defining these standards.<BR><BR>http://mail.frascone.com/pipermail/eap/2004-December/003069.html<BR>...<BR>> Section 4.1 is about Requests and Responses, it does not cover<BR>> EAP-Success. However, now that I looked again more closely, there is<BR>> actually text in section 4.2 that seems to cover this:<BR>><BR>> Identifier<BR>><BR>> The Identifier field is one octet!
  and aids
 in matching replies to<BR>> Responses. The Identifier field MUST match the Identifier field<BR>> of the Response packet that it is sent in response to.<BR>><BR>> (this is for Success and Failure)<BR>><BR>> In other words, there are existing EAP authenticators that do not match<BR>> the behavior defined in RFC 3748 and draft-ietf-eap-statemachine-05.txt.<BR>> RFC 2284 seemed to have the same text, so this is not even a new<BR>> requirement.<BR><BR>For a suggest fix, that would apply to wpa_supplicant, see:<BR><BR>http://mail.frascone.com/pipermail/eap/2004-December/003071.html<BR><BR>> OK. In order to limit the effect, the workaround could be changed to be<BR>> (reqId == lastId) || (reqId == (lastId + 1) & 0xff) which seems to cover<BR>> all the EAP implementations I have seen in RADIUS authentication<BR>> servers. <BR><BR>Hope this helps.<BR><BR>Alan DeKok.<BR>- <BR>List info/subscribe/unsubscribe? See
 http://www.freeradius.org/list/users.html<BR></BLOCKQUOTE></DIV>