I'm referring to identifier in the inner (tunneled) one. So once EAP-TLS is successfully over, Juniper SBR sends proposal for EAP-GTC with identifier value 2, in response wpa_supplicant sends legacy NAK with EAP-MSCHAPv2 as a supported method, and then Juniper SBR proposes EAP-MSCHAPv2 with identifier value 2 again. In spite of same identifier value i.e. 2 in two consecutive EAP frames from SBR, wpa_supplicant accomplishes EAP-MSCHAPv2 successfully.<br>
<br>- Paul<br><br><br><div class="gmail_quote">On Sat, Sep 25, 2010 at 12:19 AM, paul peterson <span dir="ltr"><<a href="mailto:paul.petersn@gmail.com">paul.petersn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>I'm trying to perform EAP-PEAPv1 authentication using Juniper SBR. I have EAP-GTC disabled in wpa_supplicant, so in phase-2 when wpa_supp receives EAP-GTC proposal, it sends legacy NAK with method MSCHAPv2. In response SBR sends a new proposal for MSCHAPv2 but with same identifier value as in the last EAP frame. I see wpa_supplicant does not have any check to see if the identifier value matches with the one in the last frame received during the EAP-PEAP second stage. Is this correct to skip the check ?<br>
<font color="#888888">
<br><br>- Paul<br>
</font></blockquote></div><br>