When using freeradius with wpa_supplicant I have noticed freeradius does not bump the EAP id when sending back the Access-Accept packet. wpa_supplicant notices this and has a work around. Will the WPA drop this packet (it is important because it has the keys in the attributes). Has anyone reported this bug? The reason I ask is because after receiving the accept packet, wpa_supplicant goes into AUTHENTICATED state but cannot connect to the network, or associate. Any ideas? the wpa_supplicant (last part) trace: WPA: Sending EAPOL-Key 2/4 RX EAPOL from 00:0f:b5:7a:17:bc EAPOL: Ignoring WPA EAPOL-Key frame in EAPOL state machines IEEE 802.1X RX: version=1 type=3 length=119 EAPOL-Key type=254 WPA: RX message 3 of 4-Way Handshake from 00:0f:b5:7a:17:bc (ver=1) WPA: IE KeyData - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 01 WPA: No WPA/RSN IE for this AP known. Trying to get from scan results WPA: Found the current AP from updated scan results WPA: Sending EAPOL-Key 4/4 WPA: Installing PTK to the driver. WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 RX EAPOL from 00:0f:b5:7a:17:bc EAPOL: Ignoring WPA EAPOL-Key frame in EAPOL state machines IEEE 802.1X RX: version=1 type=3 length=127 EAPOL-Key type=254 WPA: RX message 1 of Group Key Handshake from 00:0f:b5:7a:17:bc (ver=1) WPA: Group Key - hexdump(len=32): [REMOVED] WPA: Installing GTK to the driver (keyidx=1 tx=0). WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 WPA: Sending EAPOL-Key 2/2 WPA: Key negotiation completed with 00:0f:b5:7a:17:bc [PTK=TKIP GTK=TKIP] Cancelling authentication timeout Removed BSSID 00:0f:b5:7a:17:bc from blacklist EAPOL: External notification - portValid=1 EAPOL: SUPP_PAE entering state AUTHENTICATED Signal 2 received - terminating ndis_get_oid: oid=0xd010101 len (6) failed ndis_set_oid: oid=0xd010114 len (4) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_set_oid: oid=0xd010114 len (4) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_set_oid: oid=0xd010114 len (4) failed ndis_get_oid: oid=0xd010101 len (6) failed ndis_set_oid: oid=0xd010114 len (4) failed EAPOL: External notification - portEnabled=0 EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portValid=0 wpa_driver_ndis_set_wpa: enabled=0 No keys have been configured - skip key clearing rmdir[ctrl_interface]: No such file or directory EAP: deinitialize previously used EAP method (25, PEAP) at EAP deinit the freeradius (last part trace): ending Access-Challenge of id 12 to 192.168.0.229:1075 EAP-Message = 0x010c00501900170301002028f83aa4e802c2965c29685e7521a11ea189ad707d72f340478950afc820a3dd1703010020c159819f4919952b824a4c2e7d71d92338cfeb7e35842ecca2590d0ec5e9a91f Message-Authenticator = 0x00000000000000000000000000000000 State = 0xed25ce47ac6c8028e663a2f6f53414e7 rad_recv: Access-Request packet from host 192.168.0.229:1075, id=13, length=251 Message-Authenticator = 0x508b7cdf35912a2b07a9f6f461200076 Service-Type = Framed-User User-Name = "dreamer" Framed-MTU = 1488 State = 0xed25ce47ac6c8028e663a2f6f53414e7 Called-Station-Id = "000FB57A17BC:NETGEAR" Calling-Station-Id = "00070EB38E2D" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 54Mbps 802.11g" EAP-Message = 0x020c005019001703010020d636529b1ced029a7bc635638d3d21e9e6eeff64ba0e2bbdae2f362655442a601703010020653e43e16142b6e7535d53a7306aad5bc40cf157a9fa7f38c067a870a649c184 NAS-IP-Address = 192.168.0.229 NAS-Port = 1 NAS-Port-Id = "STA port # 1" Sending Access-Accept of id 13 to 192.168.0.229:1075 MS-MPPE-Recv-Key = 0x2ae009c01dc4c8af6bbf63b3a03eae0bf36d5f74277cd979e0aab0c7c0208b00 MS-MPPE-Send-Key = 0xed2e0e7f8242205404cecb7894a82d742f43a225b2f1ddae8231128e413f00ec EAP-Message = 0x030c0004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "dreamer"
DALE REAMER <dale_reamer@prodigy.net> wrote:
When using freeradius with wpa_supplicant I have noticed freeradius does not bump the EAP id when sending back the Access-Accept packet. wpa_supplicant notices this and has a work around. Will the WPA drop this packet (it is important because it has the keys in the attributes). Has anyone reported this bug?
It's not a bug in FreeRADIUS. See the following dicussion on the EAP working group, which is defining these standards. http://mail.frascone.com/pipermail/eap/2004-December/003069.html ...
Section 4.1 is about Requests and Responses, it does not cover EAP-Success. However, now that I looked again more closely, there is actually text in section 4.2 that seems to cover this:
Identifier
The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Identifier field of the Response packet that it is sent in response to.
(this is for Success and Failure)
In other words, there are existing EAP authenticators that do not match the behavior defined in RFC 3748 and draft-ietf-eap-statemachine-05.txt. RFC 2284 seemed to have the same text, so this is not even a new requirement.
For a suggest fix, that would apply to wpa_supplicant, see: http://mail.frascone.com/pipermail/eap/2004-December/003071.html
OK. In order to limit the effect, the workaround could be changed to be (reqId == lastId) || (reqId == (lastId + 1) & 0xff) which seems to cover all the EAP implementations I have seen in RADIUS authentication servers.
Hope this helps. Alan DeKok.
Thanks. What I did was to go the link you gave and from that information set the wpa_supplicant.conf to eap_workaround=0. Now I am connecting to the network. Since freeradius implements the protocol correctly it might be a good to turn off the workarounds; worked for me. dale_reamer@prodigy.net Alan DeKok <aland@ox.org> wrote:DALE REAMER wrote:
When using freeradius with wpa_supplicant I have noticed freeradius does not bump the EAP id when sending back the Access-Accept packet. wpa_supplicant notices this and has a work around. Will the WPA drop this packet (it is important because it has the keys in the attributes). Has anyone reported this bug?
It's not a bug in FreeRADIUS. See the following dicussion on the EAP working group, which is defining these standards. http://mail.frascone.com/pipermail/eap/2004-December/003069.html ...
Section 4.1 is about Requests and Responses, it does not cover EAP-Success. However, now that I looked again more closely, there is actually text in section 4.2 that seems to cover this:
Identifier
The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Identifier field of the Response packet that it is sent in response to.
(this is for Success and Failure)
In other words, there are existing EAP authenticators that do not match the behavior defined in RFC 3748 and draft-ietf-eap-statemachine-05.txt. RFC 2284 seemed to have the same text, so this is not even a new requirement.
For a suggest fix, that would apply to wpa_supplicant, see: http://mail.frascone.com/pipermail/eap/2004-December/003071.html
OK. In order to limit the effect, the workaround could be changed to be (reqId == lastId) || (reqId == (lastId + 1) & 0xff) which seems to cover all the EAP implementations I have seen in RADIUS authentication servers.
Hope this helps. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
DALE REAMER