understanding the code.

leonardo billtorvalds1
Wed Nov 24 23:25:24 PST 2004

* Saturday 20 November 2004, alle 09:10, Gunter Burchardt scrive:
> On 2004-11-19 - 20:54:37, leonardo wrote:
> > I need to understand if I interpreted the code in a correct way: when a
> > frame is received it is handled by handle_frame(), if it's a data packet
> > it passes through handle_data() and then, if it's a EAP packet it goes to
> > ieee802_1x_receive(). If it's a EAPOL packet it will interfere with EAPOL
> > state machine, otherwise if it's a EAP packet we have to forward it to
> > RADIUS right? 
> >
> > something I don't understand it's why it handle just "eap response"
> > packet and not every EAP packet, then in handle_eap_response() I can't see
> > how that packet is treated, there's no direct call to any radius function.
> > is it handled by the state machine in the main loop?

there's a copuple of things I miss.. 

main initializes one interface.hapd[i] for phisical interface (just one
for me). this calls init_driver_hostap() which calls driver_init() which calls
init_sockets() which increments eloop.readers_count. So we have one
eloop.reader[] for interface, and one eloop.reader[].sock to listen to.
in eloop_run() we whatch this socket and pass the data it receives to the
correct handler. right?

upon receival of a frame handlers call each other untill we get 
to 802_1x_receive() that does this:

sta = ap_get_sta(hapd, sa);

so we have an authenticator state machine for every station, and a new
station is initialized with hostapd_new_assoc_sta(), which I guess it is
exectued at the moment of a new association. 

back to EAPOL sm: the authenticator state machine (which I
suppose is the one specified in the standard) changes from the
connecting to the authenticating state when it receives EAPOL-Start frame.

		sta->eapol_sm->auth_pae.eapolStart = TRUE;

this happens just for EAPOL_START frames. for generic EAP frames we have:

        handle_eap(hapd, sta, (u8 *) (hdr + 1), datalen);

in handle_eap(), as I said before we have:

switch (eap->code) {
00712         case EAP_CODE_REQUEST:
00713                 HOSTAPD_DEBUG(HOSTAPD_DEBUG_MINIMAL, " (request)\n");
00714                 return;
00715         case EAP_CODE_RESPONSE:
00716                 HOSTAPD_DEBUG(HOSTAPD_DEBUG_MINIMAL, " (response)\n");
00717                 handle_eap_response(hapd, sta, eap, (u8 *) (eap + 1), eap_len);
00718                 break;
00719         case EAP_CODE_SUCCESS:
00720                 HOSTAPD_DEBUG(HOSTAPD_DEBUG_MINIMAL, " (success)\n");
00721                 return;
00722         case EAP_CODE_FAILURE:
00723                 HOSTAPD_DEBUG(HOSTAPD_DEBUG_MINIMAL, " (failure)\n");
00724                 return;
00725         default:
00726                 HOSTAPD_DEBUG(HOSTAPD_DEBUG_MINIMAL, " (unknown code)\n");
00727                 return;

which means that we handle EAP_RESPONSES and we don't do anything on
everything else. in handle_eap_response() we set a few parameters on the
sm but we don't make it run, neither we send any RADIUS packet. I guess
the RADIUS packet is sent (shouldn't we forward EAP packets to
authentication server?) afterwards when something which I still don't know
makes the sm run.

so the question remains: why do we handle just EAP_RESPONSE packets? what
do we do with the rest? 

some more: when we initialize a new sm we pass from the states
initialize->disconnected->restart->connecting almost withouth
intervention. to pass to the authenticating state we need eapReq=1 and
I can't see where this is set, since in the code we just set eapolStart.

thanks everybody for attention, I hope I'll soon pay back with some

GPG fingerprint = 2C20 A587 05AC 42E5 1292  D0D4 3EED CFB5 52FD AD1E

More information about the Hostap mailing list