Bug 472183

NM certainly does support 40-bit WEP keys; what exact option are you choosing in the UI when you enter the key?  "40/128-bit WEP Hex" or something else?

any option containing a wep key. unfortunately the router is configured to use an 64-bit key so it fails if i try any of the available option, and 64-bit wep key is nowhere to be seen in the menu.

It's generally called a "40-bit" WEP key, not a 64-bit wep key, but some manufacturers use 64-bit.  Is the key a "passphrase", an ASCII key, or a hex key?  But most certainly the option you want is "40/128-bit WEP Key".

the key is
0123456789

and the 40/128 option does not allow me to connect.

Does the dialog allow you to clikc OK and then the connection fails, or that the dialog simply doesn't allow you click OK after entering your key?

i don't have the router right now, but as far as i can remember, i could click ok and then failed.

Can you try a pure wpa_supplicant config for your network?  Put this file in /tmp (without the ------- lines):

---------------------
ap_scan=1
fast_reauth=1

network={
	ssid="<your ssid>"
	scan_ssid=1
	key_mgmt=NONE
	wep_key0=<your WEP key>
	wep_tx_keyidx=0
}
---------------------

Next, as root, do the following (make sure you have enough scrollback in your terminal, or redirect wpa_supplicant output to a file):

service NetworkManager stop
killall -TERM wpa_supplicant
/usr/sbin/wpa_supplicant -dddt -i <wifi interface> -D wext -c /etc/wpa_supplicant.conf

let that run for a minute or two, then grab its output, and attach it to this bug report so I can see if taking NM out of the equation works or not.

thnx, what should be the name of the /tmp file?

ah :) my fault.  Whatever file name you save that as, goes after the "-c" in the wpa_supplicant command.  So, if you put that content into a file called "/tmp/foo", and assuming your wifi interface is wlan0, you'd then do:

service NetworkManager stop
killall -TERM wpa_supplicant
/usr/sbin/wpa_supplicant -dddt -i wlan0 -D wext -c /tmp/foo

i've got the router and here's what i've found: (see attachment)

Created attachment 326152 [details]
output from 8dec2k8

meanwhile i've discovered that f10 on acer 5315 with broadcom 4312 internal wireless card can connect to the same wap so, i'v yum upgraded the f9 from my thinkpad x40 to f10. unfortunately this didn't help. so i did some moretests: i've attached an rtl8xxx usb card to the thinkpad and it did connect to the wap. next, i booted puppy 4.1.2 and it did connect to the wap using the pcmcia ralink card (wich does not connect in f10 and f9). same thing happen in ubuntu 8.10. so ithought that it's maybe related to selinux or iptables. i've found out that 
service iptables stop
and 
setenforce 0
does not help.

as a side note, i'vo renamed my only eth interface to eth0 and my pcmcia wireless interface to wlan0 (in/etc ...udev...persistent network rules).

next, i'll check system-config-network, _maybe_ there's an wireless interface defined there, i've found that defining interfaces there makes nm fail even if network service is stopped.

the nm version now is
NetworkManager-0.7.0-0.12.svn4326.fc10.i386

and
removing the only interface configured in system-config-network (eth2) didn't help.

i'm not that sure it' nm's fault anymore. maybe it's something in the way fedora treats pcmcia {interfaces}.

just to be sure, i've replaced the wireless pcmcia card with an old pcmcia wired network card and it connected immediatly.

out of ideas :(

i've tested the card on asus a3h notebook (with f10 live cd) and same thing happens, dhcpdiscover fails to aquire address.

Just tried a 40/64 bit WEP key (0123456789) with my ipw2200, latest F10 NetworkManager (NetworkManager-0.7.0-2.git20090207.fc10), and a Linksys WRT54GC.  Connection works fine.

Could you try latest updates *and* latest kernel for F-10?  This sounds more and more like a driver problem, which a newer kernel might help.

is your interface usb? or pcmcia?

i've bought today a router and one usb wireless card ralink rt2501.

i've configured the router to not use any wireless security.

the pcmcia card failed to connect, the usb card connected successfuly. (that's how i'm typing this things into bugzilla, btw :))

f10 is updated.

What brand and model is the PCMCIA card?  Can you paste in the output of both "/sbin/lspcmcia" and "/sbin/lspci" ?  I think you're right, it's looking like the driver for that card doesn't handle things correctly.

gigabyte "aircruiser g" gn-wmkg

# lspcmcia
Socket 0 Bridge:   	[yenta_cardbus] 	(bus ID: 0000:02:00.0)

# lspci | grep ardb
03:00.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)

thank you.

Created attachment 332265 [details]
lspci output

Ok, just to clarify...

NM + rtl8xxx USB -> works
NM + Broadcom 4312 -> works
NM + ralink rt2500 CardBus -> doesn't work

Is that correct?

yes, and 
NM + rlink rt2501 usb, works too.

s/rlink/ralink

Reporter, can you please so kind to check this issue with Rawhide (Live CD is available[1]) and let us know whether the issue is still happening? Thank you. 


[1] http://download.fedoraproject.org/pub/fedora/linux/releases/test/11-Beta/Live/i686/F11-Beta-i686-Live.iso


-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

i've tried with the snapshot1 i686 post beta live cd (gnome) and it's not working, both on unsecured and on wep/64bits connections. considering the number of failures, i tried another distro just to see the card working. then i've seen it working on sidux6 on unsecured connection when i used wpa_supplicant and not wireless tools. it was not working on wep protected connection on sidux either (whatever i choosed).

so, next thing i wanna do is buy a pcmcia card wich is known to work with fedora. is there such a wireless card?

thank you.

a small correction: it was not sidux6, it was sidux 2009-01.

news: i;ve been thinking, what if i try to connect using the network service instead of networkmanager? so i've found that not even the network service can connect using the pcmcia card, although it can too connect using the ralink 2501 usb card, even if they use the same driver! that means imo that the driver is buggy on the pcmcia side and not on the usb side.
also, i;ve got another idea: what if i\d try to use ndiswrapper? so i've discoverd that using the windows driver makes the pcmcia card connect. so i believe we can say beyond any doubt, that it\s not an nm or s-c-n bug, but a driver bug. remains a mistery, why on some other distros, the card worked, at least on unencrypted connections.

if you agree, i'll close this bug.

thank you for your help!

still not working on updated rawhide (f11)

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This bug has been triaged

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

still not working on f12 alpha rc2 (f11.91)
.

(In reply to comment #31)
> still not working on f12 alpha rc2 (f11.91)

Quick summary (correct me if I'm wrong):  rt2500 USB works, but rt2500 cardbus/pcmcia *doesn't* work, correct?  Does rt2500 cardbus/pcmcia work at all, or just fails for WEP networks?

yes, usb works, pcmcia doesn't. 
pcmcia fails for "no wireless security" or wep with 64bit key. wpa* is not an available option in network manager.

I think this is actually the same as bug 469120.  They both include issues connecting to networks with rt2500pci.  I've recently tested rt73usb and that works fine on F11 and F12, so I think it's just rt2500pci that's busted here.

*** This bug has been marked as a duplicate of bug 469120 ***

(In reply to comment #34)
> I think this is actually the same as bug 469120.  They both include issues
> connecting to networks with rt2500pci.

I doubt this is the case. This isn't just about rt2500pci.

Could this http://patchwork.ozlabs.org/patch/41171/ be a solution or a workaround. But I don't see this making inroads.

(In reply to comment #35)
> (In reply to comment #34)
> > I think this is actually the same as bug 469120.  They both include issues
> > connecting to networks with rt2500pci.
> 
> I doubt this is the case. This isn't just about rt2500pci.
> 
> Could this http://patchwork.ozlabs.org/patch/41171/ be a solution or a
> workaround. But I don't see this making inroads.  

No, that patch has nothing to do with the problem here.  It was specific to a problem with libertas chipsets and 32-character SSIDs and has nothing to do with WEP/WPA/etc.