Okay, I'm pretty sure I know what the problem is here, and I'm (mostly) to blame.
I'm going to seem like I'm rambling, and maybe I am a bit, but bear with me.
If you've ever suspended your laptop and gone somewhere else with a different AP to which your laptop also autoconnects, you have likely noticed that it often takes a while for NM to "notice" that your home AP is no longer present, and thus it will attempt to reconnect to it before doing another scan, noticing the new one, and connecting to it instead.
The solution to that problem is to put NM to "sleep" on suspend and "wake" it up on resume. The way to do that is this:
Code:
# On suspend:
dbus_send --system \
--dest=org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.NetworkManager.sleep
# On resume:
dbus_send --system \
--dest=org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.NetworkManager.wake
In the old days when pm-utils ruled the world of power management, that was done by a sleep hook at /usr/lib(64)/pm-utils/sleep.d/55NetworkManager, so it "just works" as expected.
At some point, upower entered the picture, and it allegedly handled this part of the suspend/resume cycle, although I find no evidence to suggest that in the upower-0.9.23 code -- perhaps it is present in 0.99.x, but I find no evidence there either. I'm certainly not an expert in that realm, but I know this: I understood from talking with upstream that upower handled this, and thus the conclusion was that we no longer needed the pm-utils sleep hook, so it was removed from the NM package (well, still shipped in docs until recently, but obviously nonfunctional there). I want to stress that I am NOT accusing NM devs of giving me incorrect information either intentionally or unintentionally - I'm pretty much certain that the confusion/misunderstanding was *entirely* mine.
The result is that I've been trying to track down this annoying bug of "my laptop keeps seeing my home AP when I get to work, so I have to manually rescan for APs or send NM a HUP" for quite some time.
Xfce4-power-manager added support to call the NM sleep/wake quite some time ago in response to some/most distributions using uppwer and NOT pm-utils for suspend/resume - see, upower deprecated the suspend/hibernate functionality in favor of using systemd, and you only get it without systemd if you compile upower with --enable-deprecated (which we do).
Code:
#ifdef ENABLE_DEPRECATED
#define UP_BACKEND_SUSPEND_COMMAND "/usr/sbin/pm-suspend"
#define UP_BACKEND_HIBERNATE_COMMAND "/usr/sbin/pm-hibernate"
#define UP_BACKEND_POWERSAVE_TRUE_COMMAND "/usr/sbin/pm-powersave true"
#define UP_BACKEND_POWERSAVE_FALSE_COMMAND "/usr/sbin/pm-powersave false"
#endif
Since some distributions were not doing that, xfpm decided to call out to pm-utils directly to do the suspend/hibernate operations, which should have poked the NM Sleep/Wake without any special work, but for whatever reason, xfpm's dev decided to implement that within xfpm too (using --enable-network-manager). The problem is that NM's dbus config looks like this:
Code:
...
<!-- Root-only functions -->
<deny send_interface="org.freedesktop.NetworkManager" send_member="SetLogging"/>
<deny send_interface="org.freedesktop.NetworkManager" send_member="Sleep"/>
...
As result, those dbus calls as a normal user (which is how xfpm is run - as your user account) fail, which is what you (and I) see in the logs are rejected dbus messages.
Long story short, the proper solution seems to be two things:
1. Restore the 55NetworkManager script to /usr/lib(64)/pm-utils/sleep.d/ with 0755 permissions
2. Recompile xfce4-power-manager with --disable-network-manager
After doing that here, both the error messages *and* my longstanding bug are gone :-)
