Does eapol_test lie about the data it exchanges with FreeRADIUS?

[Joe Garcia]

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.