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:
On Thu, 10 Jun 2021 13:11:39 +0100
Peter Breuer <[email protected]> wrote:
> Hello - has somebody disabled encrypted WEP in ipw2200 firmwares, or
> done something global that would have an equivalent effect, perhaps
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
On Sun, 2021-06-13 at 10:33 +0100, Peter Breuer wrote:
> This list is so offically dead! Still, I have a clue for you:
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.
> On Thu, 10 Jun 2021 13:11:39 +0100
> Peter Breuer <[email protected]> wrote:
>
> > Hello - has somebody disabled encrypted WEP in ipw2200 firmwares, or
> > done something global that would have an equivalent effect, perhaps
>
> 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/
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