<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> I have attached radius server failure log messages<br>
<br>
</div>  The supplicant starts EAP, and the server responds with a request for<br>
EAP-TLS.  The supplicant NAKs it, and asks for EAP-MD5.  The server<br>
responds with EAP-MD5.<br>
<br>
  The supplicant then responds with a NAK for EAP-MD5.  This packet from<br>
the AP contains the *old* State variable from the previous NAK.<br>
<br>
  A close look at the packet traces shows that either the supplicant is<br>
re-using the old NAK (and confusing the AP), or the AP is re-using an<br>
old packet (and confusing the supplicant).<br>
<br>
  Either way, the packet traces on the server show that the server is<br>
behaving correctly.  The error message about "no matching state" is<br>
because the server has moved on to the *next* step of EAP, and it<br>
receives a packet from the *previous* step.  So there really is "no<br>
matching state".<br>
<br>
  Try using another supplicant and/or AP.  You won't be able to fix this<br>
by editing the server configuration.<br>
<font color="#888888"><br>
  Alan DeKok.<br></font></blockquote><div><br></div><div>Thanks Alan,</div><div><br></div><div>I got the problem. The Access point was corrupting the state variable and  sending same state for both the sessions.</div><div>
<br></div><div>Thanks</div><div>Rupesh</div></div>