Bug 249709

addenda:
If I set up a fixed ip address instead of using DHCP, network manager claims to be connected to the AP in WEP128 mode, yet no internet connection is possible.

addenda:
I cross-checked this issue on another machine with ipw3945 WLAN, which is running openSuSE 10.3 alpha 1 plus as well. Although I can connect to the AP with WPA and WPA2, it will not connect with WEP ( neither ifup, nor network manager )

Please attach full dmesg log, the output of
  /sbin/lspci -v
and of
  cat /proc/interrupts

Are you able to connect using WEP128 with any other machine or under a different operating system?

I can connect WEP64 / WEP128 on this machine using Windows XP

cat /proc/interrupts

           CPU0       
  0:     276096    XT-PIC-XT        timer
  1:        483    XT-PIC-XT        i8042
  2:          0    XT-PIC-XT        cascade
  8:          2    XT-PIC-XT        rtc
  9:      24870    XT-PIC-XT        acpi, uhci_hcd:usb1, uhci_hcd:usb2, Intel 82801BA-ICH2, ohci1394, yenta, yenta, pcmcia1.0, eth0
 11:          4    XT-PIC-XT        sonypi
 12:        107    XT-PIC-XT        i8042
 14:      15945    XT-PIC-XT        ide0
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

/sbin/lspci -v

00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 11)
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: bus master, fast devsel, latency 0
        Capabilities: <access denied>

00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 11) (prog-if 00 [VGA])
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 9
        Memory at f8000000 (32-bit, prefetchable) [size=64M]
        Memory at f4000000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: <access denied>

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 03) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=09, sec-latency=64
        I/O behind bridge: 00003000-00003fff
        Memory behind bridge: f4100000-f41fffff
        Prefetchable memory behind bridge: 20000000-27ffffff

00:1f.0 ISA bridge: Intel Corporation 82801BAM ISA Bridge (LPC) (rev 03)
        Flags: bus master, medium devsel, latency 0

00:1f.1 IDE interface: Intel Corporation 82801BAM IDE U100 (rev 03) (prog-if 80 [Master])
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: bus master, medium devsel, latency 0
        [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
        [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
        [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
        [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
        I/O ports at 1800 [size=16]

00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 03) (prog-if 00 [UHCI])
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: bus master, medium devsel, latency 0, IRQ 9
        I/O ports at 1820 [size=32]

00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 03)
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: medium devsel, IRQ 9
        I/O ports at 1810 [size=16]

00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #2) (rev 03) (prog-if 00 [UHCI])
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: bus master, medium devsel, latency 0, IRQ 9
        I/O ports at 2400 [size=32]

00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio (rev 03)
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: bus master, medium devsel, latency 0, IRQ 9
        I/O ports at 1c00 [size=256]
        I/O ports at 1840 [size=64]

00:1f.6 Modem: Intel Corporation 82801BA/BAM AC'97 Modem (rev 03) (prog-if 00 [Generic])
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: medium devsel, IRQ 9
        I/O ports at 2000 [size=256]
        I/O ports at 1880 [size=128]

01:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: bus master, medium devsel, latency 64, IRQ 9
        Memory at f4101000 (32-bit, non-prefetchable) [size=2K]
        Memory at f4104000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>

01:02.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
        Subsystem: Sony Corporation Unknown device 80f2
        Flags: bus master, medium devsel, latency 168, IRQ 9
        Memory at f4102000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=01, secondary=02, subordinate=05, sec-latency=176
        Memory window 0: 20000000-23fff000 (prefetchable)
        Memory window 1: 28000000-2bfff000
        I/O window 0: 00003400-000034ff
        I/O window 1: 00003800-000038ff
        16-bit legacy interface ports at 0001

01:05.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
        Subsystem: Lucent Technologies Unknown device ab01
        Flags: bus master, medium devsel, latency 168, IRQ 9
        Memory at f4103000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=01, secondary=06, subordinate=09, sec-latency=176
        Memory window 0: 24000000-27fff000 (prefetchable)
        Memory window 1: 2c000000-2ffff000
        I/O window 0: 00003c00-00003cff
        I/O window 1: 00001400-000014ff
        16-bit legacy interface ports at 0001

01:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller (rev 03)
        Subsystem: Sony Corporation Unknown device 8111
        Flags: bus master, medium devsel, latency 66, IRQ 9
        Memory at f4100000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 3000 [size=64]
        Capabilities: <access denied>

As I suspected, that's not a PCI card. Please attach output of
  /sbin/pccardctl info

And attach a full dmesg log, please.

Well, the name is misleading, it is a PCMCIA device with a PCI device on one mini board. So it plugs into PCI and internally uses PCMCIA.

Created attachment 123233 [details]
dmesg after boot and login

Sorry, I missed that in Comment #5

WORKSTATION1L:/home/cjp # /sbin/pccardctl info
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255
PRODID_1="Lucent Technologies"
PRODID_2="WaveLAN/IEEE"
PRODID_3="Version 01.01"
PRODID_4=""
MANFID=0156,0002
FUNCID=6

This is now openSuSE 10.3 alpha4 (Kernel 2.6.21-9-default)

I rechecked this with the FSC Amilo Si 1520 (ipw3945) it will not connect with WEP either. This might be also related to Bug 225604 as well as Bug 269856

Now this is really weird, there is a variable WIRELESS_KEY_LENGTH in YaST /etc/sysconfig Editor (Hardware/Network/wlan-idxxxx). with possible values of 40 and 104. Changing this manually to any other value is not possible.

When configuring the WLAN Card with YaST/Network Devices/Network Card there is a final step "Wireless Network Card Configuration" where WEP Keys can be configured. If this is set a dialogue opens "Wireless Keys", offering a key length of either 64 or 128. This value is then set into the WIRELESS_KEY_LENGTH above, prohibiting association of any WEP based AP.

When setting the length appropriately to 40 / 104 connection is possible without problem for the ipw3945, the orinoco still fails to get a lease.

Addenda: All of this fails to work if wireless keys are entered in YaST. It only works for the ipw3945 when all the variables WIRELESS_KEY to WIRELESS_KEY_3 are empty and WIRELESS_KEY_LENGTH is set to the correct value for the AP ( 40/104 )

To corrupt the settings it suffices to enter the "Wireless Keys" dialogue and leave with accept without entering anything. The WIRELESS_KEY_LENGTH will be set to 128 / 64 instead of 104 / 40.

For the orinoco it works now also, but only if there is only one WEP Key configured in the AP ( I had all 4 configured ).

Even Network Manager is now able to connect using WEP.

A bit mysterious that nobody else should have run into this bug.

Ok, we have two issues here:
- connection is not possible with ipw3945 when using YaST to configure WEP
- orinoco does not work when more keys are configured in the AP

Is that correct? If yes, please enter a new bugreport against YaST for the first issue so we can focus on the second issue here.

In the dmesg you attached in comment #7 the driver says that the card was successfully associated to the AP. Is this dmesg from a successful or unsuccessful attempt to connect to the AP? Was that with or without WEP?

If it was from an unsuccessful attempt with WEP key set: It seems you have an access to the AP. Can it list associated stations in its configuration interface? If yes, could you restore the previous setup, try to connect and check whether also your AP thinks that your orinoco card is associated?

"connection is not possible with ipw3945 when using YaST to configure WE" is true for both

"orinoco does not work when more keys are configured in the AP" would be a separate, additional issue.

Entering separate bug report for the latter. (Bug 278619)

Yes, the AP thinks the card is connected, but not showing an IP address for it.

Reassigned to YaST team.

Hm, from comment #1 and #2 - problem is when uses dhcp, for static works fine.
No matter if NetworkManager or NetConfig is used.
This is strange for me.
I have ipw3945 onboard card - bud didn't checked wlan yet.
Did you ran 10.2 before (I think yes, because you reported me some bugs ;-) ). Did wlan works with 10.2? Could you compare configurations? 

Reproduced, it doesn't work in 10.3Alpha4 with kernel, firmware and userspace daemon installed - this worked in 10.2.Both NM and ifup - it's not YaST bug.
Joachim?

Now, the YaST bug is in comment # 10 and comment # 11

YaST is corrupting the WIRELESS_KEY_LENGTH variable depending on whether you set it from YaST/etc/sysconfig Editor or YaST/Network Devices/Network Card/Wireless Keys.

This variable has two values for WEP 40 / 104 in /etc/sysconfig Editor and 64 / 128 from YaST/Network Devices/Network Card/Wireless Key.

If set in one the other takes an invalid value.

For me its working if I set it correctly in YaST/etc/sysconfig Editor

During a "clean" install from the alpha4 DVD wireless LAN can be configured, but no connection is possible using WEP encryption. As this is taking place on the Sony Vaio PCG-SRX51P with built in ORiNOCO card it's the only option except for unencrypted.

When switching to a terminal and perusing /etc/sysconfig/network/ifcfg-wlan-id-00:02:2d:5c:f5:ef, you find that WIRELESS_KEY_LENGTH is set to 164 which is incorrect. Setting it to 104 provides a wireless network connection as desired.

A value of 164 is invalid and won't work, or course. If YaST wrote it into that variable, it's a bug. But I don't see this on my system, I just configured an Orinoco pc-card on my Alpha4 system with a hashed 128 bit key, and the ifcfg-file looks fine. Are you using a hex, hashed, or ASCII key?

The issue with the WEP key length is indeed confusing. The possible lengths of the WEP keys are 40 or 104 bit. WEP uses a 24 bit initialisation vector, if you add that, you get 64 or 128 bit, although the key itself is actually shorter. In marketing speech it's always 64 resp. 128 bit (of course), hence YaST uses these values. ifup supports both values in the ifcfg files.

Casual J. Programmer, Are you using a hex, hashed, or ASCII key?

ASCII

I had a similar problem as well. It turned out that the WEP paraphrase was set as a string rather than Hex. Changing the type did the job for me. I don't know if this is the same problem, but might double check.

I just had this problem on an upgrade to 10.3. The machine is a Thinkpad 770Z, the Wireless card a Netgear WG511v2.

Wireless did not come up after the upgrade, I ran Yast to configure it but got no connection. I noticed running iwconfig the key phrase was completely different than what I had set.

The file /etc/sysconfig/network/ifcfg-wlan0 had the correct key string but there was h: in front of it.  Removed the h: and now it shows the correct key and connects OK.

The leading h: indicates that a hashed passphrase is used. By removing h: you changed the key type to hex.

To finally resolve this issue, what problems brought up in this bug are still existent?

(In reply to comment #28 from Joachim Gleissner)
> To finally resolve this issue, what problems brought up in this bug are still
> existent?
> 

I am happy with your explanation.  The Netgear Wireless is working, I am typing over it. Thanks for looking at this.

Not sure about the orinoco_cs as I don't have access to that machine anymore. 

For the ipw3945 it appears to still not work using ifup. The ipw3945 associates with the AP OK, but never gets an IP address.

cat /etc/SuSE-release
openSUSE 10.3.1 (i586) Alpha0
VERSION = 10.3.1

rpm -qa | grep ipw
ipw3945d-1.7.22-16
ipw3945-kmp-default-1.2.2_2.6.24_rc2_git6_7-4
ipw-firmware-8-51

Doesn't work with NetworkManager either :-(

To summarise, you have a WEP connection configured, which successfully associates but no data gets transferred. Is that correct? In such cases the entered WEP key is usually wrong.

Not sure where anything could go wrong here, same configuration works with Windows XP without problems.

Apart fro a Typo in the Key it could, as far as I see it, only be wrong qualification of string, ascii or hex which I all tried ( wouldnt confuse hex for ascii anyway, would we ? )

The AP is a FRITZ!Box Fon WLAN 7050 with latest Firmware. WEP is set to 128bit no shared auth.

4 WEP keys are present one of which is marked as current.

Now, after some trying, I get the stuff to connect ( WEP64 as well as WEP 128 ). It _only_ works if there is just one WEP Key in the AP and it is #1 of 4, or else I enter all 4 keys present in the AP.

Why should it not work if I just chose to enter one of the 4 keys of the AP ?

The multiple WEP keys system is a bit strange. It is virtually of no real use for the home user, as a station uses only one key for sending. AFAIK there is no key rotation defined in WEP, at least no standard one. The order of the keys is important, because a encrypted packet contains the key number, and the receiving station uses exactly the key with this number to decrypt the packet. If there is a different key at this index (even you have the right key, just with a different index number), it won't work. I suppose this is the cause of trouble here.