[ipw3945] wpasupplicant gusty takes a long time to associate

This is my first time using launchpad, and I think I may have filed this bug in the wrong place. I'm thinking it should be against gusty specifically... but I can't figure out how to move it.

Background: I have a new X60s with a ipw3945 wifi card, same as you. I've had problems with network-manager like you describe, but I rather thought that would be a problem with network manager. I was curious to try your suggestion and downgrade to feisty's wpasupplicant package (version 0.5.7-0ubuntu2). I didn't have more luck with that at first with my network.

However, after disabling auto-detection and manually setting the prferences to WPA2 and TKIP, I managed to get a connection with version 0.5.7-0ubuntu2. In order to confirm that the problem is also on 0.6.0-1, I upgraded again. However, I wasn't able to reproduce it. I therefore have to assume that this bug is not a regression.

Does wpasupplicant 0.6.0-1 work with your network if you use it manually, like in /etc/network/interfaces?

Good catch. I traveled a little this weekend and had trouble with multiple networks from ranging from completely open to wpa even on old wpasupplicant, especially after coming back from hibernation. While I can't test on any of those networks, I'll try and nail down what's happening at home better.

I thinking it might actually be caused by the ipw3945 driver or the actual hardware underneath since it affected so many networks this weekend, but that's just speculation at this point.

Just FYI, I'm actually on an E1505N, not a X60.

it is most certainly caused by the special behavior of th eipw3945 driver. However, network-manager and/or wpasupplicant should be flexible and robust enough to cope with them. This is however something only upstream is capable to do, if at all.

As said, please try to directly state your networking parameters. I also noticed that I sometimes have to retry my password 2 times in a row(!) in order to get connected to my home wifi. Please try that as well

When KNetworkManager is trying to connect, I see the wpa_supplicant command-line from in the "ps auwx" display, but entering my password and/or manually choosing my network parameters doesn't work. I'm simply asked for my password over and over. Connecting to unencrypted or WEP networks is still a little flaky when coming back from suspension or hibernation, but after a fresh reboot they are fine.

To get a little more information I tried stopping KNetworkManager entirely, and then starting the wpa_supplicant using the command-line gleaned from "ps auwx". It starts up, gives no troublesome diagnostics, and remains attached to the terminal. Then, in a second terminal, I try using wpa_cli, but something is wrong, or I can't figure out the command-line parameters to use, because everything I've tried just results in a "cannot connect to wpa_supplicant" error from wpa_cli.

Hi,

apparently we found a workaround for one variant of this bug:

  "unset essid manually using iwconfig before connecting."

Can you try if this helps for you as well?

Thanks,

 - Alexander

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

We worked around this by unsetting essid right before trying to connect:

  network-manager (0.6.5-0ubuntu9) gutsy; urgency=low

  * debian/patches/series: disable 41o_completely_deactivate_stage1.patch
    for tribe-4

 -- Alexander Sack <email address hidden> Tue, 7 Aug 2007 12:36:37 +0200

#

  network-manager (0.6.5-0ubuntu8) gutsy; urgency=low

  * debian/patches/41n_graceful_supplicant_shutdown.patch: move
    supplicant_cleanup into stage1_prepare; remove test timeouts in
    _stage2_config and add 1 second sleep to the end of xx_stage1_prepare
  * debian/patches/series: add new patch 41n_graceful_supplicant_shutdown.patch
    to series
  * debian/patches/41l_enable_ipw3945_reset_essid.patch: enable
    ipw3945_reset_essid, by setting up function in class constructor
  * update debian/patches/41l_enable_ipw3945_reset_essid.patch:
    completely deactivate device in stage1 now
  * debian/patches/series: add new patch 41l_enable_ipw3945_reset_essid.patch
  * debian/patches/41m_unref_dbus_connection_on_shutdown.patch,
    unref shared dbus_connection on shutdown (LP: #85113)
  * debian/patches/series: add new patch 41m_unref_dbus_connection_on_shutdown.patch
  * debian/patches/41k_20_sec_wireless_link_timeout.patch: increase
    timeout for link setup ... taken from upstream ml
  * debian/patches/series: add new patch 41k_20_sec_wireless_link_timeout.patch
  * debian/patches/41e_fix_vpn_ftbfs_dont_disable_gnome_deprecated.patch: Fix
    ftbfs because of recently deprecated gnome druid - this patch enables gnome
    deprecated in Makefiles
  * debian/patches/series: add new patch
    41e_fix_vpn_ftbfs_dont_disable_gnome_deprecated.patch
  * debian/patches/41d_ipw3945_turn_off_essid_in_stage1.patch:
    implement stage1_prepare implementation in nm-device-802-11-wireless.c
  * debian/patches/series: add new patch 41d_ipw3945_turn_off_essid_in_stage1.patch
  * debian/rules, debian/control, debian/patches/series: Switch patchsystem to quilt
  * debian/patches/41c_ubuntu-fixup--get_mode_always_fails_typo_fix.patch: fix
    programming bug in wireless code
  * debian/patches/24pp_svn2591_Ensure-the-device-is-up-stage3.patch: ensure
    device is up in stage3 - cherry-picked from svn
  * debian/patches/24pp_svn2618_set-hardware-RF-to-enabled-if-no-killswitches.patch:
    enable hardware rf by default - cherry-picked from svn
  * debian/patches/24pp_svn2604_Add-HAL-based-rfkill-support.patch: hal based rfkill
    - cherry-picked from svn
  * debian/patches/24pp_svn2579-sleep-1-second-to-stabilize-if.patch: sleep to
    stabilize link status - cherry-picked from svn
  * debian/patches/41o_completely_deactivate_stage1.patch: use nm_device_deactivate
    instead of just real_deactivate to deactivate device more cleanly

 -- Alexander Sack <email address hidden> Tue, 7 Aug 2007 09:51:02 +0200

with unsetting essid before trying to connect it works pretty fast. I guess its the driver so i reject the wpasupplicant task

Tribe 5 seems to have fixed the issue. Now, the wireless either completely works or completely doesn't. When it does not work, it is simply a problem with the ipw3945 daemon not being started. This only occurs when I boot into a -386 kernel image, as I don't have a -386 ipw3945 daemon. The -generic daemon has worked for me on a -386 kernel image. Currently I've switched to just using the -generic kernel image as a work around.

Fixed via network-manager.