WPA-PSK hostapd+madwifi-ng <--> DLink DWL-G810 interop problems

Thu Apr 20 08:14:36 PDT 2006

On Tue, 2006-04-18 at 09:27 -0700, Bob Carlson wrote:

BC> It appears that the WPA Information Element (IE) in the second
BC> EAPOL message is being compared to the one sent in association
BC> request. They don't match, so the M2 message is being discarded.
BC> The 4-way never completes, so it times out.

I agree with your diagnosis.  I'd like to figure out _why_ they don't
match and hence hopefully something I can do about it.  First step must
be getting an understanding of what this hex means.  I Googled for a
bit, but I don't really know what I'm looking for.  Can anyone point me
at the right documentation?

BC> I have had a problem with another DWL when I tried WPA2. I don't
BC> recall the hex IE for WPA2, so I'm not sure what you have
BC> configured here.

I had wpa=3 (allow either WPA1 or WPA2, but require one or the other).
wpa=1 gives the same results.  wpa=2 causes all stations to ignore the
AP.  wpa=0 borks with

  ioctl[IEEE80211_IOCTL_SETMLME]: Invalid argument
  Could not connect to kernel driver.

BC> If you are using AES, if you try TKIP instead, it might work.

I think both ends believe they're using TKIP.  Hostapd is starting up
with

  madwifi_set_ieee8021x: enabled=1
  madwifi_configure_wpa: group key cipher=1
  madwifi_configure_wpa: pairwise key ciphers=0xa
  madwifi_configure_wpa: key management algorithms=0x2
  madwifi_configure_wpa: rsn capabilities=0x0
  madwifi_configure_wpa: enable WPA= 0x1
  madwifi_set_iface_flags: dev_up=1

and the output contains lots of "madwifi_set_key: alg=TKIP..." lines.
Meanwhile the web GUI on the DLink was saying "Encryption function:
TKIP" in the diagnostics.

Anyway, I reflashed the DLink with version 2.20 of the US firmware (21
Sep 2005).  The observed differences are:

 - network scan by the DLink shows hostapd as a "WPA-TKIP" network
   when bit 0 of wpa is set.

 - "Encryption Function" now says "WPA-PSK".

 - The bridge now associates using the MAC of whatever is on the
   other side of it, rather than its own.

 - WPA handshakes fails in a slightly different way:

__
Wireless event: cmd=0x8c03 len=20
ath0: STA 00:60:08:28:9a:71 IEEE 802.11: associated
  New STA
ath0: STA 00:60:08:28:9a:71 WPA: event 1 notification
madwifi_del_key: addr=00:60:08:28:9a:71 key_idx=0
ath0: STA 00:60:08:28:9a:71 WPA: start authentication
WPA: 00:60:08:28:9a:71 WPA_PTK entering state INITIALIZE
madwifi_del_key: addr=00:60:08:28:9a:71 key_idx=0
ath0: STA 00:60:08:28:9a:71 IEEE 802.1X: unauthorizing port
madwifi_set_sta_authorized: addr=00:60:08:28:9a:71 authorized=0
WPA: 00:60:08:28:9a:71 WPA_PTK_GROUP entering state IDLE
WPA: 00:60:08:28:9a:71 WPA_PTK entering state AUTHENTICATION
WPA: 00:60:08:28:9a:71 WPA_PTK entering state AUTHENTICATION2
WPA: 00:60:08:28:9a:71 WPA_PTK entering state INITPSK
WPA: 00:60:08:28:9a:71 WPA_PTK entering state PTKSTART
ath0: STA 00:60:08:28:9a:71 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=1 ie_len=0
gtk_len=0 keyidx=0 encr=0)
TX EAPOL - hexdump(len=121): 00 60 08 28 9a 71 00 14 85 2e 01 9e 88 8e
01 03 00 67 fe 00 8a 00 10 00 00 00 00 00 00 00 01 f2 13 b7 3a 49 2b 31
19 28 00 9f 97 49 5e 2a 2b 28 ba 18 da 71 8a 01 42 87 90 d9 2f da cf e9
e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
ath0: STA 00:60:08:28:9a:71 WPA: EAPOL-Key timeout
WPA: 00:60:08:28:9a:71 WPA_PTK entering state PTKSTART
ath0: STA 00:60:08:28:9a:71 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=1 ie_len=0
gtk_len=0 keyidx=0 encr=0)
TX EAPOL - hexdump(len=121): 00 60 08 28 9a 71 00 14 85 2e 01 9e 88 8e
01 03 00 67 fe 00 8a 00 10 00 00 00 00 00 00 00 02 f2 13 b7 3a 49 2b 31
19 28 00 9f 97 49 5e 2a 2b 28 ba 18 da 71 8a 01 42 87 90 d9 2f da cf e9
e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
IEEE 802.1X: 123 bytes from 00:60:08:28:9a:71
   IEEE 802.1X: version=1 type=3 length=119
ath0: STA 00:60:08:28:9a:71 WPA: WPA IE from (Re)AssocReq did not match
with msg 2/4
WPA IE in AssocReq - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2
02 01 00 00 50 f2 04 01 00 00 50 f2 02
WPA IE in msg 2/4 - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 04
01 00 00 50 f2 04 01 00 00 50 f2 04
hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA
00:60:08:28:9a:71 reason 2
madwifi_sta_deauth: addr=00:60:08:28:9a:71 reason_code=2
ath0: STA 00:60:08:28:9a:71 IEEE 802.11: deauthenticated due to local
deauth request
Wireless event: cmd=0x8c04 len=20
ath0: STA 00:60:08:28:9a:71 IEEE 802.11: disassociated
Wireless event: cmd=0x8c03 len=20
ath0: STA 00:60:08:28:9a:71 IEEE 802.11: associated
  New STA
Invalid WPA group cipher (0x0) from 00:60:08:28:9a:71
WPA/RSN information element rejected? (res 2)
Data frame from not associated STA 00:60:08:28:9a:71
__

  (note the AssocReq and msg IEs are now both 24 bytes, but the
  last byte is 02 vs 04).

 - "wlanconfig ath0 list" shows the bridged STA in mode
   "Normal WPA ATH", rather than "Normal ATH" as before.

So far the only configuration I have been able to get working is ad-hoc
with no auth or crypto at all.  Which is not really much use.

Is this more likely to be a lower-layer issue?  Should I take this to
the MadWifi list?

Cheers

Duncan