hostap WEP rekeying difficulties, cont'd

[Kyle Rose]

I got another laptop up and running for the purposes of monitoring the
802.11 frames.  Here's what I found out from ethereal:

(1) With wep_key_len_unicast and wep_key_len_broadcast both commented
out, everything of course works fine, except that no WEP results. :)

(2) With wep_key_len_unicast=13 and wep_key_len_broadcast commented
out, the client negotiates a unicast key properly but never uses it:
even after manually placing an entry in the client's ARP cache for the
AP's MAC, pings to the AP's IP address are not WEP-encrypted, meaning
the hostap driver is not lying that the Orinoco client isn't
encrypting the packets.  (Note: since ARP requests fail for the same
reason, it seems HostAP doesn't accept *any* packets from
authenticated ports that aren't WEP-encrypted, broadcast or not.)

(3) With wep_key_len_unicast=13 and wep_key_len_broadcast=13, the
client and AP exchange probe request/response (request broadcast,
response unicast to the client), but this never ends: the Orinoco card
never associates with the AP.

I did some diffs of a request/response pair for each of the above.
Neglecting differences in frame and sequence numbers, times,
connection stats (e.g., signal strength), the only substantial
differences I found were:

Between (1) and (2): nothing.

Between (1) and (3): the capability bit for whether the AP supports
WEP or not.

It seems to follow from this that the WEP capability bit deals only
with broadcast WEP, AND I started to get the feeling that the Orinoco
card won't ever send an Association Request in response to a Probe
Response with the WEP/AP capability bit set when it doesn't also have
WEP active also.

So, this got me to thinking: what if I put a bogus key on the client,
and THEN start xsupplicant?  The EAP messages and 802.1x frames should
remain unencrypted anyway.

Well, it turns out that nets me *some* progress: the client negotiates
two keys ("EAPOL Key processed: broadcast" and "EAPOL Key processed:
unicast") which both appear in iwlist eth0 enc on the client and in
hostap_crypt_conf -l wlan0 on the AP.  E.g.,

ap$ hostap_crypt_conf -l wlan0
Default keys
  algorithm: WEP
  TX key idx: 2
  key 1:
  key 2: 20 56 42 97 e0 64 f6 17 3f 3f 50 a5 59
  key 3:
  key 4:

Keys for 00:02:2d:0c:83:95
  algorithm: WEP
  TX key idx: 1
  key 1: a7 e4 cd b9 67 2d 58 5e 35 8b dd 61 58
  key 2:
  key 3:
  key 4:

client$ iwlist eth0 enc
eth0      2 key sizes : 40, 104bits
          4 keys available :
                [1]: A7E4-CDB9-672D-585E-358B-DD61-58 (104 bits)
                [2]: 2056-4297-E064-F617-3F3F-50A5-59 (104 bits)
                [3]: off
                [4]: off
          Current Transmit Key: [2]
          Security mode:open

...AND, I could finally talk WEP between these two machines.

Sounds good, eh?  Well, unfortunately, when I switch my monitoring
station to managed mode and activate xsupplicant there, it all falls
apart: neither machine can communicate with the AP now, with the
hostap module claiming

Aug 30 13:24:04 yupa kernel: wlan0: encryption configured, but RX frame not encrypted (SA=00:60:1d:1c:bf:09)
Aug 30 13:24:15 yupa kernel: wlan0: encryption configured, but RX frame not encrypted (SA=00:02:2d:0c:83:95)

for both clients, and continues to fail until I eject/insert the first
client, even if I remove the second client right after starting
xsupplicant on it.  (Although I applied the rekey_patch_orinoco to
only the kernel on the first client, a badly-behaved client should not
be able to cause an entire network to fail; even so, I doubt that is
the problem here.)

So, I'm slowly making progress, but it's very frustrating to be having
these problems when (a) it seems there are lots of people who are
making use of RADIUS/HostAP setups with no problems to speak of, and
(b) no one seems willing to help.  I know some of you have answers;
out with them! :)

Cheers,
Kyle