Problems making WPA work with ndiswrapper/ipw2100 and a 3Com AP
Kamil Iskra
kamil.89050
Sun Aug 22 12:01:18 PDT 2004
On Wed, Aug 18, 2004 at 20:52:39 -0700, Jouni Malinen wrote:
> > I've reported something that looks like a similar problem, see my mail
> > "wpa_supplicant does not work with a 3Com access point" sent on Jul 22
> > (http://lists.shmoo.com/pipermail/hostap/2004-July/007384.html).
> It looks like you were able to associate with the AP, so the issue looks
> quite a bit different from the one in this email thread. Dropping of the
> EAPOL-Start frame is expected with WPA-PSK. However, wpa_supplicant
> debug log did not show any EAPOL-Key frames from the AP. I would like to
> see a wireless sniffer log of this kind of problem to verify whether the
> AP is actually sending out EAPOL-Key frames after association (in which
> case the driver for ndiswrapper would be dropping the frames for some
> reason).
Sorry for the delay. It took me a few days to arrange for another wireless
card to do the sniffing.
I've never done wireless sniffing before, but from the output I gather that
no EAPOL frames are ever sent. The association goes OK, but nothing
happens afterwards. Here's the compact text output from ethereal:
No. Time Source Destination Protocol Info
681 16.892573 Intel_0d:de:5c 3comEuro_a8:79:53 IEEE 802.11 Authentication
682 16.892818 Intel_0d:de:5c (RA) IEEE 802.11 Acknowledgement
683 16.893321 3comEuro_a8:79:53 Intel_0d:de:5c IEEE 802.11 Authentication
684 16.893554 3comEuro_a8:79:53 (RA) IEEE 802.11 Acknowledgement
685 16.894604 Intel_0d:de:5c 3comEuro_a8:79:53 IEEE 802.11 Association Request
686 16.894833 Intel_0d:de:5c (RA) IEEE 802.11 Acknowledgement
687 16.896514 3comEuro_a8:79:53 Intel_0d:de:5c IEEE 802.11 Association Response
688 16.896747 3comEuro_a8:79:53 (RA) IEEE 802.11 Acknowledgement
689 16.899604 Intel_0d:de:5c 3comEuro_a8:79:53 IEEE 802.11 Dissassociate
690 16.899849 Intel_0d:de:5c (RA) IEEE 802.11 Acknowledgement
The association response from the AP has status set to success. As you can
see, in this case the next thing my Intel 2100 card does is to
dissassociate, or, in some cases, send a "Null function" packet. No
further meaningful communication takes place.
The relevant part of wpa_supplicant debug output is below:
Starting AP scan (broadcast SSID)
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=0 idleWhile=0
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=0 idleWhile=0
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=0 idleWhile=0
Scan timeout - try to get results
Received 593 bytes of scan results (3 BSSes)
Scan results: 3
Selecting BSS from priority group 5
0: 00:10:a7:27:d3:8a ssid='Thakoersingh' wpa_ie_len=0 rsn_ie_len=0
skip - no WPA/RSN IE
1: 00:04:e2:a8:8a:85 ssid='SMC' wpa_ie_len=0 rsn_ie_len=0
skip - no WPA/RSN IE
2: 00:0d:54:a8:79:53 ssid='3Com' wpa_ie_len=24 rsn_ie_len=0
selected
Trying to associate with 00:0d:54:a8:79:53 (SSID='3Com' freq=2432 MHz)
Cancelling scan request
WPA: using IEEE 802.11i/D3.0
WPA: Own WPA IE - 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 02
Setting authentication timeout: 5 sec 0 usec
EAPOL: External notification - EAP success=0
EAPOL: External notification - EAP fail=0
EAPOL: External notification - portControl=Auto
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=0 idleWhile=0
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=0 idleWhile=0
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=0 idleWhile=0
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=0 idleWhile=0
Wireless event: cmd=0x8c02 len=127
Custom wireless event:
'ASSOCINFO(ReqIEs=000433436f6d010482848b96dd180050f20101000050f20201000050f20201000050f2020000
RespIEs=010482840b16)'
Association info event
req_ies - hexdump(len=38): 00 04 33 43 6f 6d 01 04 82 84 8b 96 dd 18 00 50 f2 01 01 00 00 50 f2 02
01 00 00 50 f2 02 01 00 00 50 f2 02 00 00
assoc_wpa_ie - hexdump(len=26): dd 18 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2
02 00 00
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:0d:54:a8:79:53
Association event - clear replay counter
Associated to a new BSS: BSSID=00:0d:54:a8:79:53
EAPOL: External notification - portValid=0
EAPOL: External notification - EAP success=0
EAPOL: External notification - portEnabled=1
EAPOL: SUPP_PAE entering state CONNECTING
EAPOL: txStart
WPA: drop TX EAPOL in non-IEEE 802.1X mode (type=1 len=0)
EAPOL: SUPP_BE entering state IDLE
EAP: EAP entering state INITIALIZE
EAP: EAP entering state IDLE
Setting authentication timeout: 10 sec 0 usec
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=29 idleWhile=59
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=28 idleWhile=58
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=27 idleWhile=57
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=26 idleWhile=56
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=25 idleWhile=55
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=24 idleWhile=54
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=23 idleWhile=53
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=22 idleWhile=52
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=21 idleWhile=51
EAPOL: Port Timers tick - authWhile=0 heldWhile=0 startWhen=20 idleWhile=50
Authentication with 00:0d:54:a8:79:53 timed out.
This is with wpa_supplicant 0.2.4 and the latest ndiswrapper 0.10. I
didn't want to flood the list with the overly long and largely irrelevant
log files, but the whole logs are available on my webpage:
http://carol.science.uva.nl/~kamil/wpa/ (files with names beginning with ndiswrapper)
You can find there the ethereal sniff log and the complete output of
wpa_supplicant.
> I haven't tried Intel 2100 card with ndiswrapper, so I do not know what
> to expect with it as far as WPA is concerned.
Unfortunately, I do not know either. I don't have access to any other
WPA-capable APs or client cards, so I can't verify who is to blame here.
> > I can add that I was a bit more successful with linuxant and a very old
> > version of wpa_supplicant that I found on
> > http://people.zoy.org/~hpreg/wifi/, apparently built from some
> > alpha-version wpa_supplicant-lnxt2003121400.tar.gz. According to
> > wpa_supplicant, the authentication was successful, which is more than I
> > could achieve with a more recent versions. Alas, I could not send any
> > packets via the authenticated channel, they would just disappear.
> I'm not very interested in debugging old versions of wpa_supplicant,
Of course. I just wanted to point out that at some point things seem to
have been working better.
> but
> if the latest one does not work with Linuxant DriverLoader or
> ndiswrapper, I would like to get debug logs and sniffer logs from the
> failed cases.
The latest wpa_supplicant seems to be (not) working just the same with
driverloader as with ndiswrapper. The output of wpa_supplicant and the
sniff log of ethereal are basically the same, so I have not saved them.
I did save however the output with the old version of wpa_supplicant, the
one where EAPOL key exchange does take place. The difference is that after
"Association Response" from the AP the following packet exchange takes
place:
963 27.015526 Intel_0d:de:5c 3comEuro_a8:79:53 EAPOL Start
964 27.015767 Intel_0d:de:5c (RA) IEEE 802.11 Acknowledgement
965 27.021791 3comEuro_a8:79:53 Intel_0d:de:5c EAPOL Key
966 27.021972 3comEuro_a8:79:53 (RA) IEEE 802.11 Acknowledgement
967 27.023273 Intel_0d:de:5c 3comEuro_a8:79:53 EAPOL Key
968 27.023449 Intel_0d:de:5c (RA) IEEE 802.11 Acknowledgement
969 27.030312 3comEuro_a8:79:53 Intel_0d:de:5c EAPOL Key
970 27.030479 3comEuro_a8:79:53 (RA) IEEE 802.11 Acknowledgement
971 27.043207 Intel_0d:de:5c 3comEuro_a8:79:53 EAPOL Key
972 27.043394 Intel_0d:de:5c (RA) IEEE 802.11 Acknowledgement
973 27.049002 3comEuro_a8:79:53 Intel_0d:de:5c IEEE 802.11 Data
974 27.049155 3comEuro_a8:79:53 (RA) IEEE 802.11 Acknowledgement
975 27.050444 Intel_0d:de:5c 3comEuro_a8:79:53 IEEE 802.11 Data
976 27.050627 Intel_0d:de:5c (RA) IEEE 802.11 Acknowledgement
977 27.051815 3comEuro_a8:79:53 Intel_0d:de:5c EAP Failure
978 27.052048 3comEuro_a8:79:53 (RA) IEEE 802.11 Acknowledgement
979 27.090576 3comEuro_a8:79:53 Broadcast IEEE 802.11 Beacon frame
980 27.192956 3comEuro_a8:79:53 Broadcast IEEE 802.11 Beacon frame
981 27.252389 Intel_0d:de:5c 3comEuro_a8:79:53 IEEE 802.11 Null function (No data)
982 27.252634 Intel_0d:de:5c (RA) IEEE 802.11 Acknowledgement
The exchange is initiated by the client card. Is that the way it's
supposed to be? As you can see however, an "EAP Failure" packet is
eventually sent by the AP. Curiously, wpa_supplicant claims that the
authentication was successful. But that's with the old version, and as you
have stated, you are not interested in debugging it. Should you want to
have a look, the relevant files are on the web page mentioned above (files
with names beginning with "driverloader").
I wanted to see how Windows XP packet exchange looks like. Unfortunately,
I only have one laptop, so I can't sniff under Linux and start Windows at
the same time...
Kamil
More information about the Hostap
mailing list