I have a requirement to provide the reason why authentication failed. For non-EAP clients, it is easy just include Reply-Message in Access-Reject packet. But for EAP clients RFC says Reply-Message should not be sent with EAP-Message together. First I've tried to include the second EAP-Message attribute with a reason using `EAP-Message+= "error code"`. I.e. supplicant will receive first EAP-Message with reply from some "eap" module and then my custom message. At least eapol_test tool sees both attributes, but I didn't test it with end-user devices. And I've read RFC 3579 more. In §2.6.5 Displayable Messages the RFC saying "An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet." First question why it saying this? I am confused because in real life I see EAP-Message attribute in Access-Reject response EAPOL: SUPP_BE entering state RECEIVE Received 44 bytes from RADIUS server Received RADIUS message RADIUS message: code=3 (Access-Reject) identifier=8 length=44 Attribute 79 (EAP-Message) length=6 Value: 046a0004 Attribute 80 (Message-Authenticator) length=18 Value: 9f3224d1705f2e3cb32708dbea4cc348 STA 02:00:00:00:00:01: Received RADIUS packet matched with a pending request, round trip time 1.05 sec But ok, assuming this is fine, there is § 2.6.3. Conflicting Messages saying " Access-Reject packets SHOULD have only one EAP-Message attribute in them, containing EAP Failure." I bet this forbids me from using this hack EAP-Message+= "error code" I didn't find the exact wording that says if you want to include "error code" in Access-Reject reply use only EAP Notification. §2.6.5 saying "When sending a displayable message to a NAS during an EAP conversation, the RADIUS server MUST encapsulate displayable messages within EAP-Message/EAP-Request/Notification attribute(s)" But I guess this is the proper way to do it. The second question - am I, right about it? Or there is another proper way to send an error reason? If I am right about the EAP-Notification attribute can I ask to provide an example of how to do it properly? Since RFC says to use Access-Challenge for notification and then disconnect probably I can try to adapt the example site "challenge". But maybe it is overkill. All I need as I imagine is to send "Access-Challenge " from Post-Auth-Type REJECT section the first time and when the supplicant will repeat the request, send Access-Reject for the second time. -- Vladimir