Network Manager cannot connect to a WEP 128 network

Bug #205887 reported by Michael Lustfield
18
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: network-manager

This bug (114605) is being marked as a duplicate of this because it is clearly in the wrong area but I don't have a clue how to clean this up. Sorry for any hassle I cause anybody, I just feel this is important to Ubuntu and should be looked into a little more.

Original post by Daniel Lombraña
"When I try to connect with the Network Manager application to the 128 WEP network I get always a pop up asking me the passphrase. The truth is that the key is correct and if I do it by hand with the next commands I get connection:

iwconfig eth1 essid ID key KEY restricted
dhclient eth1

I don't know why NM cannot get an IP from the network."

Post by Stanleyid
"I had tested in two computers in to others APs. I got the same bug.
+ Intel Pro/Wirelss 2915ABG ---Driver - ipw2200
+ Broadcom Corporation BCM4306 802.11b/g Wireless ---- Driver - bcm43xx"

Post by Khorne
"05:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)"

My personal post
"

BAM - Exactly the bug I want to report.

First of all, I need to note that the afore mentioned method of connecting to the wireless network via command line worked 100% for me and I want to kiss you for it because this is a mission critical system.

Secondly, I want to note that I needed to disconnect the wired and then perform the commands for a successful connection.

Third, the good stuff:

06:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
Linux eaglei 2.6.24-12-generic #1 SMP Wed Mar 12 22:31:43 UTC 2008 x86_64 GNU/Linux

Connection to my home WPA2 connection seems to usually work fine.
Trying to connect to my universities wireless which is WEP w/ a 10 char hex key lead me here.

Don't know how much help this is - but I was happy to find a work around and will be happy to help get this moving along."

Revision history for this message
Michael Lustfield (michaellustfield) wrote :

I realized that when I get an IP using command line, I'm not always able to use the internet. I need to investigate more. I attached proof that I do have an IP. My evidence of no internet activity is any application in Gnome. I'll try some text based tools next time.

Revision history for this message
Richard Theil (richard-theil) wrote : I can confirm this (or similar) issue. Regression from Gutsy.

I can confirm this (or a similar issue) on a Thinkpad T41 with Atheros built-in WLAN for Hardy a6 and Xubuntu-Hardy beta live CD. This is a regression from Gutsy. I run a WLAN with a 128bit WEP key. Setup under Gutsy from nm-applet worked perfectly by just entering the passphrase as it was entered into the AP for key generation.

Behaviour under Hardy beta is that nm-applet sees the Network and asks for the key. It then stalls with both blobs gray, indicating "Waiting for passphrase". Eventually, it will ask again, to no avail.

When configuring this as suggested above (iwconfig/dhclient), things get seriously weird. I can set a key with iwconfig. This key, however, will seemingly randomly "degrade" to either another key (but always the same other key), or later even to "off". I made sure I killed nm-applet and made sure no obvious offender process runs. I renamed "iwconfig" to "iwconfig2" to make sure no other process tries to access it and put a logger in place of "iwconfig". The logger is not invoked, but the problem persists.

With a small likelyhood (about 30% of tries), an "dhclient ath0" following the iwconfig will succeed. Once that has happened, the WLAN connection stays reliable.

I save you the logs for now, because the essence is: do iwconfig, then check interfaces three times to watch three different key settings (proper key, wrong key, "off") in the worst case.

Revision history for this message
Michael Lustfield (michaellustfield) wrote :

The recent network-manager update today fixed this problem. :)

Changed in network-manager:
status: New → Fix Released
Revision history for this message
Jaime Carpenter (j.carpenter) wrote :

I am having the same problem with WEP 128 bit and Hardy Heron (beta). If a fix is available, how do I get it? I've run update manager and it tells me my system is up to date. This is a Dell D520 with Intel 3945.

Revision history for this message
Richard Theil (richard-theil) wrote : Fixed for me with hardy daily-live 2008-03-30

Got today's daily live image, booted the live cd, did the passphrase login. Flawless operation on two out of two attempts.

Revision history for this message
Mackenzie Morgan (maco.m) wrote :

Does it still work for you guys? In current Hardy using iwl4965, NM refuses my WEP key every time.

Revision history for this message
Jaime Carpenter (j.carpenter) wrote : Re: [Bug 205887] Re: Network Manager cannot connect to a WEP 128 network

It still works for me, but after an 'update' of the kernel, I had to
install the package again to match the new kernel that came with the
updates to Hardy.

Mackenzie Morgan wrote:
> Does it still work for you guys? In current Hardy using iwl4965, NM
> refuses my WEP key every time.
>
>

Revision history for this message
Mackenzie Morgan (maco.m) wrote :

Which package? network-manager? It isn't a kernel-specific package, though.

Revision history for this message
Jaime Carpenter (j.carpenter) wrote :

Mackenzie,

Originally I installed:

sudo apt-get install linux-backports-modules-2.6.24-16-generic

After running an update the kernel was updated and I had to run the command again with the correct running kernel.

You will need to use the uname -r command to determine your running kernel. I'm currently running 2.6.24-19-generic

I hope this helps.
Jaime

Mackenzie Morgan wrote:
> Which package? network-manager? It isn't a kernel-specific package,
> though.
>
>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.