I've been debugging an embedded RADIUS client, specifically one that does PEAP auth, using eapol_test, or at least trying to, however I can't see how it could work using the messages it claims to be exchanging with FreeRADIUS. In particular eapol_test claims it replies to the initial identity request with an EAP, not PEAP, message: EAP-PEAP: Encrypting Phase 2 data - hexdump(len=12): 02 a5 00 0c 01 74 65 73 74 33 32 31 when it should be just PEAP, 01 74 65 73 74 33 32 31. Looking at the FreeRADIUS code that handles this (3.2.x, the current version shipping with various Linux distros), src/modules/rlm_eap/types/ rlm_eap_peap:eappeap_process() calls eapmessage_verify() which, for an EAP Response (type = 2) only allows an EAP-TLV and nothing else, in particular not an EAP Identity message as eapol_test claims it's sending. I've verified this by sending the message that eapol_test claims it's sending and getting: eap_peap: Received unexpected EAP-Response, rejecting the session. eap_peap: ERROR: Tunneled data is invalid which is exactly what you'd expect from the code in eapmessage_verify(). So does eapol_test invisibly convert messages to and from EAP/PEAP format when communicating with FreeRADIUS and report the EAP form while using the PEAP form? Further evidence in support of this is what it reports on read of a PEAP Identity Request: EAP-PEAP: Decrypted Phase 2 EAP - hexdump(len=1): 01 EAP-PEAP: received Phase 2: code=1 identifier=165 length=5 The first line reports it's read a PEAP message (which is indeed what's being sent) and on the second line it's magically converted itself into an EAP message, which isn't actually sent. Does this mean that eapol_test is an unreliable source of information when it comes to debugging auth issues? JG.