Re: Maintaining connection
- From: Dan Williams <dcbw redhat com>
- To: Stuart Gathman <stuart gathman org>
- Cc: networkmanager-list gnome org
- Subject: Re: Maintaining connection
- Date: Thu, 12 Mar 2015 11:40:51 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]