[Gutsy]Network Manager Applet can't connect wireless with ipw3945 driver

Thanks for taking the time to report this bug and helping to make Ubuntu better. Could you please add the full contents of '/var/log/daemon.log' as an attachment to your bug report? Thanks in advance.

I have recreated this bug on Gutsy using network-manager version 0.6.5-0ubuntu2.

Attached is relevant information from '/var/log/daemon.log'.

I've just hit the same problem after the recent Gutsy network-manager upgrade to 0.6.5-0ubuntu2 (still running the same kernel as when it was working OK).

On my ThinkPad X60, however, I can force it to connect by toggling the kill switch on and off. It still seems to take 45 seconds to connect though, where it used to take under 10.

Jun 22 17:20:43 gutsy NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) complete.

Jun 22 17:20:45 gutsy avahi-daemon[5620]: Registering new address record for fe80::219:d2ff:fb12:ce16 on eth1.*.

Jun 22 17:21:32 gutsy NetworkManager: <info> Activation (eth1/wireless) Stage 2 of 5 (Device Configure) successful. Connected to access point 'AP'.

[..]

Jun 22 17:21:36 gutsy NetworkManager: <info> Activation (eth1) Stage 5 of 5 (IP Configure Commit) complete.

i am running gutsy on a Lenovo 3000 N100.
wireless worked perfect under feisty and i upgraded to gutsy via wireless.
after first reboot wireless worked fine.. the problem appeared after second reboot.
network manager appears on taskbar and it shows all two wireless networks a protected one and a free one.
i cant connect to none of them. and when i click on network manager icon on taskbar it dissapears.i am connected with wired network but network manager icon still dissapeared...
summing up , i cant connect to wireless networks (protected or not) and after wireless connection failure network manager icon disappears (after this i connect with wired ethernet network)

Here is my deamon.log

For informations : I started my computer cable connected and wired connection in the NM applet. Wifi switch turned off.
I turned on my wifi switch and tried to connect to an unsecured network. It treied to connect during about 2 minutes, then came back to the wired connection.

I'm confirming too. I couldn't even get WEP to connect (manually), but I believe that was just me (and me constantly changing my settings without a reboot confused it all somewhere). Open security it works fine.

except for the fact that I can't use networkmanager at the moment because of bug #121605 , under feisty it take some time to join a network.

I sometime change manually the channel , so the appropriate channel is picked up.
Under nm-applet, re-clicking on the network you want to join kindda helps sometime in joining a wireless network

It generally works for me (with the bcm43xx driver, though) with the latest packages in gutsy. Can you please upgrade network-manager and network-manager gnome and see whether they fix the connection? Thank you!

Each morning (US time) I update my system off the gutsy repos. Still no go.

With lastest Network-Manager (0.6.5-0ubuntu4), Network-Manager-Gnome (0.6.5-Oubuntu3) and kernel 2.6.22-7-generic, still doesn't connect.

Even worse now : NM-aplet crashes each time I want to connect a wireless network. In a terminal it's written : "Erreur de segmentation (core dumped)"

yostral: that crash is likely due to bug #121228

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/121228

Sorry, I don't know how to do URL links. HTML doesn't seem to work ;)

After few tests, nm crashes only when network is protected (wep, wpa...). On an open network, still the same, unable to connect.

I may be seeing this too, but can't be sure until I can get the AP rebooted (It has been flaky before).

Running wpa_supplicant manually (which I may have done wrong), I get:

CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys

wpa_passphrase SSID_IN_HERE > wpa.conf
(SSID obtained from network manager logs in /var/log/daemon.log where do I get it more "officially"?)

sudo wpa_supplicant -ieth1 -Dwext -cwpa.conf

If anyone can post some better debugging steps to test running wpa_supplicant manually, I'll give them a go.

With today's updates, network-manager-gnome 0.6.5-0ubuntu4, no more crash on encrypted network (bug 121228 fixed).

But still no connection for me with ipw3945 driver. Nothing on open network. When network is encrypted, a window open to ask for the key, but nothing happens after I entered it. Nothing about gnome-keyring and of course no connection.

If you went more information, tell which ones. I've already given my daemon.log.

i confirm yostral.
with today's updates network manager doesnt crash anymore but i cant connect to wireless network.

Same problem, I also noticed that the wired and wireless interfaces appear as eth2 and eth3 on a T60 and X60. Does anyone else see this? If not I will open a new bug elsewhere

I do

On 6/28/07, Serge <email address hidden> wrote:
>
> Same problem, I also noticed that the wired and wireless interfaces
> appear as eth2 and eth3 on a T60 and X60. Does anyone else see this? If
> not I will open a new bug elsewhere
>
> --
> [Gutsy]Network Manager Applet can't connect wireless with ipw3945 driver
> https://bugs.launchpad.net/bugs/121439
> You received this bug notification because you are a direct subscriber
> of the bug.
>

The fingers with which you are dialing are too fat. Sorry, hit send
too quickly.

Yes, my interfaces appear as eth2 and eth3 (wired and wireless respectively).
This is a dell D620.

On 6/28/07, Alan S. <email address hidden> wrote:
> I do
>
>
>
> On 6/28/07, Serge <email address hidden> wrote:
> > Same problem, I also noticed that the wired and wireless interfaces
> > appear as eth2 and eth3 on a T60 and X60. Does anyone else see this? If
> > not I will open a new bug elsewhere
> >
> > --
> > [Gutsy]Network Manager Applet can't connect wireless with ipw3945 driver
> > https://bugs.launchpad.net/bugs/121439
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>

My interfaces are ok, eth0 and eth1, on Dell Inspion 9400.

But today, gutsy doesn't recognize my kill switch button... It's a combinaison of keys, Fn+F2. In the logs it's written that the key isn't known...

So I can't test wifi anymore for the moment. If I start my computer with what I think to be on or off, it's the same, no more wifi in Gutsy.

In Feisty everything's still perfect.

Kill switch is now recognized again.

But still no connection possible even after today's update (network-manager-gnome 0.6.5-0ubuntu5).

I have a similar problem to that mentioned above. I can connect to a WPA or WEP encrypted network, but I can't connect at all to an unprotected network. Running on a Toshiba P105-S9337.

I'm also having this problem, 2.6.22-7-generic, network-manager_0.6.5-0ubuntu4, using ipw3945 on a thinkpad T60. On boot the startup scripts get a connection to any open AP properly, ifup and ifdown work fine, device names are normal (eth0 copper, eth1 wifi). After using KNetworkManager things go "awry." There is play-by-play in the attached logfile.

I have always had occasional random troubles with ipw3945 flying south on Feisty (I chalk it up to that aggravating reg daemon, will be happy when iwlwifi makes it in), but removing and re-modprobing the module has always fixed it. This did not help in this case. RF kill does not seem to affect it.

Also of note, the first time this happened, the link would be fine on boot, as above, but after NM frobbed it, ip link would show it being NO-CARRIER. I couldn't reproduce this last symptom for this report.

HTH,
Kyle

I can confirm that with the latest updates (2.6.22-7-generic, NM 0.6.5-0ubuntu4) on a ThinkPad X60 with an IPW3945, I still get:

* Connects perfectly when using WPA, and uses eth1 as expected.

* Fails to connect when using a working open AP. Toggling kill switch on/off then always allows it to connect. Uses eth1 as expected.

Open AP runs wpa_supplicant, but gets an error:

Jul 1 10:35:29 gutsy NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) starting...

Jul 1 10:35:29 gutsy NetworkManager: <info> Activation (eth1/wireless): access point 'OpenAP' is unencrypted, no key needed.

Jul 1 10:35:29 gutsy NetworkManager: <info> Old device 'eth1' activating, won't change.

Jul 1 10:35:31 gutsy NetworkManager: <info> SUP: sending command 'INTERFACE_ADD eth1^I^Iwext^I/var/run/wpa_supplicant^I'

Jul 1 10:35:31 gutsy NetworkManager: <info> SUP: response was 'OK'

Jul 1 10:35:31 gutsy NetworkManager: <info> Error opening control interface to supplicant.

Jul 1 10:35:31 gutsy NetworkManager: <WARN> real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant.

Jul 1 10:35:31 gutsy NetworkManager: <info> Activation (eth1) failure scheduled...

After a kill switch toggle, I get:

Jul 1 10:36:01 gutsy NetworkManager: <info> Activation (eth1/wireless): access point 'OpenAP' is unencrypted, no key needed.

Jul 1 10:36:01 gutsy NetworkManager: <info> SUP: sending command 'INTERFACE_ADD eth1^I^Iwext^I/var/run/wpa_supplicant^I'

Jul 1 10:36:01 gutsy NetworkManager: <info> SUP: response was 'OK'

Jul 1 10:36:01 gutsy NetworkManager: <info> SUP: sending command 'AP_SCAN 1'

Jul 1 10:36:01 gutsy NetworkManager: <info> SUP: response was 'OK'

and it continues OK.

I can confirm the open AP behavior below, but am unable to connect using WPA2

On 7/2/07, Ian Redfern <email address hidden> wrote:
> I can confirm that with the latest updates (2.6.22-7-generic, NM
> 0.6.5-0ubuntu4) on a ThinkPad X60 with an IPW3945, I still get:
>
> * Connects perfectly when using WPA, and uses eth1 as expected.
>
> * Fails to connect when using a working open AP. Toggling kill switch
> on/off then always allows it to connect. Uses eth1 as expected.
>

I also can confirm this bug running Gutsy AMD64 on my Dell D820 w/ ipw3945. I've attached the output of 'tail -n 0 -f /var/log/syslog' while trying to switch from the wired connection to wireless. I notice this bug has the 'Incomplete' status. Please let me know if there is any other information that will help get this bug resolved. It's very annoying.

This bug also appears on my Acer:

sudo lspci | grep -i ethern
02:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5789 Gigabit Ethernet PCI Express (rev 21)

There's also one other extremely fancy bug:
When connecting to wired network, the wireless also connects! But sadly for me, to different networks isn't the best way to get a stable network connection...:)

I have the same issue.

I'm using Gutsy Tribe 2 and have an Intel 3945ABG internal card.

I cannot connect on any secured mode BUT I can connect on non-secure
wired mode, but NOT wireless.

I can connect with networkmanager with ipw3945 on my private WPA-PSK secured network with the following steps reliably:

- try to connect, NM will try a bit but ask me then for a key
- press cancel on that dialogue
- retry connecting
- (quickly) turn off the hardware rf-kill switch
- after about one sec, turn on rf-kill switch
- NM connects to network successfully.

I haven't really figured out why I have to do these steps, but without them, I cannot connect to my home lan either.

That works for me as well.

On 7/12/07, Reinhard Tartler <email address hidden> wrote:
> I can connect with networkmanager with ipw3945 on my private WPA-PSK
> secured network with the following steps reliably:
>
> - try to connect, NM will try a bit but ask me then for a key
> - press cancel on that dialogue
> - retry connecting
> - (quickly) turn off the hardware rf-kill switch
> - after about one sec, turn on rf-kill switch
> - NM connects to network successfully.
>
> I haven't really figured out why I have to do these steps, but without
> them, I cannot connect to my home lan either.
>
> --
> [Gutsy]Network Manager Applet can't connect wireless with ipw3945 driver
> https://bugs.launchpad.net/bugs/121439
> You received this bug notification because you are a direct subscriber
> of the bug.
>

If I log in and my laptop starts connecting to an open access point it will fail. But if I toggle the kill switch while its still trying to make the original connection it will work.

I have the same issue as the previous commenter on a Lenovo 3000 N100. Thanks. If you need any logs, etc.. Please, let me know.

On Sony SZ3, I get the same problem where the wifi network is detecetd, tries o connect but times out. If I try the solution from Reinhard Tartler, NM connects fine!
 In /var/log/syslog:
First attachment, connects with wire, then unplug wire, try to connect to unsecure wifi

Second attachment, connects with wire, unplug wire, tries to connect to wifi, wifi switch off/on, then NM connects.

I've tested it with Gutsy Desktop-CD Tribe 3.

Bug is still present! Can't connect to a WPA-encrypted network (which works in Feisty even with the live-cd).

My hardware: intel 3945 wireless using ipw3945 driver.

I'm seeing it work fine for WEP (hex / passphrase) and WPA (passphrase) networks, however I happened across an unsecure (open) network earlier this week and couldn't connect.

The Wireless light on the laptop lit up solid (indicating association on the ipw3945), but shortly after it would start blinking again. Network manager seemed to be forcing it to re-associate again and again.

Disabling wireless in network-manager would allow the card to associate properly, and I could manually connect by running dhclient.

Fixed here by doing a 'sudo /etc/init.d/dhcdbd start' before logging into X. Now I have no clue why dhcdbd doesn't start in the first place.

I am experiencing the same problems with network-manager 0.6.4-6ubu in feisty, with a ipw3945 driver.

This could be a regression, since it works fine with feisty from the original CD, and only stopped working for me a few weeks ago (after upgrading packages? don't know).

GOOD NEWS. I've solved this problem at least for Atheros cards and if you've used update-manager to update from Feisty to Ubuntu Gutsy Tribe 3.

Turns out that Ubuntu saves the old linux-restricted-modules-2.6.20-15-generic (from Feisty) *and* the new 2.6.22-8 version (from Gutsy) when you do an upgrade. On a hunch that Ubuntu confuses NM by having two versions of this file, I tried an experiment that worked:

1. Go into Synaptic and delete the old version.
2. Then install Linux-Restricted-Modules-2.6.22-8-386 and dbus-x11 (noticing the dbus command that worked for someone above).
3. Then restart your computer.

Worked like a charm for me. I have a 128-bit WEP encyrpted wireless network on a Linksys router, and Gutsy took my passphrase with no problem. Wired network also works.

So developers, for Tribe 4, just tweak Update Manager to make sure it deletes all Linux-Restricted-Modules except one and also installs Linux-Restricted-Modules-2.6.22-8-386 and dbus-x11.

Oh, and one more tip for testers: If you can't get the highest screen res in Gutsy, install 915Resolution. It worked for me with my Intel chipset. (For Feisty I'd have to install that Intel file and delete 810, but for some reason Gutsy installs both by default. Don't delete one; it will kill your X. Just install 915Resolution alongside them, and all is well.)

Cheers!

Don't we are talking here about the ipw3945 driver for intel wireless-cards?

1. it cant't be a solution to install *-386 restricted-modules. We are working the the *-generic kernel, aren't we? In Feisty different installed kernels (and fitting kernel-headers) doesn't disrupt NM at all. Or I am wrong?

2. it is not a problem of two different installed kernels, because the ip3945 driver doesn't even work with the desktop-cd in live-mode! In live-mode you can be very sure, that only one kernel is "installed".

Hi Suzan,

I'm not sure about your questions. Though my reasons why this works might be wrong, I can confirm that this works for me for Atheros. I also suspect it will actually let NM work for any wired device that wasn't working previously in Gutsy. Any laptop these days can at least use a cable, even while getting wifi sorted.

Since I don't have an Intel wireless card, I can't confirm or deny that it works for those. But hopefully this can get some creative juices flowing toward a solution that works for all types of wireless cards. :-)

My point isn't that two different kernels are installed, but that there are two versions of restricted modules for the one installed kernel. The point is that cards using binary blobs need (I think) to have those blobs (restricted modules) loaded into a vanilla kernel, and I though that having two versions of these blobs would confuse NM.

I was working from an installed system, since most users won't run a live CD in perpetuity.

But maybe I'm just talking rubbish...

Matt

Under Tribe 1 and 2 I had both wireless problem and eth2/eth3 problem reported by Serge.
I tried Tribe 3 and it works perfectly. It connects to any kind of wirless network within few seconds, and ethernet interfaces are properly configured. Everything worked flawlessly since live boot-up without configuring and/or installing anything.
My machine is an Inspiron 6400 laptop, with intel 3945 wireless card.

@Andrea:

you mean, it works even under live-mode with Tribe3? I don't have Gutsy installed yet, I've only tested it live.

That's weird... I've tried it also with thre Tribe3 desktop-cd an it doesn't work. AND I have the exact same laptop as you, an DELL Inspiron 6400 with intel 3945 wireless-card.

I have a DELL Inspiron 9400, with the same Intel 3945 wireless chip, and I'm still unable to connect with tribe 3, Livecd or installed version.

@Suzan: Yes, I mean that under live-mode with Tribe 3, Network Manager works perfectly.
I don't know why your laptop doesn't works as well as my one... they should behave identically.

I am also having the same issue. I have a Dell E1505 /w 3945 Wireless Adapter. I can connect to an open wireless network just fine. I can connect my network with WPA Encryption /w SSID Broadcast enabled. Its not until I disable SSID Broadcast do I start expericing problems with connecting. Please help. I reported the bug here: https://bugs.launchpad.net/bugs/127660

I had success with getting WPA to work, but only if you restart DBUS completely. I'm going to do a cold start and see if DBUS seems to be the hangup.

I have done a cold start and found that there's a problem somewhere with DBUS.

My Specs:

Dell Latitude D820
Intel 3945 ABG

I did not use the kill switch, and upon restarting DBUS, I was able to connect to my AP using WPA and stay connected.

I don't know if this will help, but it's working (seems to disable my suspend and hibernate when I restart DBUS, which I expected).

Like Reinhard, Jc and Nic, if I turn on and off the kill-switch while it's trying to connect, it works... at least with an open network (I've not tried yet with wep or wpa).

If I restart dbus, it doesn't work.

And when wifi is on, I can hear a very high frequency sound, like a whistling. And I know, according to the english Ubuntu forum, I'm not the only one with this. And don't say it's because of my computer, it does that only on Gutsy. Everything works fine, without noise, in Feisty, Debian, Fedora or Windows... Strange...

On Mon, Jul 02, 2007 at 08:44:47AM -0000, Ian Redfern wrote:
>
> * Fails to connect when using a working open AP. Toggling kill switch
> on/off then always allows it to connect. Uses eth1 as expected.

What do you mean by toggling kill switch? How do you do that?

 - Alexander

The ThinkPad X60 has a wireless kill switch on the front, and using it to stop and start wireless seems to help on open networks.

After recent upgrades (now running 0.6.5-0ubuntu7) I've lost access to my WPA-protected AP, even from a vanilla Tribe 3 installation. It can connect (after a few tries), but then I get the messages

nm_policy_device_change_check:: old_dev has_link? 1

SWITCH: terminating current connection 'eth1' because it's no longer valid.

nm_device_is_802_3_ethernet: assertion `dev != NULL' failed

nm_device_is_802_11_wireless: assertion `dev != NULL' failed

and it shuts down.

I'm also getting

nm_policy_device_change_check:: old_dev has_link? 1

nm_policy_device_change_check:: old_dev && new_dev!!

in the log every 130 seconds throughout the day.

I also have a Dell Inspiron 6400 (a.k.a. E1505) with ipw3945. It worked flawlessly under Feisty.

An interesting note: since I upgraded to Gutsy, ipw3945 connects to networks that I don't want it to connect to. Some neighbour has a network with SSID "default". If ipw3945 connects to default before NetworkManager gets a chance to say "hey! connect to home_ssid!", I'm up a creek without a paddle.

If, however, I restart ipw3945 and manage to click my home network in KNetworkManager *before* ipw3945 connects to 'default', I get normalcy.

Or, one time, X froze.

Anyway, do other people see this behaviour (connecting to open networks "automagically")?

Jon Anderson <email address hidden> writes:

> Anyway, do other people see this behaviour (connecting to open networks
> "automagically")?

I assumed that this was a 'feature' of NM? - So yes, I notice this as
well from time to time.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Using a HP 6710b with ipw3945. I can connect to an unsecured network, but can not connect to a WPA2-Enterprise network.

Regarding Matt Donnelly's comment about 'any laptop these days can at least use a cable': not always. At my university, student laptops are only allowed to connect via wireless (and only with WPA2-Enterprise/AES/TTLS/Pap... which means no connecting with 64bit Vista either :p). ITS will not allow non-ITS managed machines to have their MAC addresses registered for wired connection.

> I assumed that this was a 'feature' of NM? - So yes, I notice this as
> well from time to time.

But I'm not talking about NM... since upgrading to Gutsy, my laptop connects to random open networks before NM is even involved in the process:

 - before I log in (my KNetworkManager settings are in my KWallet, so
   it used to be that wireless networking was a post-login thing)
 - immediately after rmmod ipw3945 && modprobe ipw3945, while
   KNetworkManager still shows "No Wireless Networks Found"

Thus, if NM isn't doing the connecting, the driver must be. This messes things up, so NM can't do its job anymore. Using 'sudo iwconfig', I see things like:

 - ESSID: "default" even though NM is trying to connect to "home"
 - my home encryption key being used with my neighbour's network

So, I seem to have a pretty serious disconnect between NM and the ipw driver, with the driver doing all sorts of things (e.g. connecting to networks) that NM is supposed to be in charge of. This is the behaviour of which I ask, "does anybody else see this as well, or should I file a new bug?"

I'm also seeing this on Gutsy. iwconfig shows

eth1 IEEE 802.11g ESSID:"Belkin54g"

which is my neighbour's open access point, not my WPA one - I'm currently connected by Ethernet from eth0, and there is no mention of this ESSID in /var/log/daemon.log.

For people seeing the problem that Ian Redfern and I have, please confirm Bug #129213.

same problem here on a Compal Hel80 with Intel 3945.

unsecured yes. WPAed no.

Had it connected to my WPAed AP while i was using tribe 3 live-cd to install. just had to enter the key 2 or 3 times.

I can report an improvement with WPA - 0.6.5-0ubuntu7/2.6.22-8-generic reliably connects on the third attempt.

The first attempt (automatic at login) gives a prompt for my WPA key. If I cancel this, then choose my network from the list, it connects correctly without prompting (I use pam_keyring, although this works without it), then immediately disconnects with the messages

<info> Activation (eth1) successful, device activated.

<debug> [1185866897.251316] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of wireless network 'SecureAP'

<info> nm_policy_device_change_check:: old_dev has_link? 1

<info> SWITCH: terminating current connection 'eth1' because it's no longer valid.

When I select it manually again, it connects and stays connected. I get the same set of messages, except for the SWITCH one - instead I get

<info> nm_policy_device_change_check:: old_dev && new_dev!!

This has worked reliably for me across several reboots - I suggest that anyone having WPA problems should try repeated logins.

hi,
after some canceling and inserting the key several times i finally get a connection. still have to find out the exact steps...

but there seems to be some general problem with the keyring. maybe this is related. at least for me it doesn't save any keys. not for nm-applet or any other program. i looked for the latest bugs ( https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=keyring&orderby=-datecreated&search=Search&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= ) and found some related stuff as well as a duplicate of this bug ( https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/122653 ).

just wanted to let you know...

A few additional data points:

On my notebook (Dell Latitiude D820, fully updated gutsy as of August 1 2007, kernel 2.6.22-9-generic):

The wireless kill switch trick works (documented in comments on this bug already)

 swapping out the 3945 card with an Atheros card results in NetworkManager working as expected (other than the longstanding "can't associate with hidden networks" bug).

Switching to the iwl3945 driver also results in NetworkManager working as expected (until the driver does horribly during suspend/resume)

Dropping back to the Feisty kernel (2.6.20-16-generic) also results in a working system.

I can now (from when I could ? I don't know) connect to an wep encrypted network with NetworkManager, without switching the kill switch button. But I still need to do that with an unencrypted one.

I use Gutsy up to date :
 - kernel : 2.6.22-9-generic
 - Network manager : 0.6.5-0ubuntu7
 - Network manager gnome : 0.6.5-0ubuntu8

I use ipw3945 driver.

I can notice now too that I can't hear my wifi whistling anymore, as I said before.

On Thursday 02 August 2007 17:15, yostral wrote:
> I can now (from when I could ? I don't know) connect to an wep encrypted
> network with NetworkManager, without switching the kill switch button.
> But I still need to do that with an unencrypted one.

I am also now in the same boat after dist-upgrade. Thinkpad T60 with ipw3945.

pissboy@dsr:~$ apt-cache show linux-image-2.6.22-9-generic \
   network-manager knetworkmanager | egrep '^Ver|^Pack'
Package: linux-image-2.6.22-9-generic
Version: 2.6.22-9.21
Package: network-manager
Version: 0.6.5-0ubuntu7
Package: knetworkmanager
Version: 1:0.2~r686534-0ubuntu1

WEP networks connect fine, have to use the kill switch trick on open ones.

Additionally, KNetworkManager is now acting funny, the first time I try to
select a network after login, I have to tell it to connect to a particular
network twice, the first time I select it, the icon just blinks at me and
then continues doing whatever it was doing (either automatically connecting
to some network I'm not interested in, or sitting there disconnected).
Obviously this may be a separate bug, but thought I'd throw it out there.

Kyle

Please try the latest gutsy network-manager packages (version 0.6.5-0ubuntu8). They have a lot of related fixes.

Still not working for me. I just did an upgrade and rebooted.

network-manager is still 0.6.5-0ubuntu7 , network-manager-gnome is 0.6.5-0ubuntu8 .

but no improvements.

this bug is really nasty....

I also can confirm it still doesn't work. In fact prior to today's gutsy update I was able to connect to my wireless network (WEP) although it was way slow. But now I cannot connect wireless at all (Intel 3945). Tried several workarounds and reboots and the result is always the same. The gray balls spin, never go green, and seem to be stuck on my WEP network. I try to click on open networks that show up in the list and it stays stuck on my network, and it also won't let me select wired network after I plug in ethernet. Also: nm-applet crashed immediately after installing the last gutsy update. I wasn't even able to get ethernet going until I reinstalled network-manager and network-manager-gnome.

Joy, at least for me. There's a new gutsy network-manager update out there (had to click check in update-manager to see it). My 3945 wireless is back to working now.

Any chance the fix for this will make it back into Feisty? Or does the fact that I'm seeing the same problem in Feisty since a few weeks ago mean that something else is wrong?

Shoofy, like you, I started experiencing this problem on Feisty a few weeks ago (see earlier comment and also-affects).

Do we know whether this is really the same problem?

with network-manager 0.6.5-0ubuntu9 it takes approx. 30 secs to connect to my WPAed network and still the key is not stored in keyring, although it is asking for the master key every time. but i think this is another problem as happens with other stuff like connecting to servers as well.

besides that it works! so, thx so far!

This was confirmed as fixed for two people, Chris still experienced it. Chris, can you please check with 0.6.5-0ubuntu9 again?

Moving over to Tribe 5, this is not a blocker any more since it seems to work now.

No luck for me either. Network manager still doesn't want to connect to wpa2-enterprise network, (works fine in Fedora 7, so I know network manager *can* do it). I never got the various workarounds to work either, though I have not had trouble using wpa_supplicant manually. I'll try again tomorrow after purging and reinstalling network-manager et al, and using clean gconf.

My wireless seems to work fine with Wicd, which tells me that my problem (on Feisty) was definitely with NetworkManager, not anything else. I'd really like this fix to make it back to Feisty, since I like NetworkManager more than Wicd.

network-manager 0.6.5-0ubuntu9 should fix wpa for ipw3945 ... if it doesn't for you please let us know.

> network-manager 0.6.5-0ubuntu9 should fix wpa for ipw3945 ... if it doesn't for you please let us know

and what about Feisty, is it the same problem, and if yes, will the package be available for Feisty too?

no, network-manager 0.6.5-0ubuntu9 still has not fixed the problem for me. i just waited for well over a minute to connect to my unencrypted network and finally had to toggle my switch off and on for it to work. as soon as i toggle the switch it connects immediately.

NAK - Still broken here.

ii network-manager 0.6.5-0ubuntu9 network management framework daemon
ii network-manager-gnome 0.6.5-0ubuntu8 network management framework (GNOME frontend)

(Is there an update pending for network-manager-gnome which is needed, and I've not got yet?)

Symptom here is a failure to associate to the wep network, with repeated prompting for the password.

Workaround is:

sudo /etc/dbus-1/event.d/25NetworkManager stop
gconftool-2 --recursive-unset /system/networking/wireless/networks/<NAME_OF_NETWORK>
sudo /etc/dbus-1/event.d/25NetworkManager start

It will then connect properly.

I also noted that when on an unsecure network recently, I still had to do the RF-Kill Off / On whilst assocating trick. This "feels" like its becase the ipw3945 driver manages to associate to any unsecure network it finds (might / might not be correct) _without_ network manager, and network-manager causes it to un-associate. It then fails to associate correctly with the desired network, and the RF-Off /On cycle perhaps kicks the driver into finding something (Does it always find the one you asked for?).

I have a Dell D820 with an intel 3945, and under gutsy I also have to switch my wireless switch on and off to connect with network manager. I'm running current gutsy with network-manager 0.6.5-0ubuntu9. This happens _every_ time I try to connect to my open wireless network (I don't have any wep/wpa networks to try on right here), whether it's first boot, or coming back from suspend, or just switching networks.

Still no luck today. It is doing better than yesterday... actually gets a key now, whereas before it would never manage to get a key. But now it times out while trying to associate. (Check the log excerpt)

I seem to be doing better since the update... still had a problem last night, but things are going swimmingly.

Lenovo T61, ipw3945, network-manager 0.6.5-0ubuntu9 won't connect to an open AP. It associates fine, but doesn't get an address via DHCP. I run sudo dhclient3 eth1 manually as a workaround.

Here's an interesting message that appears in /var/log/user.log when I try to connect with Network Manager:

    dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason

I managed to connect for a few seconds!
All I had to do was to pull the plug from my fonera, and I was able to connect to my WRT54GL running DD-WRT with WPA2. It seems the open network on the fonera kept messing things up, as NM would connect to it while trying to connect to WPA2. Now the only problem is that it seems to find a better network with the same SSID, disconnects and never reconnects. I am attaching the relevant parts of syslog.

I have a Thinkpad T60 with Kubuntu Gutsy just installed and fully updated. I cannot connect to my college's unsecured wireless network unless I use the RF kill-switch on the front to toggle the device off and then on again while it attempts to connect. According to daemon.log (which I have attached), it fails because it takes too long and times out.

ThinkPad X60 with intel chipset here. NetworkManager can't connect to the wireless network either for me. But it's all set up so I just need to run

sudo dhclient eth1

in the terminal and I get an IP address and am good to go.

As I said here [1], the applet works well under Tribe4 (both Live-mode and installed). "works well" means that it connect to the wireless network without problems.

Anyway, now It isn't capable of storing the network key. At every boot, it asks for the key again, and you can understand this is very annoying. This problem was not present under Tribe3 and before.

My hardware is not changed (Inspiron 6400 with 3945 network card) and my network is (un)protected by a wep 128bit Hex key.

[1] https://bugs.launchpad.net/ubuntu/gutsy/+source/network-manager/+bug/121439/comments/41

Tested with Tribe 4 Desktop-CD in live-mode:

still no luck to connect to an WPA-encrypted network.

(Dell Inspiron 6400 with intel 3945 wireless)

This is a REALLY nasty bug, 'cause with feisty the intel 3945 wireless chip is the best supported wireless-chip at all, supports every encryption.

I still am not able to associate with wireless networks until the kill switch is toggled after powering up or a suspend/resume cycle. I am currently running network-manager_0.6.5-0ubuntu9 and using the ipw3945 driver.

I would like for everyone to try this. I just turned on my laptop, opened a terminal and performed and apt-get update without thinking. Then I noticed that the network manager was still trying to connect. The weird thing is that the update downloaded. So I figured that I would try a apt-get upgrade. That also began to download. It worked fine until network-manager timed out and then the download stopped.

I tried to re associate but it wouldn't connect this time until I toggled the switch.

On Wed, Aug 08, 2007 at 02:23:57PM -0000, Chris Lovett wrote:
> no, network-manager 0.6.5-0ubuntu9 still has not fixed the problem for
> me. i just waited for well over a minute to connect to my unencrypted
> network and finally had to toggle my switch off and on for it to work.
> as soon as i toggle the switch it connects immediately.
>

does your network have broadcast ssid enabled ... or are you trying to
connect to hidden network?

 - Alexander

On Wed, Aug 08, 2007 at 11:02:35PM -0000, Peter Clifton wrote:
> NAK - Still broken here.
>
> ii network-manager 0.6.5-0ubuntu9 network management framework daemon
> ii network-manager-gnome 0.6.5-0ubuntu8 network management framework (GNOME frontend)
>
> (Is there an update pending for network-manager-gnome which is needed,
> and I've not got yet?)
>
> Symptom here is a failure to associate to the wep network, with repeated
> prompting for the password.

0.6.5-0ubuntu9 only approaches wpa-psk for ipw3945 in not-hidden networks ...

>
> Workaround is:
>
> sudo /etc/dbus-1/event.d/25NetworkManager stop
> gconftool-2 --recursive-unset /system/networking/wireless/networks/<NAME_OF_NETWORK>
> sudo /etc/dbus-1/event.d/25NetworkManager start
>
> It will then connect properly.
>
> I also noted that when on an unsecure network recently, I still had to
> do the RF-Kill Off / On whilst assocating trick. This "feels" like its
> becase the ipw3945 driver manages to associate to any unsecure network
> it finds (might / might not be correct) _without_ network manager, and
> network-manager causes it to un-associate. It then fails to associate
> correctly with the desired network, and the RF-Off /On cycle perhaps
> kicks the driver into finding something (Does it always find the one you
> asked for?).
>

this is all for wep?

 - Alexander

On Thu, Aug 09, 2007 at 04:48:22AM -0000, TorenC wrote:
> I have a Dell D820 with an intel 3945, and under gutsy I also have to
> switch my wireless switch on and off to connect with network manager.
> I'm running current gutsy with network-manager 0.6.5-0ubuntu9. This
> happens _every_ time I try to connect to my open wireless network (I
> don't have any wep/wpa networks to try on right here), whether it's
> first boot, or coming back from suspend, or just switching networks.
>

open networks are known to still cause issues, please *only*
confirm/unconfirm not-hidden wpa networks for the time being.

Thanks,

 - Alexander

On Thu, Aug 09, 2007 at 05:50:59AM -0000, Ashton Batty wrote:
> Still no luck today. It is doing better than yesterday... actually gets
> a key now, whereas before it would never manage to get a key. But now it
> times out while trying to associate. (Check the log excerpt)

Can you try WPA-PSK as well; I assume you have EAP?

 - Alexander

Alexander, my ssid is set to broadcast. The network is also open.

Sorry, I have no control over the network, and must use EAP-TTLS/PAP. The key type can either be AES-CCMP or TKIP.

Confirm with IPW3945 on Lenovo N100 0768 with Gutsy Tribe 4. The driver is not associating at all with the AP, although it can clearly detect the SSID.

I get a timeout if the network is open and a 'not ready' if the network is set up with WPA-PSK. More details at bug #131546

I've done a bit more work on this to see if I can get everything in.

If I do a manual configuration, switch off roaming mode and enter the SSID details by hand then I can get an association and the network works.

Process to reproduce:

Restart access point.
Restart laptop in roaming mode.
Login.
Fire up a terminal running 'iwevent' and 'tail -f /var/log/daemon.log'
Enter incorrect WPA password.
 - Network manager will now try and associate with access point, and eventually ask for a new key (usually in a minimised window which is annoying).
Enter correct WPA password.
- Network manager will log an assertion failure 'nm_utils_supplicant_request_with_check: assertion 'ctrl !=NULL' failed. This comes after a 'Error opening supplicant global control interface' earlier on.
- Association fails.
- (You get the same association failure without the assertion fault if you enter the correct WPA password first time).
Select manual configuration and enter 'network admin' password.
Switch off roaming mode on the wireless and select the ESSID from the drop down list.
Enter the correct WPA password and select DHCP configuration.
- Access point will associate correctly.
Go back into the wireless configuration and switch 'roaming mode' back on.
- Once network manager wakes up, it will associate correctly with the AP (and probably ask for the WPA password again - probably with a window in the background or minimised).
If you now reboot the machine, then network manager appears to work correctly (although it doesn't retrieve the WPA password from the keyring - you have to enter it again). Multiple reboots appear to have the same effect until the AP is restarted

I would just like to add that I have reproduced the following statement on every boot up:

"I would like for everyone to try this. I just turned on my laptop, opened a terminal and performed and apt-get update without thinking. Then I noticed that the network manager was still trying to connect. The weird thing is that the update downloaded. So I figured that I would try a apt-get upgrade. That also began to download. It worked fine until network-manager timed out and then the download stopped.

I tried to re associate but it wouldn't connect this time until I toggled the switch."

I think the problem might be linked with bug number 128116. What makes me think so is that while nm is trying to connect (until it times out), latest info displayed in daemon.log is :

Aug 12 14:49:18 franck-gusty NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) complete.
Aug 12 14:49:23 franck-gusty NetworkManager: <info> nm_policy_device_change_check:: old_dev has_link? 1
Aug 12 14:49:23 franck-gusty NetworkManager: <info> Old device 'eth1' activating, won't change.

Then, if I switch wireless radio on and off, nm will connect, and here is what it says next :

Aug 12 14:50:02 franck-gusty NetworkManager: <debug> [1186923002.350925] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_44e_300d_019c0ec2_if2').
Aug 12 14:50:02 franck-gusty hcid[5385]: Device hci0 has been activated
Aug 12 14:50:02 franck-gusty NetworkManager: <debug> [1186923002.369241] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_44e_300d_019c0ec2_if0').
Aug 12 14:50:02 franck-gusty NetworkManager: <debug> [1186923002.379087] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_44e_300d_019c0ec2_if0_bluetooth_hci').
Aug 12 14:50:02 franck-gusty NetworkManager: <debug> [1186923002.409693] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_44e_300d_019c0ec2_if1').
Aug 12 14:50:02 franck-gusty NetworkManager: <debug> [1186923002.440255] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_44e_300d_019c0ec2_usbraw').
Aug 12 14:50:07 franck-gusty NetworkManager: <info> nm_device_set_active_link start
Aug 12 14:50:07 franck-gusty NetworkManager: <info> Activation (eth1/wireless) Stage 2 of 5 (Device Configure) successful. Connected to access point 'fougeres'.
Aug 12 14:50:07 franck-gusty NetworkManager: <info> Activation (eth1) Stage 3 of 5 (IP Configure Start) scheduled.
Aug 12 14:50:07 franck-gusty NetworkManager: <info> Activation (eth1) Stage 3 of 5 (IP Configure Start) started...
Aug 12 14:50:08 franck-gusty NetworkManager: <info> Activation (eth1) Beginning DHCP transaction.
Aug 12 14:50:08 franck-gusty NetworkManager: <info> Activation (eth1) Stage 3 of 5 (IP Configure Start) complete.
Aug 12 14:50:08 franck-gusty NetworkManager: <info> DHCP daemon state is now 12 (successfully started) for interface eth1
Aug 12 14:50:09 franck-gusty NetworkManager: <info> DHCP daemon state is now 1 (starting) for interface eth1
Aug 12 14:50:12 franck-gusty NetworkManager: <info> DHCP daemon state is now 4 (reboot) for interface eth1
Aug 12 14:50:12 franck-gusty NetworkManager: <info> Activation (eth1) Stage 4 of 5 (IP Configure Get) scheduled...
Aug 12 14:50:12 franck-gusty NetworkManager: <info> Activation (eth1) Stage 4 of 5 (IP Configure Get) started...
Aug 12 14:50:12 franck-gusty NetworkManager: <info> Retrieved the following IP4 configuration from the DHCP daemon:
Aug 12 14:50:12 franck-gusty NetworkManager: <info> address 192.168.0.5
Aug 12 14:50:12 franck-gusty NetworkManager: <info> netmask 255.255.255.0
Aug...

I managed to connect today. I did nothing special... I firstly failed to connect to a unsecured network, but then after that failed, I tried the WPA2 EAP-TTLS/PAP network, and it connected. NM still doesn't store anything in the gnome-keyring, which seems broken in general. Will investigate a bit more tomorrow, if I get the chance.

Don't know if it has anything to do with the problem, but I also get this error (after the connecting process begins, ie after I switch the radio button off and on) :

Aug 13 15:45:20 franck-gusty dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.host_name
Aug 13 15:45:20 franck-gusty dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.nis_domain
Aug 13 15:45:20 franck-gusty dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.nis_servers

Does this give any hint ?

On Mon, Aug 13, 2007 at 10:41:33AM -0000, Ashton Batty wrote:
> I managed to connect today. I did nothing special... I firstly failed to
> connect to a unsecured network, but then after that failed, I tried the
> WPA2 EAP-TTLS/PAP network, and it connected. NM still doesn't store
> anything in the gnome-keyring, which seems broken in general. Will
> investigate a bit more tomorrow, if I get the chance.
>

WPA should be fixed for most (if you broadcast ssid). Open Network is
still a problem and we probably need a driver update to approach this.

 - Alexander

we should take a close look for tribe-6

Good news: It works now! No problems to connect to an WPA encrypted network!

At least for my installed Gutsy. For the live-cd (daily-build from yesterday) I have to reactivate network and wireless and activate it again. After that I was able to connect to my WPA network.

Tested with my Dell Inspiron 6400 with Intel 3945 wireless.

WPA is now working every time for me too (with broadcast SSID).

I can't connect to my open AP from my Thinkpad X60 with Intel ipw3945. I also see that toggling the wifi kill switch makes things work.

I ran a packet capture and I only see ICMPv6 messages. After I toggle the kill switch, IPv4 DHCP is performed. I've attached part of the capture below. Frame 5 is where DHCP starts after I toggle the wifi kill switch.

No. Time Source Destination Protocol Info
      1 0.000000 fe80::213:2ff:fe08:da2c ff02::2 ICMPv6 Router solicitation
      2 3.999749 fe80::213:2ff:fe08:da2c ff02::2 ICMPv6 Router solicitation
      3 4.727754 fe80::213:2ff:fe08:da2c ff02::16 ICMPv6 Multicast Listener Report Message v2
      4 7.999758 fe80::213:2ff:fe08:da2c ff02::2 ICMPv6 Router solicitation
      5 18.383935 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x6ca4ee0f
      6 18.391796 192.168.30.1 192.168.30.199 DHCP DHCP ACK - Transaction ID 0x6ca4ee0f
      7 18.394018 192.168.30.1 192.168.30.199 DHCP DHCP ACK - Transaction ID 0x6ca4ee0f
      8 18.423733 192.168.30.199 224.0.0.22 IGMP V3 Membership Report
      9 18.451764 192.168.30.199 224.0.0.22 IGMP V3 Membership Report
     10 18.727888 192.168.30.199 224.0.0.251 MDNS Standard query ANY pip.local, "QM" question ANY 199.30.168.192.in-addr.arpa, "QM" question ANY pip [00:13:02:08:da:2c]._workstation._tcp.local, "QM" question
     11 18.787841 192.168.30.199 224.0.0.251 MDNS Standard query response PTR _workstation._tcp.local PTR pip [00:13:02:08:da:2c]._workstation._tcp.local
     12 18.979848 192.168.30.199 224.0.0.251 MDNS Standard query ANY pip.local, "QM" question ANY 199.30.168.192.in-addr.arpa, "QM" question ANY pip [00:13:02:08:da:2c]._workstation._tcp.local, "QM" question
     13 19.231834 192.168.30.199 224.0.0.251 MDNS Standard query ANY pip.local, "QM" question ANY 199.30.168.192.in-addr.arpa, "QM" question ANY pip [00:13:02:08:da:2c]._workstation._tcp.local, "QM" question
     14 19.432005 192.168.30.199 224.0.0.251 MDNS Standard query response HINFO, cache flush I686 LINUX A, cache flush 192.168.30.199 PTR, cache flush pip.local SRV, cache flush 0 0 9 pip.local TXT, cache flush
     15 19.471717 :: ff02::16 ICMPv6 Multicast Listener Report Message v2

I'm not near an open network to try, but are open networks still an issue? They appeared to be a few days ago last time I tried to use one (2007-08-23).

Seems the network card associates before NW manager asks it to. Digging at the ipw3945 sourcecode, there is an option for that behaviour:

module_param(associate, int, 0444);
MODULE_PARM_DESC(associate, "auto associate when scanning (default 0 off)");

There is also an option to auto-create an ad-hoc network if needed, default as on.

If the card "appears" to be associating to some open networks without network manager asking it, is there:

 a) Some bug in the driver ignoring this option
 b) Some bug in NW manager actually asking for the assocation
 c) Some other script causing the association or setting this parameter when loading ipw3945

Could I request that when a fix is released, some technical details of what that was, or what the problem is believed to be is posted.
Perhaps a link to a commit in http://kernel.ubuntu.com/git or some other SCM where changes are made?

I realise that for Fiesty and other released versions this is less important, and many users won't care about these details, but for Gutsy (or any development branch) bug reports, I can imagine the people testing might be interested in the debugging process. Whilst I'm much more familiar developing / debugging GTK+ applications, I do try and read the sources / follow fixes for any bug I encounter as a way of learning from those who know enough solve the problem.

Kind regards,
Peter Clifton

Stupidity kicking in... point c) above: my "fixwifi.sh" script which I used to unprobe and re-probe the ipw3945 driver had associate=1 set as a parameter. (DOH!)

I was probably seeing the association because after suspend (which _should_ work with ipw3945), the wireless often stops working, or the regulatory deamon exits and it all needs re-loading, and I would run this little script.

Isn't this a dupe of bug 119563?

I confirm the same bug on a fresh install of Gutsy Tribe 5 on my HP DV 6373 laptop.

I'm still experiencing the bug (bugs?). Rarely it has connected without any apparent problems, but most times it doesn't work. I haven't had the time or the chance to explore the problems methodically. My last post was the first of three times it has connected to the WPA2 network successfully during the last fortnight.

Still bugs here as well with WPA Personal.

Plugging in the "wired" works fine.

Sometimes wireless works and most of the time it doesn't.

I have an Acer TravelMate 8210 with the ipw3945 chipset, running Gusty Tribe 5 fully updated via Update Manager.

I cannot connect to Open or WPA Networks.

I have modprobed, dbus'ed and switched on an off - with no luck.

I have tried network-manager and iwconfig. The networks are visible in both applications, but I cannot connect to them with either - leading me to believe there is a kernel / ip3945 interaction problem.

Wired works fine.

Here is my syslog from a network-manager connection attempt. Eth0 is my wired interface, Eth1 is my ipw3945 interface.
The short description is "it just sits and spins...." ;)

------------------

Aug 27 21:39:43 Fry kernel: [46151.400000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
^[[A^[[BAug 27 21:39:49 Fry NetworkManager: <info> User request to enable wireless.
Aug 27 21:39:49 Fry NetworkManager: <info> nm_policy_device_change_check:: old_dev has_link? 1
Aug 27 21:39:49 Fry NetworkManager: <info> nm_policy_device_change_check:: old_dev && new_dev!!
Aug 27 21:39:50 Fry kernel: [46158.980000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
Aug 27 21:39:58 Fry kernel: [46166.564000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
Aug 27 21:40:03 Fry NetworkManager: <info> nm_policy_device_change_check:: old_dev has_link? 1
Aug 27 21:40:03 Fry NetworkManager: <info> nm_policy_device_change_check:: old_dev && new_dev!!
Aug 27 21:40:05 Fry kernel: [46174.148000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
Aug 27 21:40:08 Fry NetworkManager: <debug> [1188268808.518903] nm_device_802_11_wireless_get_activation_ap(): Forcing AP 'Skippy'
Aug 27 21:40:08 Fry NetworkManager: <info> User Switch: /org/freedesktop/NetworkManager/Devices/eth1 / Skippy
Aug 27 21:40:08 Fry NetworkManager: <info> Deactivating device eth1.
Aug 27 21:40:08 Fry avahi-daemon[28208]: Withdrawing address record for 169.254.5.252 on eth1.
Aug 27 21:40:08 Fry avahi-daemon[28208]: Leaving mDNS multicast group on interface eth1.IPv4 with address 169.254.5.252.
Aug 27 21:40:08 Fry avahi-daemon[28208]: Interface eth1.IPv4 no longer relevant for mDNS.
Aug 27 21:40:08 Fry dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason
Aug 27 21:40:08 Fry NetworkManager: <info> Device eth1 activation scheduled...
Aug 27 21:40:08 Fry NetworkManager: <info> Deactivating device eth0.
Aug 27 21:40:08 Fry dhclient: There is already a pid file /var/run/dhclient.eth0.pid with pid 28642
Aug 27 21:40:08 Fry dhclient: killed old client process, removed PID file
Aug 27 21:40:08 Fry dhclient: DHCPRELEASE on eth0 to 192.168.77.1 port 67
Aug 27 21:40:08 Fry avahi-daemon[28208]: Withdrawing address record for 192.168.77.104 on eth0.
Aug 27 21:40:08 Fry avahi-daemon[28208]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.77.104.
Aug 27 21:40:08 Fry avahi-daemon[28208]: Interface eth0.IPv4 no longer relevant for mDNS.
Aug 27 21:40:09 Fry avahi-daemon[28208]: Withdrawing address record for fe80::216:36ff:fe89:7fb5 on eth0.
Aug 27 21:40:09 Fry NetworkManag...

I think this might be related to bug #131553. Note the last comment I made on that one; it may be that the problems with the 3945 wireless driver and Network Manager are affecting wired ethernet as well.

I have Dell Latitude D820, and since upgrading to Gutsy from Feisty, I couldn't even see the wireless network card under "System > Administration > Network". (it also could not find the ipw3945 driver by modinfo ipw3945)

As it turns out - I was always selecting the 386 kernel from the Grub boot menu. Now I tried the Generic (!) kernel, and the wireless connection works! It shows the available connections and I could connect to an unsecured network. The generic kernel is also mentioned at the original bug report of this thread.

I created a home network with WPA-PSK authentication with a passphrase and was able to connect to that network. If anyone needs more details about my laptop (dell latitude d820) hardware or ubuntu setup, please ask.

I am using
   - "linux-restricted-modules-generic" version 2.6.22.10.11 and
   - "network-manager" version 0.6.5-0ubuntu9 and
   - "linux-image-2.6.22-10-generic" version 2.6.22-10.30

Someone else with the same problem. Gutsy, upgraded from Feisty, refuses to connect to any secured network, but will connect just fine with unsecured networks. Running the latest NM and knetworkmanager on an HP nx7300 with ipw3945. Connecting to WPA networks didn't work for me in Feisty either (although I was only using Fesity for about a week before I went for gutsy).

Will try the killswitch trick to see if that makes any difference, but still very BUGBUGBUG...!

BTW, how do we get status away from "incomplete"?

It looks like everything works fine with iwl3945 (except for the wireless light on my Thinkpad not lighting up). Is there anything that prevents that driver being the default?

Alex, you say everything works with iwl drivers using network-manager? If so, could you please post easy instructions how to test iwl driver here, so people with this issue can verify if it helps?

Thanks,

  - Alexander

I can confirm this bug.
I am unable to connect to my home router using WPA2 Personal and AES encryption (SSID broadcast disabled). It was possible in Feisty, but it is not in Gutsy as far as I remember.
Lastly I tried it in daily-live build 20070831.
I have Intel PRO/Wireless 3945ABG.

Here's what I did to use the iwl3945 driver:
sudo modprobe -r ipw3945
sudo modprobe -i mac80211
sudo modprobe -i iwl3945
sudo /etc/init.d/networking restart

Note: iwl3945 will use wlan0 as the interface instead of eth1 (at least on my hardware). Also, it seems that loading iwl3945 automatically unloads ieee80211.

I was able to connect to an unsecured wireless network and access the internet. I do not have a secured network to try it with, so I don't know if that works.

On Fri, Aug 31, 2007 at 05:55:10PM -0000, Alex Wauck wrote:
> Here's what I did to use the iwl3945 driver:
> sudo modprobe -r ipw3945
> sudo modprobe -i mac80211
> sudo modprobe -i iwl3945
> sudo /etc/init.d/networking restart
>
> Note: iwl3945 will use wlan0 as the interface instead of eth1 (at least
> on my hardware). Also, it seems that loading iwl3945 automatically
> unloads ieee80211.
>
> I was able to connect to an unsecured wireless network and access the
> internet. I do not have a secured network to try it with, so I don't
> know if that works.
>

Alex, does Network Manager itself work with this? e.g. what do you
have in /etc/network/interfaces?

 - Alexander

On Fri, Aug 31, 2007 at 05:08:34PM -0000, Petr Nemec wrote:
> I can confirm this bug.
> I am unable to connect to my home router using WPA2 Personal and AES encryption (SSID broadcast disabled). It was possible in Feisty, but it is not in Gutsy as far as I remember.
> Lastly I tried it in daily-live build 20070831.
> I have Intel PRO/Wireless 3945ABG.
>

Petr, please try the workaround in gutsy that Alex suggested:

/etc/dbus-1/event.d/25NetworkManager stop
sudo modprobe -r ipw3945
sudo modprobe -i mac80211
sudo modprobe -i iwl3945
# optional (try?): sudo /etc/init.d/networking restart
/etc/dbus-1/event.d/25NetworkManager start

 - Alexander

After I switched to iwl3945, Network Manager didn't seem to see the new interface. I think restarting networking did ifconfig wlan0 up, so maybe that's all that needed to be done for Network Manager to see it. I didn't have to restart Network Manager. I'll see if I can figure out how to make iwl3945 the default instead of ipw3945 and post the instructions here. There must be a relatively non-painful way to do it.

I tried iwl3945, but it creates the interface wlan0_replace - which isn't seen by network manager. I've tried modinfo to see if I could specify the interface in the modprobe options, but couldn't find a related option.

Alexander Sack: I tried it, just on a live CD (yesterdays build), exactly like you wrote, even with that optional step, but after I start Network Manager again, Apport appears and it says "Network Manager closed unexpectedly".
I will try to install it on a hdd, yet, and see whether it changes something.

Alexander Sack: ...When installed on hdd, the Network Manager is not already crashing after restart, but the wireless disappeared from the NM.
Tried again with and without that optional step.

I didn't get wlan0_replace, but I did have to remove iwl3945 and reinsert it before I got wlan0 and wmaster0. I suspect that has something to do with ipw3945 having been loaded previously. So, to recap:
sudo modprobe -r ipw3945
sudo modprobe mac80211
sudo modprobe iwl3945
sudo modprobe -r iwl3945
sudo modprobe iwl3945

I then had to run iwlist wlan0 scanning to get it to scan for networks.

It just blew up. I hadn't tested it much, and now I'm having trouble removing the module, I don't have network access, and everything is generally screwed up. Apparently wlan0 is in use and the kernel isn't letting me do much of anything.

 A couple a weeks ago I´ve upgrades to gutsy wireless was not working I
follow the trick to turn on/off the wireless switch while connecting and
this worked 50% of the time.

But I've keep feisty kernel 2.6.20 for the "just in case" situation and when
booting with this kernel I don't have problem connecting to public or
secured spots. But when booting this kernel I've got several segmentation
faults.

The iwlwifi site says that the driver still is in a development, I've tried
several snapshot in the past and is not as estable as ipw3945, ie lost
connection under heave use, can't connect after suspend, etc., so far this
issues are being solved, but IMHO is not ready for a production release.

If you want to load iwl3945 on boot you should blacklist ipw3945, ie create
a file blacklist-ipw3945 under /etc/modprobe.d, which contains the line

blacklist ipw3945

This will prevent the automatic load of this module and iwl3945 should be
loaded instead.

 PD: I was doing this from my memory so better take a look at ubuntu wiki
howto blacklist a module. If you want to undo this just remove the file
blacklist-ipw3945.

Well, after a big round of updates of pretty much the entire KDE tree, knetworkmanager is working fine for me with my WPA2 network and no longer hangs at 28%, killswitch trick no longer needed either AND the kwallet integration worked flawlessly too. Have reconnected three times now and it seems to be holding steady...

Running Gutsy with all update up to today and it works for me. It even reconnects after a resume from S2R. I'm using WPA2 with AES.

Btw: I'm also testing OpenSUSE 10.3 beta2 and they are using the iwl driver. From comments there it seems the ipw driver is crap ad the iwl driver is highly experimental, so I foresee a lot of trouble yet to come.

Still having the same timeout issue as of today with unencrypted networks, encrypted works fine.

On my Lenovo 3000 N100, my ipw3945 card will connect to wireless networks (unencrypted and encrypted) under Gutsy, but take 30 seconds to a minute to connect. This was almost instantaneous under Feisty.

there is an attempted fix for this available in bzr: https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac

Please test if replacing your current driver with this one helps.

to get a copy of the source just use:

 bzr branch https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac

to build it you need kernel-headers et al installed and run:

 make IEEE80211_IGNORE_DUPLICATE=y SHELL=/bin/bash

i have a similar problem in feisty: i gat a list of the aviable wireless networks in natwork-manager bun i connot connect. (it takes foreever and a day). using manual configuration and static ip connection is no problem. but then connection ist very very slow. Dell Inspiron 6400 wit Intel Pro Wireless 3945 Network card.

https://bugs.launchpad.net/ipw3945/+bug/103210

i will try gusty tribe-6 today.

Thanks Alex, built and tested your tree, and it now works (associates correctly) with Network manager on an open network.

I'll test with WPA Personal when I'm home. This had been working for me for some time now, so I'll only post again if it doesn't work.

Thanks so much

I have a Lenovo 3000 N100 with Intel 3945ABG wireless chip. I have experienced the same problem connecting to unsecured wireless networks reported by others already: network-manager connected fine under Feisty, but stopped working when I installed Gutsy. The work-around reported by others (toggling the kill switch) also worked for me.

I compiled and installed the ipw3945 driver from Alexander Sack, and have been testing it today on unsecured networks at work and home. So far, it is working fine on my system! Thanks for your work fixing this bug.

I compiled the new driver as well. Now I can connect to both secured and unsecured. Thank you very much.

Latest update to kernel 2.6.22-11 has fixed this bug for me.

confirmed: fixed

thanks

After installed todays daily-live build and then installed all updates from internet (including kernel 2.6.22-11), I was finally able to connect to my Wireless-G Router.
I dont know what fixed this bug, but at last it is working.

Not working for me :( Behaviour seems to be exactly the same - connection attempted, and then I'm prompted to re-enter the WPA key. Running 2.6.22-11-generic and all the latest updates. Syslog attached.

Working normal for me again! Thanks

We rolled an updated ipw3945 module which ships a patch that should normalize association behaviour.

To verify that you have the latest module installed, please do:

# modinfo ipw3945 | grep ^version

version: 1.2.2mp.ubuntu1 <-- this is the right version

Please test. Thanks,

 - Alexander

The new version fixed it for me!

The whole system seems to struggle if you change the security settings
(in my case from WPA to WPA2). I get a time out in the logs, but
retrying simply goes through the procedure all over again. I'm no
longer asked for a new protocol/password.

On 9/9/07, Alexander Sack <email address hidden> wrote:
> We rolled an updated ipw3945 module which ships a patch that should
> normalize association behaviour.
>
> To verify that you have the latest module installed, please do:
>
> # modinfo ipw3945 | grep ^version
>
> version: 1.2.2mp.ubuntu1 <-- this is the right version
>
> Please test. Thanks,
>
> - Alexander
>
> --
> [Gutsy]Network Manager Applet can't connect wireless with ipw3945 driver
> https://bugs.launchpad.net/bugs/121439
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Works for me, as well (on Gutsy).

Perhaps we could call this fixed?

I'm running:
lavid@lavid-laptop:~$ cat /proc/version
Linux version 2.6.22-11-generic (buildd@rothera) (gcc version 4.1.3 20070831 (prerelease) (Ubuntu 4.1.2-16ubuntu1)) #1 SMP Fri Sep 7 05:07:05 GMT 2007

and I've been getting the following messages in my kernel log:

[ 4967.888000] UDP: short packet: From 70.81.97.112:50 112/50 to 76.195.223.90:43069
[ 5330.760000] UDP: short packet: From 70.81.97.112:50 112/50 to 76.195.223.90:34629
[ 5630.880000] UDP: short packet: From 70.81.97.112:50 199/50 to 76.195.223.90:55296
[ 5930.844000] UDP: short packet: From 70.81.97.112:50 199/50 to 76.195.223.90:42856
[ 6230.888000] UDP: short packet: From 70.81.97.112:50 112/50 to 76.195.223.90:32950
[ 6530.928000] UDP: short packet: From 70.81.97.112:50 71/50 to 76.195.223.90:2713
[ 6624.752000] ipw3945: Microcode SW error detected. Restarting.
[ 6625.252000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[ 6627.240000] ipw3945: Can't stop Rx DMA.
[ 6627.620000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
[ 6831.432000] UDP: short packet: From 70.81.97.112:50 199/50 to 76.195.223.90:14226
[ 7131.820000] UDP: short packet: From 70.81.97.112:50 199/50 to 76.195.223.90:61946
[ 7431.040000] UDP: short packet: From 70.81.97.112:50 71/50 to 76.195.223.90:50341
[10063.268000] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
[10063.268000] ipw3945: Microcode SW error detected. Restarting.
[10064.260000] ipw3945: Can't stop Rx DMA.
[10065.632000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
[22114.568000] ipw3945: Microcode SW error detected. Restarting.
[22114.568000] ipw3945: Microcode HW error detected. Restarting.
[22115.564000] ipw3945: Can't stop Rx DMA.
[22116.936000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
[25036.604000] ipw3945: Microcode SW error detected. Restarting.
[25037.104000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[25038.096000] ipw3945: Can't stop Rx DMA.
[25039.468000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
[28981.528000] UDP: short packet: From 74.212.42.2:8024 48290/71 to 76.195.223.90:22445
[34406.556000] ipw3945: Microcode SW error detected. Restarting.
[34407.056000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[34408.048000] ipw3945: Can't stop Rx DMA.
[34409.420000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
[37332.512000] ipw3945: Microcode SW error detected. Restarting.
[37332.512000] ipw3945: Microcode HW error detected. Restarting.
[37333.508000] ipw3945: Can't stop Rx DMA.
[37334.876000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
[69421.300000] ipw3945: Microcode SW error detected. Restarting.
[69421.800000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[69422.792000] ipw3945: Can't stop Rx DMA.
[69424.168000] ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)

I can, however, connect to my WPA network without many issues.

I have encountered this same bug on my home PC with a Edimax USB (Ralink, rt73 driver).

I am able to connect with WPA from the CLI.

NetworkManager spins for upto 28% and then gives up. So I guess it is not ipw3945 specific.

Regards
Anand Vaidya

Working fine for me today, since ipw3945 1.2.2mp.ubuntu1

this bug was fixed in ipw3945 driver (version 1.2.2mp.ubuntu1). Thanks for your feedback. If you have other issues, please look if there are other bugs already tracking those, otherwise open a new bug.

alrite nothing is fixed to me.

I got a clean install of gutsy.
and i punched in modinfo ipw3945 | grep ^version
and it shows
1.2.2mp

However,

after succesful connection about a few minutes the connection gets lost.
when i do left click on NM and do manual configuration it shows two WIRED Network?!
after a while my terminal doesnt react to my commands and then the whole system hangs

well

for now I pulled out my old DLINK G 630 laptop card and use that and have no problem at all.

I never had this problem with feisty as far as I remember.

Any help

I have ipw3945 and am still having the same problem. network-manager correctly associates with the AP but does NOT handle the dhclient correctly.

drink@agamemnon:~$ modinfo ipw3945 | grep ^version
version: 1.2.2mp.ubuntu1

If I manually run sudo dhclient eth1 after associating to the AP with network-manager then everything works (this is how I'm updating this bug report now.)

I get errors in various log files. For example, in my /var/log/debug:
Feb 20 03:51:19 agamemnon NetworkManager: <debug> [1203508279.473716] nm_device_
802_11_wireless_get_activation_ap(): Forcing AP 'Wireless'
Feb 20 03:51:38 agamemnon kernel: [ 233.432000] eth1: no IPv6 routers present

compressed daemon.log attached.

If this is a different bug let me know, but I am definitely having this problem with the versions which allegedly solve the problem.