(2012/10/31 4:36), Sam Hartman wrote:
Alan implied that when the eap stack fails to produce an answer the RADIUS server doesn't have anything else to do.
This is not always the case. See the following text in Section 2.2 of RFC 3579:
" A RADIUS server determining that a non-fatal error has occurred MAY send an Access-Challenge to the NAS including EAP-Message attribute(s) as well as an Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet (Ignored)". The Access-Challenge SHOULD encapsulate within EAP-Message attribute(s) the most recently sent EAP-Request packet (including the same Identifier value). On receiving such an Access-Challenge, a NAS implementing previous versions of this specification will decapsulate the EAP-Request and send it to the peer, which will retransmit the EAP-Response. A NAS compliant with this specification, on receiving an Access-Challenge with an Error-Cause attribute of value 202 (decimal) SHOULD discard the EAP-Response packet most recently transmitted to the RADIUS server and check whether additional EAP-Response packets have been received matching the current Identifier value. If so, a new EAP-Response packet, if available, MUST be sent to the RADIUS server within an Access-Request, and the EAP-Message attribute(s) included within the Access-Challenge are silently discarded. If no EAP-Response packet is available, then the EAP-Request encapsulated within the Access-Challenge is sent to the peer, and the retransmission timer is reset. " Yoshihiro Ohba
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
