Wireless (WPA) connection results in system lock-up

I've the same problem. Suddenly ubuntu freezes, (sometimes without do anything) at the startup.
I think wifi could be the problem because one day in a friend's home the mini continuosly freezes at the startup (about three times) the fourth time I decided to put off the wifi and the mini worked perfectly.

I am having a slightly different problem in that when I use WPA on my Linksys WAP55AG access point, there are some sites that I can not browse to. Ping times are all fine with no packet loss, but any connections to the sites in question fail, e.g.:

$ wget www.google.com
--11:58:47-- http://www.google.com/
=> `index.html'
Resolving www.google.com... 72.14.207.99, 72.14.207.104
Connecting to www.google.com|72.14.207.99|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.ca/ [following]
--11:58:47-- http://www.google.ca/
=> `index.html'
Resolving www.google.ca... 72.14.207.104, 72.14.207.99
Reusing existing connection to www.google.com:80.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

[ <=>
] 5,808 --.--K/s

11:58:48 (789.64 KB/s) - `index.html' saved [5808]

$ rm index.html
$ wget http://dell-mini.archive.canonical.com/ ... -dell-mini
--11:58:53-- http://dell-mini.archive.canonical.com/ ... -dell-mini
=> `hardy-dell-mini'
Resolving dell-mini.archive.canonical.com... 91.189.90.29
Connecting to dell-mini.archive.canonical.com|91.189.90.29|:80...

Switching back to unsecured wireless resolves the issue, but that is not really an option due to security considerations. I am using WPA1 + PSK/TKIP.

Additional info from aaamr over at mydellmini.com [1]:

"I solved my issue... when I switched the security settings from TKIP to AES on my Linksys access point, the issue resolved."

[1] http://www.mydellmini.com/forum/wireless-issues-p8275.html#p8275

I'll also try changing my router from WPA (TKIP) to WPA (AES) and see if that makes any difference.

After changing the router from WPA (TKIP) to WPA (AES) I have not had any system lock-ups while the Mini tries to setup the wireless network connection.

Will continue to keep an eye on this ...

Changing the status of this bug to "Invalid" and converting the bug to a question is incorrect.

This is still a bug and still valid:

Changing the router encryption from WPA(TKIP) to WPA(AES) is a workaround, not a fix for this bug.

The wireless driver for the Mini 9 needs to be able to support both of the above encryptions methods, just like it needs to support the older, much less used WEP.

For example, if a user has another laptop or wireless device that does not support the newer WPA(AES), they will need to set their router to WPA(TKIP), but this will result in occasional lock-ups for the Mini 9.

See comments above.

Incorrectly converted to a question.

What wifi driver do you use?

please post at least:
lspci -vvn > lspci_vvn.txt
dmsg > dmsg.txt

Also gie details on the version of Ubuntu you are using, and so on.
Thanks,

I've had this bug happen to me a number of times. A couple times it happened while I was on my home network (WPA2 AES) and a couple at my girlfriends house (WEP128). Using the stock drivers that came with my Mini 9. It just happened again as I was going to check the driver I was using (wl, as it turns out).

Using Ubuntu 8.04, fully updated. Using magic SysReq key pattern REISUB seems to reboot the machine with no ill effects.

I think I can now confirm that this bug does not happen on WPA-Enterprise systems. I spent all day connected to a WPA-Enterprise network at my local university with no lockups. Again, using the stock wl driver.

As previously requested here are the outputs from my lspci -vvn. (dmesg follows)

dmesg printout.

lspci output. Note this is after the 170+ updates released on Jan. 9, 2009.

dmesg output. Note this is after the 170+ updates released on Jan. 9, 2009.

I can add to this that it has happened to me once when connected to an unprotected network. It has, however, never happened if I kept my wireless and bluetooth off. I will try and keep my bluetooth off and wireless on and see what happens.

There is more info on this issue in this (possible) dupe: https://bugs.launchpad.net/dell-mini/+bug/300784

I'm not certain that this is actually caused by the wireless. Whenever I have bluetooth turned off but wireless on I don't get this issue. I re-installed 8.04 (non-dell) and forgot to turn off bluetooth. Sure enough I got the lockup again. Now that I have turned bluetooth back off I haven't had any issues.

There's no way to be certain either way, but I think these may be linked somehow. And, as previously stated, this is not specific to WPA2. I can say I have never had this happen with WPA-EAP and never when bluetooth is off. Anything else is basically conjecture.

I can confirm that this is a problem on a Mini 9 without Bluetooth installed (with frequency as per the initial description).

In terms of timing, the lock-up happens right after the blue connection bars appear in the network manager applet in the panel (i.e. as soon as the wireless appears to establish a connection with the router).

My Dell Mini 12 locks up about 40% of the time just before I get the wireless blue bars. The spinner stops and the system seems to be hung. I am using the wl driver configured for WPA1 Personal (TKIP). I was unable to get it to connect to my AP with AES so the work around does not work for me. I have bluetooth disabled in bois.

Here are the last few lines of syslog when it hangs:

Jan 25 10:24:26 brandon NetworkManager: <info> Now managing wireless (802.11) device 'eth1'.
Jan 25 10:24:26 brandon NetworkManager: <info> Deactivating device eth1.
Jan 25 10:24:26 brandon NetworkManager: <WARN> nm_device_802_11_wireless_set_wep_enc_key(): error setting key for device eth1: Invalid argument

Here is what I get when it comes up fully:

Jan 25 10:26:06 brandon NetworkManager: <info> Now managing wireless (802.11) device 'eth1'.
Jan 25 10:26:06 brandon NetworkManager: <info> Deactivating device eth1.
Jan 25 10:26:06 brandon NetworkManager: <WARN> nm_device_802_11_wireless_set_wep_enc_key(): error setting key for device eth1: Invalid argument
Jan 25 10:26:17 brandon NetworkManager: <info> SWITCH: no current connection, found better connection 'eth1'.
Jan 25 10:26:17 brandon dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason
Jan 25 10:26:17 brandon NetworkManager: <info> Will activate connection 'eth1/prvwls'.
Jan 25 10:26:17 brandon NetworkManager: <info> Device eth1 activation scheduled...
[continues]

Actually, that's pretty helpful. It seems that the network manager is having trouble figuring out / remembering that wireless is eth1 (it probably checks wlan0 first). I'm not one of the ubuntu or nm programmers but that's what it looks like to me. Perhaps the NM people would be of more help in this case, but it looks to me like when it hangs it's trying to figure out what interface to use. Perhaps it hits an endless loop of some sort? I'll have a look at some of the NM stuff and see if I can figure anything else out.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just saw that this bug was confirmed, though the duplicate seems to be
more apt for me (https://bugs.launchpad.net/dell-mini/+bug/300784)

I work in IT at a university with WPA2 Enterprise set up for wireless.
I am now using wpasupplicant to get around my particular issue, but it
is still flacky. I would love to use the native linux broadcom drivers.

I can easily get in contact with the admins of our wireless setup as
well as get whatever information you would like to assist in
troubleshooting this issue. Please tell me what you would need and I
will be happy to provide.

Robert

Chris Gregan wrote:
> ** Changed in: dell-mini
> Assignee: (unassigned) => Pat McGowan (pat-mcgowan)
> Status: New => Confirmed
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmDHQkACgkQup357T5MfTYt6wCgrMUHeBumyCKrk7xX/7Hs7kuK
CXEAn332eHvKw5pkLfF7KRjxzN+ss6Rx
=3xFk
-----END PGP SIGNATURE-----

Brand new DELL Mini; ships with up-to-date 8.04 (no updates available from GUI or command line).

Wireless works, except when connecting to my WAP (i.e., I can borrow from my neighbours but not use my own).

My WAP: WRT54GL running White Russian 0.9, WPA (PSK), WPA2, AES. Not using TKIP, not using WEP, not using WPA1.

Tried the "disable power management" workaround from ubuntumini.com - no effect.

Tried Feisty_No-fluff steps 1, 2e, 3 - no effect. (What's really weird is that wl still shows up in the device manager gui - I suppose this could be the module loading bug, but the fixes to that don't seem to work either. Also really weird that lshw -C network lists ndiswrapper+bcmwl5, etc., as the driver, but GUI still shows wl.)

Tried the disable bluetooth workaround - interesting effect! With bluetooth running, attempt to connect to my WAP and system locks showing the GUI - just looks frozen; with bluetooth disabled in BIOS, GUI borks - ctrl-fn-alt-f1 to another vt and screen is filled with jagged lines. Don't know what value this data point is, but the nature of the failure is different.

Will be more than pleased to attach whatever diagnostic information may be of value.

I would just like to say that I received my new Dell Mini 12 on Thursday (April 9th, 2009) and have the same problem. About 1 in 3 times when I try to connect it locks solid.

I'm using a D-Link DAP-1160 with the encryption set to WPA(TKIP)

An update was posted April 14th that included an updated wl driver. This was reported to fix bug #300784. Please get the update and update the bug with your results.

This bug is a duplicate of either bug# 300784 or bug# 292450, both of which are fixed with the latest wl driver, which has now (finally) hit the DELL MINI repos as well.

All DELL Mini users running the default OS (Ubuntu 8.04) should be able to get this by selecting System from the menu bar, then administration, then update manager, then clicking Check, and finally clicking install updates.

I'm marking this fix released based on my DELL MINI and on the afore-quoted bug reports.