wpa_supplicant fails to initiate WEP128 connection over ipw2200 driver/device

[Peter Breuer]

Hello wpa_supplicant-ers

Recently I have not been able to connect over WEP (128) through my
intel ipw2200 wifi device (venerable ibm tp x40 laptop, cerca
2006, 1.2GHz 686M processor, 1GB ram) via two or three new routers that
I have tried. Connections around town and in airports have been fine.
I even managed a connect over WEP in the office.

One of the few things that has changed is the version of wpa_supplicant,
because I keep the debian/devuan unstable distro uptodate on the laptop.
I have used the same 4.13.4 kernel and driver firmware (20161130-5) for
ages!

Seeing what would happen I upgraded the kernel to 5.12.9 and the
driver firmware to 20200721-1. No change.

The kernel says (with debugging turned on in the driver):

     ipw_best_network Network 'TP-Link_0B42 (c0:c9:e3:2f:0b:42)' excluded because of privacy mismatch: off != on.

That is, the connection has encryption, but local thinks it can't do
that. The driver code stanza in question is:

        /* Verify privacy compatibility */
        if (((priv->capability & CAP_PRIVACY_ON) ? 1 : 0) !=
            ((network->capability & WLAN_CAPABILITY_PRIVACY) ? 1 : 0)) {
                IPW_DEBUG_MERGE("Network '%*pE (%pM)' excluded because of privac
y mismatch: %s != %s.\n",
                                network->ssid_len, network->ssid,
                                network->bssid,
                                priv->
                                capability & CAP_PRIVACY_ON ? "on" : "off",
                                network->
                                capability & WLAN_CAPABILITY_PRIVACY ? "on" :
                                "off");
                return 0;
        }

so the "off" is from priv->capability, and the "on" is from
network->capability.  The driver thinks encryption is off in the
device/itself and thinks encryption is on in the wifi. It is right
about the latter.

(going for a plaintext connection, one with encryption off, there
is no trouble connecting)

I think wpa_supplicant is missing in an attempt to turn on encryption, but
I don't know, and hopefully somebody here will.

The wpa_supplicant report is

  eth1: Trying to associate with c0:c9:e3:2f:0b:42 (SSID='TP-Link_0B42' freq=2412 MHz)
  Failed to add supported operating classes IE - hexdump(len=3): 3b 01 51
  eth1: Association request to the driver failed

(I augmented the error message with the hexdump; what on earth is a "IE"?)

It is from here - apologies from my debug additions:

        wpabuf_put_u8(buf, WLAN_EID_SUPPORTED_OPERATING_CLASSES);
        /* Will set the length later, putting a placeholder */
        ie_len = wpabuf_put(buf, 1);
        wpabuf_put_u8(buf, current);

        for (op = 0; global_op_class[op].op_class; op++) {
                if (wpas_op_class_supported(wpa_s, ssid, &global_op_class[op])){
                        wpabuf_put_u8(buf, global_op_class[op].op_class);
                        // PTB
                        *ie_len = wpabuf_len(buf) - 2;
                        if (*ie_len < 2 || wpabuf_len(buf) > len) {
                          wpa_hexdump_buf(MSG_ERROR,
                           "Failed to add supported operating classes IE", buf);
                        }
                        // BTP
                }
        }
        *ie_len = wpabuf_len(buf) - 2;
        if (*ie_len < 2 || wpabuf_len(buf) > len) {
                wpa_hexdump_buf(MSG_ERROR,
                           "Failed to add supported operating classes IE", buf);
                res = 0
        } else {
   
The usual error (second stanza) would ordinarily be emitted instead. I
made the error come out at the moment of the "operating class" being
added so a failure would let us know what the failed addition was.

I guess/understand that the third byte in "3b 01 51" is the class and it
is trying to talk to the driver over some kernel interface. Whatever
51 is, it is not liked.

My vague impression is that the wrong number may be delivered to the
driver.  This is a b/g device.  No n, no a.  From iwpriv I get:

 % sudo iwpriv eth1 set_mode 2
 % sudo iwpriv eth1 get_mode 
 eth1      get_mode:802.11b (2)
 % sudo iwpriv eth1 set_mode 4
 % sudo iwpriv eth1 get_mode
 eth1      get_mode:802.11g (4)
 % sudo iwpriv eth1 set_mode 6
 % sudo iwpriv eth1 get_mode
 eth1      get_mode:802.11bg (6)

Nothing else that I can discover.  That may be the issue (for all I
know).

The background to this is that I finally got out of London (trapped by
pandemic) back to home, where the isp is forcing an upgrade to
fibre-optic cable.  Their new router doesn't do WEP (and my laptop has
no hardware support for WPA2, and I need my cycles), so I added a
TP-Link wifi access point, since I have used one in London happily over
the last 10 months of being trapped.  No dice.  Its firmware says 2018.

I replaced the AP with a ethernet-over-power unit from TP-Link that also
does wifi, but the same issue is present.

Does anyone here know what is going on? Has this been "seen"?

   ii  wpasupplicant  2:2.9.0-21   

Just tried downgrading wpasupplicant. No change. Weird. Yes, I have got the
password right.

   ii  wpasupplicant  2:2.4-1+deb9u9

  eth1: Trying to associate with c0:c9:e3:2f:0b:42 (SSID='TP-Link_0B42' freq=2412 MHz)
  eth1: Association request to the driver failed
  eth1: CTRL-EVENT-DISCONNECTED bssid=c0:c9:e3:2f:0b:42 reason=0
  eth1: CTRL-EVENT-SSID-TEMP-DISABLED id=7 ssid="TP-Link_0B42" auth_failures=2 duration=20 reason=CONN_FAILED

So I don't know what is going on. At all.

Any clues? Has the whole world changed their WEP implementations in their
routers or something? Is it possible that "security" is now preventing
WEP in a situation where several other thransmitters are discovered?


Peter