Expand description
Pure EAPOL / EAP codec — IEEE 802.1X-2004 §11.3 and RFC 3748.
No I/O, no locks, no async, no state. Everything here is a total function over bytes, so
tests/server/eapol/codec_test.rs can pin it against literal specification bytes without
a socket, an interface or a privilege. That split is the point: the transport in mod.rs
is a thin shell over these functions, and the transport is the part that has never run.
§The one rule this file exists to enforce
An EAP-Success frame is an admission decision, so there is exactly one function in
this crate that can produce those bytes — eapol_eap_success_frame — and it shares no
code with eapol_eap_failure_frame. Neither takes a code, a boolean, or anything else
that could select the other. grep -rn EAP_CODE_SUCCESS src/ --include='*.rs' finds five
code sites and exactly one of them writes the octet: the constant, that one builder, the
EapPacket::decode arm, eap_code_name, and classify_frame in mod.rs. The other four
only read. A sixth site, or a second one that constructs a frame, wants careful reading.
A generic encode_eap_result(code, id) would be shorter and is precisely what must not
exist: one wrong argument, one inverted condition, and an authentication bypass is a
single character wide.
Structs§
- EapPacket
- A decoded EAP packet.
eap_typeis present only for Request and Response (RFC 3748 §4.1); Success and Failure have no type octet and are exactly four octets long (§4.2). - Eapol
Frame - An EAPOL PDU: protocol version, packet type, and the body the length field delimits.
- Ethernet
Frame - A parsed Ethernet II frame.
payloadhas any trailing pad removed only insofar as the EAPOL layer declares its own length — Ethernet itself cannot tell pad from data.
Enums§
- Codec
Error - Everything that can be wrong with a frame. Deliberately specific: an authenticator that logs “bad packet” tells an operator nothing about which of six layers failed.
Constants§
- EAPOL_
HEADER_ LEN - Protocol version (1) + packet type (1) + body length (2).
- EAPOL_
TYPE_ ASF_ ALERT - EAPOL_
TYPE_ EAP_ PACKET - EAPOL_
TYPE_ KEY - EAPOL_
TYPE_ LOGOFF - EAPOL_
TYPE_ START - EAPOL_
VERSION_ 2001 - 802.1X-2001. Still what many supplicants put on the wire.
- EAPOL_
VERSION_ 2004 - 802.1X-2004. NetGet’s default.
- EAPOL_
VERSION_ 2010 - 802.1X-2010.
- EAP_
CODE_ FAILURE - EAP_
CODE_ REQUEST - EAP_
CODE_ RESPONSE - EAP_
CODE_ SUCCESS - EAP_
HEADER_ LEN - Code (1) + identifier (1) + length (2).
- EAP_
TYPE_ IDENTITY - EAP_
TYPE_ MD5_ CHALLENGE - EAP_
TYPE_ MSCHAP V2 - EAP_
TYPE_ NAK - EAP_
TYPE_ NOTIFICATION - EAP_
TYPE_ PEAP - EAP_
TYPE_ TLS - ETHERNET_
HEADER_ LEN - Destination MAC (6) + source MAC (6) + EtherType (2).
- ETHERNET_
MIN_ FRAME_ LEN - An Ethernet frame is padded out to 60 octets before the FCS. EAPOL frames are far shorter than that, so trailing padding is the normal case and must be ignored rather than parsed.
- ETHERTYPE_
EAPOL - EtherType carrying EAPOL, IEEE 802.1X-2004 §11.3.1.
- MD5_
CHALLENGE_ LEN - RFC 1994 §2.2 recommends a challenge of at least the digest length.
- PAE_
GROUP_ ADDRESS - The PAE group address supplicants send to, IEEE 802.1X-2004 §7.8 Table 7-2.
- TLS_
FLAG_ LENGTH_ INCLUDED - EAP-TLS flag bits, RFC 5216 §3.1. Shared by PEAP (RFC 7170 §3.1 uses the same layout).
- TLS_
FLAG_ MORE_ FRAGMENTS - TLS_
FLAG_ START
Functions§
- build_
ethernet_ frame - Build an Ethernet II frame, padding the tail to the 60-octet minimum the MAC layer requires. Pad octets are zero, and the EAPOL body-length field is what lets the receiver ignore them.
- decode_
md5_ value - Split an MD5-Challenge type-data field into its value and its trailing name.
- eap_
code_ name - eap_
request_ identity EAP-Request/Identity— the first thing an authenticator says. Carries no prompt.- eap_
request_ md5_ challenge EAP-Request/MD5-Challenge— RFC 3748 §5.4, whose value field follows RFC 1994 §4.1:Value-Size (1) | Value | Name.- eap_
request_ notification EAP-Request/Notification— a displayable message, RFC 3748 §5.2. Not a decision.- eap_
request_ tls_ start EAP-Request/TLSor/PEAPcarrying only the Start flag, RFC 5216 §3.2.- eap_
response - Encode a Response body. Used by the supplicant role and by tests playing a supplicant.
- eap_
response_ identity EAP-Response/Identitycarrying a claimed identity.- eap_
type_ name - eapol_
eap_ failure_ frame - The denial. Every fail-closed path in
mod.rscalls this directly, bypassing the action executor entirely, so no model output and no error path can reach the function above. - eapol_
eap_ success_ frame - The only function in NetGet that can produce an
EAP-Success. - eapol_
logoff_ frame - An EAPOL-Logoff.
- eapol_
packet_ type_ name - eapol_
start_ frame - An EAPOL-Start, used by the supplicant role and by tests playing one.
- eapol_
wrap_ eap - Wrap an already-encoded EAP packet in an EAPOL header.
- encode_
md5_ value Value-Size (1) | Value | Name— RFC 1994 §4.1, reused by EAP-MD5-Challenge.- format_
mac - Lower-case colon-separated form, which is what every event field carries.
- md5
- RFC 1321 MD5 of a single buffer.
- md5_
challenge_ digest - RFC 1994 §2.2:
MD5(Identifier || Secret || Challenge). - md5_
response_ matches - Whether a supplicant’s MD5-Challenge response matches the digest of the expected secret.
- parse_
ethernet_ frame - parse_
mac - Accepts
aa:bb:cc:dd:ee:ff,aa-bb-cc-dd-ee-ffandaabbccddeeff, any case. - tls_
flags - Flags on an EAP-TLS/PEAP fragment, RFC 5216 §3.1, as a structured triple. Returns
Nonewhen the fragment carries no flags octet at all.