HostAP & Intel Proset

[Jouni Malinen]

On Fri, Dec 17, 2004 at 10:36:49PM -0800, Lawrence Wong wrote:

> The config file that was shown earlier is indeed the
> exact config file that I used. The daemonize parameter
> doesn't seem to have any effect on my Fedora Core 3
> box:

> The description in the hostapd.conf says "daemonize"
> is used to determine forking into the background.
> Could it be a bug as it does not fork?

Aah.. This is actually a feature, i.e., the configuration file is not
supposed to be able to change the daemonizing. The bug part is that I
have not removed that configuration option and had already forgotten
about this change.. That variable is no more, so that should clear up
confusion a bit.

> EAP: EAP entering state SELECT_ACTION
> EAP: getDecision: no identity known yet -> CONTINUE
> EAP: EAP entering state PROPOSE_METHOD
> EAP: getNextMethod: type 1
> EAP: EAP entering state METHOD_REQUEST
> EAP: building EAP-Request: Identifier 103
> EAP: EAP entering state SEND_REQUEST
> EAP: eapReqData -> EAPOL - hexdump(len=5): 01 67 00 05
> 01
> EAP: EAP entering state IDLE

> IEEE 802.1X: Sending EAP Packet to 00:0c:d7:94:f1:3b
> (identifier 103)

OK, so here goes to EAP-Request/Identity from hostapd to start
authentication.

> Received 78 bytes management frame
> DATA
> IEEE 802.1X: 46 bytes from 00:0c:d7:94:f1:3b
>    IEEE 802.1X: version=1 type=1 length=0
>    ignoring 42 extra octets after IEEE 802.1X packet
> wlan0: STA 00:0c:d7:94:f1:3b IEEE 802.1X: received
> EAPOL-Start from STA

And this is EAPOL-Start from the client to start authentication.

> wlan0: STA 00:0c:d7:94:f1:3b IEEE 802.1X: aborting
> authentication
> EAP: EAP entering state SELECT_ACTION
> EAP: getDecision: no identity known yet -> CONTINUE
> EAP: EAP entering state PROPOSE_METHOD
> EAP: getNextMethod: type 1
> EAP: EAP entering state METHOD_REQUEST
> EAP: building EAP-Request: Identifier 198
> EAP: EAP entering state SEND_REQUEST
> EAP: eapReqData -> EAPOL - hexdump(len=5): 01 c6 00 05
> 01
> IEEE 802.1X: Sending EAP Packet to 00:0c:d7:94:f1:3b
> (identifier 198)

And hostapd sends another EAP-Request/Identity as a reply to this.

> Received 41 bytes management frame
> DATA (TX callback) ACK
> IEEE 802.1X: 00:0c:d7:94:f1:3b TX status - version=2
> type=0 length=5 - ack=1

The client ACKed this frame (link layer), so at least the connection
seems to be working.

> Received 26 bytes management frame
> MGMT
> mgmt::disassoc
> disassocation: STA=00:0c:d7:94:f1:3b reason_code=1
> wlan0: STA 00:0c:d7:94:f1:3b WPA: event 2 notification
> wlan0: STA 00:0c:d7:94:f1:3b IEEE 802.11:
> disassociated

However, the client did not reply to identity request and just
disassociated. Without getting debug log from the client, it is quite
difficult to guess what would be reason for this. Could you please try
the attached patch that makes EAP identity number start from zero and
not from a random starting point? It is recommended to start from a
random number, but most authentication servers do not do this. Another
possible test would be to setup an external RADIUS authentication server
and configure hostapd to use it instead of the integrated EAP
authenticator.

> One thing I did notice when testing out with the
> WPA-PSK mode is that with hostapd-0.3.1, Intel Proset
> was not able to connect (same 802.1x unauthorized
> error) while Windows XP built in client was able to.
> But with hostapd-0.2.5, both Intel Proset and Windows
> XP were able to connect just fine.

Could you please send a full debug log of hostapd from both the
successful case with 0.2.5 and failed case with 0.3.1? WPA-PSK is quite
different from IEEE 802.1X/EAP-MD5 case. Please also add one more -d to
the command line (or increment debug= variable) to include all message
dumps.

> Could it be due to some changes in the 802.1x code
> between 0.2.5 and 0.3.x that caused the errors above?

0.3.x has moved to a newer version of IEEE 802.1X standard (not yet
approved) IEEE 802.1X-REV), so there are indeed some small changes in
the EAPOL state machine behavior. Getting debug logs from both versions
running the exact same test case would be useful information.

-- 
Jouni Malinen                                            PGP id EFC895FA
-------------- next part --------------
Index: eap.c
===================================================================
RCS file: /home/jm/cvsroot/hostap/hostapd/eap.c,v
retrieving revision 1.3
diff -u -p -B -4 -r1.3 eap.c
--- eap.c	13 Dec 2004 04:13:21 -0000	1.3
+++ eap.c	18 Dec 2004 18:18:19 -0000
@@ -550,15 +550,17 @@ static u8 * eap_sm_buildFailure(struct e
 
 
 static int eap_sm_nextId(struct eap_sm *sm, int id)
 {
+#if 0
 	if (id < 0) {
 		/* RFC 3748 Ch 4.1: recommended to initalize Identifier with a
 		 * random number */
 		id = rand() & 0xff;
 		if (id != sm->lastId)
 			return id;
 	}
+#endif
 	return (id + 1) & 0xff;
 }