Re: NM Success and Failure

[Dan Williams <dcbw redhat com>]

On Mon, 2006-10-09 at 15:43 -0700, Joshua L. Phillips wrote:
> I have been experimenting with NetworkManager and wpa_supplicant for the 
> last month. I am writing this little note to share some of my 
> experiences with this software and also to see if others have 
> encountered the same issues that I have (from the looks of other Linux 
> mailing-lists I have had many of the same problems as others.)
> 
> First, this is an excellent piece of software. I say that because we 
> have been needing something like this for mobile linux. It's the simple 
> wireless network switching and browsing that I like the most. And I also 
> like the fact that it tries to connect to a wired connection as soon as 
> it is plugged in. It seems to make sense. Most of the time, it works 
> just fine.
> 
> It works well with the orinoco_cs drivers (I am working on a i686-FC5 
> (fully updated) box and have used Network Manager with two PCMCIA 
> wireless cards. These are a Netgear MA401RA and a Microsoft MN-520. Both 
> can be used with the orinoco_cs driver.) I had to blacklist the hostap 
> drivers like many others who use these cards, but that was just a couple 
> of lines in /etc/modprobe.d/blacklist This setup worked well.
> 
> However, the wireless network at the University that I attend uses WPA2 
> Enterprise authentication and encryption. I also wanted to use the 
> WPA-PSK option on my home router instead of WEP. Thus, the orinoco_cs 
> drivers were no longer able to fulfill my needs since they only support 
> WEP. I promptly unblacklisted hostap_cs, upgraded the firmware on both 
> cards and blacklisted the orinoco modules so that my stock kernel would 
> no longer load them. I am able to successfully authenticate with my home 
> router using WPA-PSK and the University's wireless network using 
> PEAP/MSCHAPV2. Excellent, but there are still a few issues...
> 
> With this setup, once I have authenticated with a particular network, it 
> is perilous to switch either to the wire or to another wireless network. 
> My system will sometimes (usually) lock-up when I try either of these 
> two options after connecting to a wireless network. (Sometimes it will 
> happen without any noticable change whatsoever which is very 
> frustrating.) There were no problems with orinoco_cs and actually I 
> don't think the problem is with hostap_cs. It seems to be with 
> wpa_supplicant... sort of. I can duplicate the same lock-up by running 
> wpa_supplicant independently and then killing the process using killall. 
> If I do this, sometimes the machine locks. I don't know the exact 

Right, that certainly sounds like a hostap driver problem, and if you
can't get backtraces, perphaps you could try the SysRq stuff when the bo
locks and try to get a panic over serial cable or something.  Could you
take this bit over to the hostap lists at shmoo.com?  That's a better
place for driver issues, especially if you can reliably reproduce the
issue with plain wpa_supplicant runs.

> circumstances yet, but I will continue to search. However, I can 
> alleviate this issue by doing something a little nicer to wpa_supplicant:
> 
> wpa_cli -iwlan0 disconnect
> wpa_cli -iwlan0 terminate
> 
> The machine has NEVER locked when I use this method. I think that this 
> may be the better way to shutdown the process unless it simply will not 
> respond at all. This might never be an issue on some setups, but it has 
> been a headache for me. Since it happens with both cards, I suspect that 
> wpa_supplicant leaves the hostap driver in an unfortunate state which 
> then locks my machine. For now, I have switched to using wpa_supplicant 
> and connecting it to my ifup-wireless script and then to ifdown 
> performing the suggested commands.
> 
> Does anyone know how and when NM stops wpa_supplicant? Maybe this will 
> solve this problem that I and others are having?

NM doesn't necessarily terminate wpa_supplicant in the nicest manner,
and we can likely do better here.  I'll have to investigate what these
two commands do internally in the control interface, but it's quite
possible to ensure that NM terminates wpa_supplicant in a better manner
(and falls back to kill -9 or something if the supplicant fails to
respond in an allotted time).  Can you file a bug at gnome.org against
NM with this information?

Thanks!
dan

> ref: http://www.ubuntuforums.org/showthread.php?t=180160
> 
> If NM keeps the same wpa_supplicant process running when switching 
> networks, does it issue a disconnect command before loading the new 
> configuration? Or does it simply kill and start a new process (which 
> could explain my freeze-up problems?)
> 
> Even if I do not switch wireless networks, when I shut-down the system, 
> it cannot complete the shutdown process. It locks up when trying to stop 
> named. I know that named is connected to NM vi DBUS, but what if these 
> connections aren't being closed properly and this is the another reason 
> that my system might occasionally be hanging. I don't know how to test 
> this independently and my logs are completely silent no matter which 
> situation I am trying to analyze.
> 
> JLP
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list