Invocations of nmcli with at least this version of networkmanager (haven't checked previous versions) result in a complaint involving ss (actual shown below). Reproducible: Always Steps to Reproduce: 1. emerge -1 =net-misc/networkmanager-0.9.10.1_pre20141101 2. nmcli n Actual Results: The following error repeated several times: (process:1870): libnm-glib-WARNING **: Error in get_property: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist Expected Results: A correct description of the current networking status from nmcli. I've verified that ss is not installed on my system and I hypothesize that this is the cause of the problem.
Not sure I agree that networkmanager is missing a dependence on iproute2. On my system exhibiting this behavior I do in fact have sys-apps/iproute2-3.17.0 installed. Perhaps it's important that nmcli does not run as my non-root user with the aforementioned error. What's also interesting is that when run as the root user I get the same error even though ss is in the root user's path. Perhaps this is due to the path of the ss utility not conforming with convention? Why don't we place ss in /usr/bin rather than /usr/sbin? Does this last question warrant another update to the bug title to ensure accuracy?
But, then, the error is the same even if "ss" is present and in /usr/bin and /usr/sbin? (you can temporally drop there a symlink to test) and executable by the user trying to use it?
Hey Pacho, Yes, dropping a symlink does not change the issue. I'm beginning to think my hypotheses were all naïve in this case. With /bin/ss linked to /sbin/ss the errors are the same as non-root and root.
It works ok in my case: $ whereis ss ss: /sbin/ss /usr/include/ss /usr/share/ss /usr/share/man/man8/ss.8.bz2 $ nmcli n activado Maybe it's related with some problem with dbus activation or similar. Are you running it from a console or X? Do you run systemd or openrc?
Per https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/636776 looks like it could be caused by some conflict with connman (I guess indicator-network is not available on Gentoo :/)
I'm running it inside of konsole using X. I use systemd as my RC system. A misconfigured or setup dbus would be a reasonable hypothesis. I assume your working system is openrc?
I hate to be that guy, but I have the same error here.
(In reply to Alex Brandt from comment #6) > I'm running it inside of konsole using X. I use systemd as my RC system. A > misconfigured or setup dbus would be a reasonable hypothesis. I assume your > working system is openrc? No, I have systemd too :) (In reply to Aaron W. Swenson from comment #7) > I hate to be that guy, but I have the same error here. That is not a problem at all ;) Looking at: https://bugzilla.gnome.org/show_bug.cgi?id=690457 https://bugzilla.gnome.org/show_bug.cgi?id=739255 I think that maybe it's a problem with some obsolete configuration in your /etc/NetworkManager directory, maybe you check files you could have there... or even move it to /etc/NetworkManager.old and reconfigure networks and, if it works, starting copying back the old configs until you find the offending one
Looks like that was it. Sorry for the delay in checking. Thanks for the help investigating this. I'm not sure what the appropriate resolution would be for this one but I can give it a worksforme.
(In reply to Alex Brandt from comment #9) Were you able to find the concrete offending line? The same as https://bugzilla.gnome.org/show_bug.cgi?id=690457#c9 ?
Not yet, my config is so simple that I just recreated what was needed. I'll reconfigure the other network tonight and check the diff.
No, the whole format changed between my original setup and my new setup. New section names and properties both. In fact the generated configuration had the parameter that was mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=690457#c9 and it worked as expected. Not sure how this resolves this bug but you've helped me solve the issue I was having.
Was that warning preventing you from using nmcli completely? If that is the case we can add a check to the ebuild for ensuring people look at that file, if it was only a warning, I guess we don't need to do that
(In reply to Pacho Ramos from comment #13) > Was that warning preventing you from using nmcli completely? If that is the > case we can add a check to the ebuild for ensuring people look at that file, > if it was only a warning, I guess we don't need to do that Yes, at least if the proper output was in the long list of warnings it was drowned out and unnoticeable. A check would be excellent. Thanks again for the help.
What was the file containing the bogus psk-flags=1? Some file inside /etc/NetworkManager/?
It was any file that contained a wireless network configuration.
+ 15 Dec 2014; Pacho Ramos <pacho@gentoo.org> + networkmanager-0.9.10.1_pre20141101.ebuild: + NM shows lots of errors making nmcli neither unusable, bug #528748 (by Alex + Brandt), upstream bug #690457, add a warning then. +
I recently got the warning * You have psk-flags=1 setting in above files, you will need to * either reconfigure affected networks or, at least, set the flag * value to '0'. Because there were no ‘above files’ mentioned, I was confused. Somebody in the forums (https://forums.gentoo.org/viewtopic.php?p=7814414) told me it was a file in /etc/NetworkManager/system-connections/. Perhaps it would be good to mention this explicitly in the warning, and also that the setting psk-flags=1 is deprecated. (Or is it? How can I get equivalent functionality?) As to how it got in my configs: I think these are generated by kde-misc/plasma-nm or net-libs/libnm-qt. So it may be a good idea to alert the Gentoo and upstream KDE people about this issue.
(In reply to Erik Quaeghebeur from comment #18) > [...], and also that the setting > psk-flags=1 is deprecated. (Or is it? How can I get equivalent > functionality?) I now have convinced myself that psk-flags=1 is not deprecated. See https://developer.gnome.org/libnm/stable/NMSetting.html#NM-SETTING-SECRET-FLAG-AGENT-OWNED:CAPS The ebuild warning as currently formulated is misleading: it should be made explicit that this only applies to people using nm-cli. (And then it should be verified that it is still valid for current versions of NetworkManager.)
