Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #618 (reopened defect)

Opened 16 years ago

Last modified 14 years ago

WPA-PSK (AP mode) does not work with Pocket PC client

Reported by: wfragg@gmail.com Assigned to:
Priority: major Milestone:
Component: madwifi: other Version:
Keywords: Cc:
Patch is attached: 1 Pending:

Description

My Pocket PC (rx3715) do not connect to my AP with card based on Atheros 5212.

I use 1546 revision of madwifi-ng and hostapd 0.5.3.

The indication is following: client device (Pocket PC) tries to connect for some time and eventually connects to other AP (I think, it is PPC logic - if it fails to connect to one network, it chooses other).

There is nothing interesting in the hostapd logs. If I turn on +assoc and +input using the 80211debug, I got the following in the logs:

May 12 11:53:13 lmct-post1 kernel: [00:11:0a:2c:21:5d] discard probe_req frame, ssid mismatch: 0x1707180b0d1e0605071a160a1b140717060e01050d1f071d111f1618021f0f12
May 12 11:53:13 lmct-post1 last message repeated 6 times
May 12 11:53:13 lmct-post1 kernel: ath0: [00:11:0a:2c:21:5d] recv probe req
May 12 11:53:13 lmct-post1 last message repeated 4 times
May 12 11:53:14 lmct-post1 kernel: [00:11:0a:2c:21:5d] discard probe_req frame, ssid mismatch: 0x1707180b0d1e0605071a160a1b140717060e01050d1f071d111f1618021f0f12
May 12 11:53:14 lmct-post1 last message repeated 5 times
May 12 11:53:14 lmct-post1 kernel: ath0: [00:11:0a:2c:21:5d] recv probe req
May 12 11:53:14 lmct-post1 last message repeated 4 times
May 12 11:53:15 lmct-post1 kernel: [00:11:0a:2c:21:5d] discard probe_req frame, ssid mismatch: 0x1707180b0d1e0605071a160a1b140717060e01050d1f071d111f1618021f0f12
May 12 11:53:15 lmct-post1 last message repeated 6 times
May 12 11:53:16 lmct-post1 kernel: ath0: [00:11:0a:2c:21:5d] recv probe req
May 12 11:53:19 lmct-post1 last message repeated 23 times
May 12 11:53:20 lmct-post1 kernel: [00:11:0a:2c:21:5d] discard probe_req frame, ssid mismatch: 0x0c0a1e1f090c19020a0a071c030919020302061808110c1f1a19010e151e1603
May 12 11:53:20 lmct-post1 last message repeated 4 times
May 12 11:53:20 lmct-post1 kernel: ath0: [00:11:0a:2c:21:5d] recv probe req
May 12 11:53:20 lmct-post1 last message repeated 3 times
May 12 11:53:21 lmct-post1 kernel: [00:11:0a:2c:21:5d] discard probe_req frame, ssid mismatch: 0x0c0a1e1f090c19020a0a071c030919020302061808110c1f1a19010e151e1603

These ssid's look very strange to me. I remember everything worked quite well with old madwifi code and hostapd 0.4.7 (but I need new code for VAP feature - we need two networks, one open and one secured).

This problem is experienced only with the WPA-PSK network (therefore, it could be hostapd problem as well - I do not know, but hostapd simply shows nothing in the logs). The open network works fine.

Attachments

20060515-monitor-ppc.gz (23.9 kB) - added by wfragg@gmail.com on 05/15/06 05:16:44.
Monitored packets (PocketPC fails to connect to the WPA-PSK-enabled network)
20060515-monitor-ppc-old-working.gz (21.1 kB) - added by wfragg@gmail.com on 05/15/06 13:47:49.
Captured packets, association of old madwifi-based AP (madwifi from CVS, 20051019 + hostapd 0.4.7) with same Pocket PC
madwifi-wpa-ppc-fix.patch (1.5 kB) - added by wfragg@gmail.com on 05/16/06 06:01:49.
Signed-off-by:

Change History

05/12/06 15:21:06 changed by wfragg@gmail.com

Forget to mention. We experience the same problems with two other Pocket PC devices (they all Win Mobile 2003 SE based).

05/12/06 15:50:54 changed by dyqith

What's the true ssid of the AP and what is the Pocket PC set to connect to ? And is the MAC addr one of the Pocket PC's ?

Can you also use the +auth flag ?

05/15/06 05:15:58 changed by anonymous

true ssid is "secure". WPA-PSK passphrase is 0123456789123.

After monitoring using other AP I found that PPC sometimes sends probe requests with right SSID, AP responses with "Probe response" (several times) and nothing happens - PPC does proceed, but sends "probe requests" again.

+auth flag does not show any additional information.

Also note that my Nokia 9500 starts associating just fine (although it fails in GTK negotiation, but it seems more like hostapd problem, I think).

I've attached a monitored dump. MAC of mine AP is 00:0b:6b:37:35:aa, MAC of Pocket PC is 00:11:0a:2c:21:5d. Other devices are out of interest.

05/15/06 05:16:44 changed by wfragg@gmail.com

  • attachment 20060515-monitor-ppc.gz added.

Monitored packets (PocketPC fails to connect to the WPA-PSK-enabled network)

05/15/06 13:47:49 changed by wfragg@gmail.com

  • attachment 20060515-monitor-ppc-old-working.gz added.

Captured packets, association of old madwifi-based AP (madwifi from CVS, 20051019 + hostapd 0.4.7) with same Pocket PC

05/15/06 13:51:32 changed by wfragg@gmail.com

I've added the captured packets where PocketPC at least starts associating with AP (and I see some output from hostapd).

05/15/06 20:07:08 changed by dyqith

after reading through all this + the monitor logs,

It doesn't look like its a madwifi-ng problem to me. The AP responds fine with probe response, but there's no assoc request, so the AP doesn't send a assoc response.

Is the PocketPC capable of WPA-PSK ?

05/16/06 04:32:01 changed by wfragg@gmail.com

Yes it is WPA-PSK capable. As I've said previously, this PPC (and two others) work just fine with old madwifi + hostapd 0.4.7. And all three of them do not work with new combination.

Probably, you are right (the logs look fine to me too) and this is a problem with PocketPC. But from my point of view, it worked with previous code, so there must be a way to make it working with current code, I suppose.

Maybe, PPC does not like some additional tags in beacon frames/probe responses.

Is there a way make frames from "new" code look like frames from "old" code (remove all tags that present only in "new" code) or frames are composed in firmware code?

05/16/06 04:43:03 changed by dyqith

You can change things around in the code. Take a look at net80211/ieee80211_input.c for the recv end, net80211/ieee80211_output.c for tx end.

forgot to ask, are all of them g capable, i think the logs say yes...

05/16/06 05:58:09 changed by wfragg@gmail.com

Seem like I found the problem.

I've moved outputting WPA tagged parameter (ieee80211_add_wpa calls in the ieee80211_beacon.c and ieee80211_output.c) to be the last tagged parameter in the frame, and now my PPC starts associating! Looks like the problem was PPC either thinks that WPA parameter is the last or it requires proper order of parameters.

Also, PocketPC now properly detects that network is WPA-PSK (previously PPC detected the network as WEP and I had to set the parameters manually).

I will attach a patch later.

05/16/06 06:01:49 changed by wfragg@gmail.com

  • attachment madwifi-wpa-ppc-fix.patch added.

Signed-off-by:

05/16/06 06:03:38 changed by wfragg@gmail.com

I mistakenly submitted the form. Here is the proper signature:

Signed-off-by: Ivan S. Dubrov <wfragg@gmail.com>

05/16/06 06:29:10 changed by anonymous

  • patch_attached set to 1.

05/16/06 06:48:48 changed by dyqith

  • status changed from new to closed.
  • resolution set to fixed.

patch merged into changeset:1553

Thanks, looks like you found a bug with out implementation (802.11i standards seems to want the protected stuff at the end of the frame)

thanks.

05/19/06 22:43:18 changed by dyqith

  • status changed from closed to reopened.
  • resolution deleted.

Please try changeset:1575

I changed a few things again.

Please try it to see if it works for you ?

05/19/06 22:43:49 changed by dyqith

related ticket:633

06/24/06 16:57:55 changed by red@meshnode.org

For me it dint also work when i have the option "tkip ccmp" option aktive in hostapd.conf. When i removed the CCMP option it works perfectly.

07/17/07 14:50:49 changed by mtaylor

This ticket has not been updated in over six months and is being marked as "works for me" automatically.

If the ticket is still applies to the head revision of trunk, please re-open the ticket and provide any additional details needed and progress on the problem to date. Thanks.