ipw2200 driver no longer sets encrypted WEP in ipw2200 device?

Hello - has somebody disabled encrypted WEP in ipw2200 firmwares, or done something global that would have an equivalent effect, perhaps latent until triggered?

This last week I have not been able to connect over encrypted 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.

The background is that I have finally gotten out of pandemic-locked london, where the laptop/device and I have together been doing encrypted WEP for the past 10 months (and for 10 years before that, all over the world), to madrid, where ... no encrypted WEP works to any router. No - it is not dead. It works fine in plaintext. If you tell me what "open" WEP means (key=0, perhaps?), I'll test that. Yes, I do have the passwrods rite ;).

What can be going on? It's not the kernel .. I shifted from 4.13 to 5.12 to test. Same in both. It's not the wpa_supplicant, I think, because my configuration input from iwconfig seem to behave the same. The key is taken, the ssid is taken, it finds the AP (sometimes), and ... nothing. I twiddle power ctrl on/off, load the same key elsewhere in the list, swap between them, set the channel specifically, name the AP specifically, etc, and ... nothing. Nul points. 0db connection, i.e. not connected.

I have turned on module debugging and added more. The ipw2200 driver says it is associating ... and 0.15s later it disassociates, having received a "CMAS_INIT" (in the module code) from the hardware (?).

 [ 6171.318959] ipw2200: ipw_best_network Network 'TP-Link_0B42 (c0:c9:e3:2f:0b:42)' is a viable match.
 [ 6171.318981] ipw2200: ipw_associate_network Asociation attempt: 'TP-Link_0B42', channel 1, 802.11g [12], long[:long], enc=on (open) key=1.
 [ 6171.319015] 00000000 54 50 2D 4C 69 6E 6B 5F  30 42 34 32               TP-Link_ 0B42    
 [ 6171.319909] ipw2200: ipw_associate_network associating: 'TP-Link_0B42' c0:c9:e3:2f:0b:42
 ... 
 ... (see below)
 ...
 [ 6171.448296] ipw2200: ipw_rx_notification disassociated: 'TP-Link_0B42' c0:c9:e3:2f:0b:42

Why would this happen? Between those two points there is

  [ 6467.685231] libipw: libipw_rx_mgt received BEACON (128)
  [ 6467.685237] libipw: libipw_rx_mgt Beacon

Good. Then some probes:

  [ 6467.685241] libipw: libipw_process_probe_response 'MiFibra-00CA' (e0:51:63:39:00:cc): 0000 0100-0001 0001
  [ 6467.685250] libipw: libipw_parse_info_param WLAN_EID_SSID: 'MiFibra-00CA' len=12.
  ...
  [ 6467.685311] libipw: libipw_process_probe_response Updating 'MiFibra-00CA' (e0:51:63:39:00:cc) via BEACON.

Then we're back in ipw2200:

  [ 6467.791322] ipw2200: ipw_rx_notification type = 11 (4 bytes)
  [ 6467.791346] ipw2200: ipw_rx_notification AUTH_SEQ_1
  [ 6467.792997] ipw2200: ipw_rx_notification type = 10 (4 bytes)

and boom! :

  [ 6467.793009] ipw2200: ipw_rx_notification disassociated: 'TP-Link_0B42' c0:c9:e3:2f:0b:42

That's all she wrote.

Does anyone know what is going on? And how to fix it!

Is the driver unhappy about something in the configuration data it receives from the radio link, perhaps? (the libipw_parse_info...). There are too many "UNKNOWN"s in it for my comfort. See below.

Thanks in advance

Peter

----

 [12597.929233] libipw: libipw_process_probe_response 'TP-Link_0B42' (c0:c9:e3:2f:0b:42): 0000 0100-0001 0001
 [12597.929246] libipw: libipw_parse_info_param WLAN_EID_SSID: 'TP-Link_0B42' len=12.
 [12597.929258] libipw: libipw_parse_info_param WLAN_EID_SUPP_RATES: '82 84 8B 96 12 24 48 6C ' (8)
 [12597.929263] libipw: libipw_parse_info_param WLAN_EID_DS_PARAMS: 1
 [12597.929268] libipw: libipw_parse_info_param MFIE_TYPE_ERP_SET: 6
 [12597.929275] libipw: libipw_parse_info_param WLAN_EID_EXT_SUPP_RATES: '0C 18 30 60 ' (4)
 [12597.929280] libipw: libipw_parse_info_param Unsupported info element: UNKNOWN (45)
 [12597.929286] libipw: libipw_parse_info_param Unsupported info element: UNKNOWN (61)
 [12597.929291] libipw: libipw_parse_info_param Unsupported info element: UNKNOWN (127)
 [12597.929296] libipw: libipw_parse_info_param Unsupported info element: UNKNOWN (11)
 [12597.929302] libipw: libipw_parse_info_param WLAN_EID_VENDOR_SPECIFIC: 24 bytes
 [12597.929307] libipw: libipw_parse_info_param WLAN_ EID_VENDOR_SPECIFIC: 7 bytes
 [12597.929312] libipw: libipw_process_probe_response Updating 'TP-Link_0B42' (c0:c9:e3:2f:0b:42) via PROBE RESPONSE.

This list is so offically dead! Still, I have a clue for you:

Same issue with WPA1 or 2. Plaintext is OK except the signal keeps dropping, and the same is true even from my modern mobile phone.

The clue is this note from TP-Link:

https://www.tp-link.com/en/support/faq/2303/
TP-Link has officially begun to launch our 802.11AX class wireless routers. However, some Intel WLAN adapters with old driver can't detect the wireless signal of our routers. Please upgrade the driver of your WLAN card to the latest if you have this issue.

Intel has also released a FAQ for its compatibility issue:
https://www.intel.com/content/www/us/en/support/articles/000054799/network-and-i-o/wireless-networking.html

I imagine the issue is broad (TP-Link would downplay it) and might be a major messup. Blame Intel for not predicting your future mistake , would you .. heh heh and see what happens.

Has anything of these Intel driver changes made it into a recent kernel?

See where brand loyalty gets you ...

PTB

You sound frustrated. FYI, in case you haven't noticed, the list isn't even near dead. I'll have a clue down below as to why your question didn't get any answers.

Which is talking about the 7265 as the oldest product of the bunch, and ~9260 as the newest.

Those had a launch date of Q3'14 and Q4'17 respectively. You might call them old, but evidently they were fixed. I can't even speculate what the issue might have been though, but if it wasn't just a Windows driver (Linux not affected) or firmware issue (new binaries would've been released for Linux as well), then I certainly never heard about it.

However, your thread here is talking about ipw2200. The devices that driver is for aren't even listed on ark.intel.com (any more?), but I recently du out something about them for unrelated reasons. The _latest_ of the bunch (this driver works on) was a mini-PCI (not PCIe) product called 2915ABG, with a *launch* date of ~2003, and an *EOL* date of EOY 2009.

I think you'll not be surprised that there's hardly anyone who could help you.

I'll note though that the driver for those ancient devices is just as ancient, and (obviously) hasn't changed recently. You'll need to look elsewhere.

I'm also not sure why you're complaining about WEP (might as well run open network) and AX interoperability together. :)

johannes