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);
[...]
eapol_sm_step(sta->eapol_sm);
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.
case IEEE802_1X_TYPE_EAPOL_START:
[...]
sta->eapol_sm->auth_pae.eapolStart = TRUE;
sta->eapol_sm->dot1xAuthEapolStartFramesRx++;
eapol_sm_step(sta->eapol_sm);
this happens just for EAPOL_START frames. for generic EAP frames we have:
case IEEE802_1X_TYPE_EAP_PACKET:
[...]
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
contribution.
leonardo.
--
GPG fingerprint = 2C20 A587 05AC 42E5 1292 D0D4 3EED CFB5 52FD AD1E
More information about the Hostap
mailing list