eap Mailing List: RE: Issue 204: Peer-to-peer operation

[Pasi.Eronen (Pasi.Eronen]

Jim Burns wrote:
>
> Our original assumption in the design of the .1X/EAP state machines
> was that EAP was a functional entity that could have multiple
> instantiations, one for each state machine.  So, the current .1X
> design delivers the EAP frame once to each EAP machine (which looks
> like two deliveries of the same frame if there is a single EAP
> mux/demux layer).
> 
> The .1X transport does not filter the frames as EAP peer frames and
> EAP authenticator frames because there is no indication in the EAPOL
> header of the type of EAP frame being carried and their is no logic
> in .1X which is related to the EAP header.
> 
> So, we need to answer the question: Is their a single EAP layer
> above the lower layer transport that does mux/demux?  Does the EAP
> layer assume there is a single channel to the lower layer transport
> or one for each of its EAP's state machine?

The current versions of EAP state machines don't mind if all EAP
frames are delivered to both state machines. The EAP Peer state
machine ignores all EAP Responses (by setting eapNoResp to TRUE), 
and EAP Authenticator state machine ignores EAP Requests, Successes
and Failure (by setting eapNoReq to TRUE).

Adding a "EAP demultiplexing layer" somewhere might be more
elegant than delivering the frames twice, but personally I could 
live with the current approach (especially since these state 
machines specify only externally visible behavior, not 
implementation).

Best regards,
Pasi