NetworkManager causes system freeze, lock up, kernel panic
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
network-manager (Ubuntu) |
Expired
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: network-manager
This is a critical bug, either caused specifically by or precipitated by NetworkManager. There is a very large thread of users that seem to be experiencing this bug at http://
I have been experiencing this bug since Ubuntu Intrepid 8.10. I am running 8.10 on a Compal HEL 80 with an Intel Pro Wireless 3945ABG card. I connect to a Virginia Tech campus network, which uses WPA-EAP with TLS, and requires an 802.1x user certificate, CA certificate, and user key to authenticate. (Our LUUG has documented the actual steps for connecting to this network in Ubuntu 8.10 at the following URI: http://
I raise the possibility that these lock ups occur when NetworkManager decides to "hop" from one WAP of an ESSID to another WAP of the same ESSID (but different Address), as I've noticed somewhat frequent disconnections and reconnections in NetworkManager via nm-applet, and also that NetworkManager chooses somewhat poorly in which WAP of the same ESSID to connect to (there may be another WAP of a different address with a much stronger signal, yet NetworkManager chooses a WAP with a poorer signal).
I do not experience these system freezes when I kill NetworkManager and connect to the campus network via wpa_supplicant. I reported this in the above mentioned thread at http://
I also do not experience these system freezes when connecting to my home WAP, either via NetworkManager or wpa_supplicant. The home WAP is WPA-PSK. Only a password is required to connect to that WAP, and it is the only WAP of its ESSID in the area.
I have attached the output of lspci.
I hope the Ubuntu team will take a look at this issue. I performed an install of 9.04 Jaunty Alpha 5 on a new MacBook 5.1 and experienced immediate lockup upon connection to the VT-Wireless network via NetworkManager's nm-applet, so it is likely this critical bug is still present in the packages shipping with Jaunty.
Suggestions for reproducing the bug:
* Run tests of NetworkManager within a room that has multiple WAPs of the same ESSID
* Set up connections to these WAPs to use 802.1x certificates
* Connect using NetworkManager and wait until freeze--this often times will not even require explicit network communication by the user (e.g., browsing the web via Firefox, running a Bittorrent), lockups tend to be spurious in timing from my experience
* Maybe having multiple clients connected to the WAPs will also prove a key part--again, freezes reported tend to happen on college campuses or in workplaces
Suggestions for users who suspect they are experiencing this bug:
* Report here, with your network card and information about the type of network you were connecting to (e.g., WPA-EAP over TLS with 802.1x certificats)
* Please attempt to connect to your wireless network through a different client instead of NetworkManager. I provided a script to help you at http://
I hope that this will help the NetworkManager developers investigate this bug, and hopefully squash it.
Best,
Chris Lasher
Changed in network-manager (Ubuntu): | |
status: | Expired → Incomplete |
I am also experiencing this same issue. My home network is WPA encrypted with only a password required to connect and I connect daily through NM without any issue. However, at work we have an open "guest" access point. The kernel will panic EVERY single time I connect to this network, guaranteed. I connected manually via the terminal and did not experience the lockup.
My hardware is a Dell Inspiron E1505 and an Intel Pro Wireless 3945abg card. One thing I have seen in dmesg before the lockup is the card will associate, then disassociate repeatedly.