On Thu, 2015-03-12 at 10:39 -0400, Stuart Gathman wrote: > On 03/12/2015 10:31 AM, Dan Williams wrote: > > On Wed, 2015-03-11 at 20:49 -0400, Stuart D. Gathman wrote: > >> On Wed, 11 Mar 2015, Dan Williams wrote: > >> > >>> What's the reason to reset NM when it reports something isn't connected? > >>> Just to ensure always-on connectivity as hard as possible? Also, what > >>> do you mean by "reset", what specific actions are you running to do so? > >> In my case, wpa_supplicant hangs every so many megabytes, and I have to > >> killall wpa_supplicant to restore the network connection. I've been > >> wondering about a way to have NM do that automatically, since fixing > >> wpa_supplicant seems to be difficult. > > You can just "kill -9 wpa_supplicant" from a script somewhere and NM > > will restart the supplicant automatically via D-Bus activation. Does > > the hanging supplicant also block D-Bus communication? Can you gdb the > > supplicant and find out what function it's hung in? Or is it not > > actually hanging, but just not doing some requested operation? > > > > But obviously, fixing wpa_supplicant would be preferable... > This has some stacktraces. The problem persists on several different > laptops, with different Wifi chipsets. > > https://bugzilla.redhat.com/show_bug.cgi?id=1119524
Ok, we'll need debug logs then, since the stack traces show that the supplicant isn't really hung, it's just that the key change apparently didn't happen correctly... you can do this by: mv /usr/sbin/wpa_supplicant / killall -TERM wpa_supplicant /wpa_supplicant -dddtu (pipe to your favorite logfile) and then go until it "hangs". Then send me the logfile since it might contain private information. Move the supplicant back to /usr/sbin/ when you're done to get back to normal. Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
