RE: networkmanager permissions problem
> > I've previously compiled modemmanager and networkmanager from source > > on x86_64 (non-systemd) and they work fine. > > > > Using basically the same method on an RPi3 (non-systemd) - I get > > permissions problems. > > > > I've compiled both (ModemManager-1.6.12, NetworkManager-1.4.6) with > > and without polkit, but both give a permissions error on starting nm- > > dispatcher. > > > > I've tried starting nm-dispatcher and polkitd directly as root (the > > dbus and networkmanager daemons are running as root) and neither give > > errors. > > It's not polkit that's the problem here. It's D-Bus service activation that's > not able > to launch nm-dispatcher or wpa_supplicant or polkit. > Perhaps that's because of something like selinux or apparmor preventing the > main dbus-daemon process from running them, or perhaps permissions aren't > set on them correctly, or perhaps the paths in the service activation files in > /etc/dbus-1/system.d/ aren't correct. > > Activation is a feature of dbus that actually runs the given program the first > time a request is made to that program's D-Bus interface. On systemd systems, > that's handled by systemd. On non-systemd systems, D- Bus has a helper that > the main dbus-daemon execs which then runs the given service binary. > Aaargh The permissions on dbus-daemon-launch-helper were incorrect. Things work fine now - sorry for the noise. John ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
networkmanager permissions problem
I've previously compiled modemmanager and networkmanager from source on x86_64 (non-systemd) and they work fine. Using basically the same method on an RPi3 (non-systemd) - I get permissions problems. I've compiled both (ModemManager-1.6.12, NetworkManager-1.4.6) with and without polkit, but both give a permissions error on starting nm-dispatcher. I've tried starting nm-dispatcher and polkitd directly as root (the dbus and networkmanager daemons are running as root) and neither give errors. Note also that eth0 is already running using udhcpc before starting networkmanager to enable an ssh connection. Any trouble shooting suggestions would be much appreciated. -- Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.5505] NetworkManager (version 1.4.6) is starting... Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.5507] Read config: /usr/local/etc/NetworkManager/nm-system-settings.conf Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.5766] manager[0xdd0028]: monitoring kernel firmware directory '/lib/firmware'. Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6028] dns-mgr[0xdda440]: init: dns=default, rc-manager=symlink Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6176] rfkill0: found WiFi radio killswitch (at /sys/devices/platform/soc/3f30.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/ieee80211/phy0/rfkill0) (driver brcmfmac) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6183] manager[0xdd0028]: WiFi hardware radio set enabled Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6184] manager[0xdd0028]: WWAN hardware radio set enabled Feb 18 05:55:02 box daemon.notice dbus[2961]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Feb 18 05:55:02 box daemon.notice dbus[2961]: [system] Activated service 'org.freedesktop.nm_dispatcher' failed: Failed to execute program org.freedesktop.nm_dispatcher: Permission denied Feb 18 05:55:02 box daemon.err NetworkManager[2966]: [1518933302.6487] dispatcher: could not get dispatcher proxy! Error calling StartServiceByName for org.freedesktop.nm_dispatcher: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program org.freedesktop.nm_dispatcher: Permission denied Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6495] settings: loaded plugin keyfile: (c) 2007 - 2015 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6565] settings: hostname: couldn't get property from hostnamed Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6585] dhcp-init: Using DHCP client 'dhcpcd' Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6587] manager: WiFi enabled by radio killswitch; enabled by state file Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6589] manager: WWAN enabled by radio killswitch; enabled by state file Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6590] manager: Networking is enabled by state file Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6594] Loaded device plugin: NMVxlanFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6595] Loaded device plugin: NMVlanFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6596] Loaded device plugin: NMVethFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6598] Loaded device plugin: NMTunFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6599] Loaded device plugin: NMMacvlanFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6600] Loaded device plugin: NMIPTunnelFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6601] Loaded device plugin: NMInfinibandFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6603] Loaded device plugin: NMEthernetFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6604] Loaded device plugin: NMBridgeFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6605] Loaded device plugin: NMBondFactory (internal) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.6951] Loaded device plugin: NMWwanFactory (/usr/local/lib/NetworkManager/libnm-device-plugin-wwan.so) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.7082] Loaded device plugin: NMWifiFactory (/usr/local/lib/NetworkManager/libnm-device-plugin-wifi.so) Feb 18 05:55:02 box daemon.info NetworkManager[2966]: [1518933302.7240] Loaded device plugin: NMBluezManager (/usr/local/lib/NetworkManager/libnm-device-plugin-bluetooth.so) Feb 18 05:55:02 box daemon.inf
RE: [PATCH 1/1] service: only attempt to load the 'tun' modules if necessary
> -Original Message-
> From: Thomas Haller [mailto:thal...@redhat.com]
> Sent: Friday, 04 July, 2014 18:28
> To: networkmanager-list@gnome.org; Bastien Nocera
> Cc: John Frankish; Thomas Haller
> Subject: [PATCH 1/1] service: only attempt to load the 'tun' modules if
> necessary
>
> 'tun' support might be compiled into the kernel, thus modprobe will always
> fail.
>
> https://mail.gnome.org/archives/networkmanager-list/2014-
> July/msg00014.html
>
> Signed-off-by: Thomas Haller
> ---
> src/nm-openvpn-service.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/nm-openvpn-service.c b/src/nm-openvpn-service.c index
> 84968e8..b45eb28 100644
> --- a/src/nm-openvpn-service.c
> +++ b/src/nm-openvpn-service.c
> @@ -1623,7 +1623,8 @@ main (int argc, char *argv[])
> if (debug)
> g_message ("nm-openvpn-service (version " DIST_VERSION
> ") starting...");
>
> - if (system ("/sbin/modprobe tun") == -1)
> + if ( !g_file_test ("/sys/class/misc/tun", G_FILE_TEST_EXISTS)
> + && (system ("/sbin/modprobe tun") == -1))
> exit (EXIT_FAILURE);
>
> plugin = nm_openvpn_plugin_new ();
> --
> 1.9.3
>
Everything works fine now :)
Thanks
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
networkmanager-openvpn will not connect
Using networkmanager-openvpn- 0.9.8.4 patched to use libsecret, I am unable to
connect.
After configuring the vpn connection using gnome-control-center, I'm prompted
for the vpn password, but after entering it I get the error " Connection
activation failed: the VPN service failed to start".
Running from the command line gives the output below.
The tun module is compiled into the 3.8.13 kernel I'm using (CONFIG_TUN=y), is
this the source of the error?
Regards
John
--
$ nmcli con up uuid 540fd671-39c7-4b1c-9745-ff4b5690e259
Error: Connection activation failed: the VPN service failed to start
$ sudo /usr/local/lib/NetworkManager/nm-openvpn-service --debug
** Message: nm-openvpn-service (version 0.9.8.4) starting...
modprobe: module tun not found in modules.dep
** Message: real_need_secrets: connection -
connection
name : "connection"
id : "VPN 1" (s)
uuid : "540fd671-39c7-4b1c-9745-ff4b5690e259" (s)
type : "vpn" (s)
permissions : ['user:tc:'] (s)
autoconnect : FALSE (s)
timestamp : 0 (sd)
read-only : FALSE (sd)
zone : NULL (sd)
master : NULL (sd)
slave-type : NULL (sd)
secondaries : [] (sd)
vpn
name : "vpn"
service-type : "org.freedesktop.NetworkManager.openvpn" (s)
user-name : NULL (sd)
data : [ { 'username': }, { 'comp-lzo': yes }, { 'remote':
uk1.vpn.xxx.com }, { 'connection-type': password }, { 'password-flags': 3 }, {
'ca': /mnt/sdb2/tmp/ca..com.crt }, ] (s)
secrets : [ ] (s)
ipv6
name : "ipv6"
method : "auto" (s)
dhcp-hostname : NULL (sd)
dns : [] (s)
dns-search : [] (sd)
addresses : [] (s)
routes : [] (s)
ignore-auto-routes : FALSE (sd)
ignore-auto-dns : FALSE (sd)
never-default : FALSE (sd)
may-fail : TRUE (sd)
ip6-privacy : -1 (sd)
ipv4
name : "ipv4"
method : "auto" (s)
dns : [] (s)
dns-search : [] (sd)
addresses : [] (s)
routes : [] (s)
ignore-auto-routes : FALSE (sd)
ignore-auto-dns : FALSE (sd)
dhcp-client-id : NULL (sd)
dhcp-send-hostname : TRUE (sd)
dhcp-hostname : NULL (sd)
never-default : FALSE (sd)
may-fail : TRUE (sd)
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: NetworkManager-openvpn-0.9.8.4 and gnome-keyring
> > > > > > > > The configure script for NetworkManager-openvpn-0.9.8.4 > > > > > > > > looks for gnome-keyring-1.pc, which is not present in > > > > > > > > gnome-keyring-3.10.1 > > > > > > > > > > > > > > > > Is this mean to be compiled with ''--without-gnome" for gnome-3? > > > > > > > > > > > > > > Which Linux distro do you have? The development headers are > > > > > > > often shipped in sub-packages, like "gnome-keyring-devel" or > > > > > > > "gnome-keyring- dev". It may also be named > > > > > > > "gnome-keyring-libs-devel" or "gnome-keyring- libs-dev". Does > > > > > > > your distro have any packages like that? > > > > > > > > > > > > > I compiled Gnome-keyring-3.10.1 from source - it looks like the > > > > > > source package no longer installs gnome-keyring-1.pc since about > > > > > > gnome-keyring- 3.4.x? > > > > > > > > > > > > The only libs installed are: > > > > > > > > > > > > /usr/local/lib/gnome-keyring/devel/gkm-gnome2-store-standalone > > > > > > .so > > > > > > /usr/local/lib/gnome-keyring/devel/gkm-secret-store-standalone > > > > > > .so > > > > > > /usr/local/lib/gnome-keyring/devel/gkm-ssh-store-standalone.so > > > > > > /usr/local/lib/gnome-keyring/devel/gkm-xdg-store-standalone.so > > > > > > /usr/local/lib/pkcs11/gnome-keyring-pkcs11.so > > > > > > /usr/local/lib/security/pam_gnome_keyring.so > > > > > > > > > > > > ..so perhaps this makes sense? > > > > > > > > > > I think I know the issue. Upstream GNOME switched to > > > > > "libsecret", which network-manager-openvpn was not ported to > > > > > use. We'll have to fix that in the NM-openvpn 0.9.8.x branch, it was > > > > > already fixed in git master. > > > > > > > > > > So the short answer is it's not going to work right now, but > > > > > should soon. > > > > > > > > John, can you test the attached patch? Let me know if this fixes > > > > the issue for you. Thanks! > > > > > > The one where I forget to attach the patch. Fixed. > > > > Thanks - the patch applies cleanly, but "make" fails as below. > > > > I tried substituting the libsecret CFLAGS and LIBS for > @GNOMEKEYRING_CFLAGS@ and @GNOMEKEYRING_LIBS@, but it didn't > help. > > Try re-running configure, there might be some generated files that need > updating after this patch. Does that help? > In fact I was missing the gettext dev files - all OK now, sorry for the confusion and thanks for the help. Cheers John ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: NetworkManager-openvpn-0.9.8.4 and gnome-keyring
> > > > > > The configure script for NetworkManager-openvpn-0.9.8.4 looks > > > > > > for gnome-keyring-1.pc, which is not present in > > > > > > gnome-keyring-3.10.1 > > > > > > > > > > > > Is this mean to be compiled with ''--without-gnome" for gnome-3? > > > > > > > > > > Which Linux distro do you have? The development headers are > > > > > often shipped in sub-packages, like "gnome-keyring-devel" or > > > > > "gnome-keyring- dev". It may also be named > > > > > "gnome-keyring-libs-devel" or "gnome-keyring- libs-dev". Does your > > > > > distro have any packages like that? > > > > > > > > > I compiled Gnome-keyring-3.10.1 from source - it looks like the source > > > > package no longer installs gnome-keyring-1.pc since about > > > > gnome-keyring- 3.4.x? > > > > > > > > The only libs installed are: > > > > > > > > /usr/local/lib/gnome-keyring/devel/gkm-gnome2-store-standalone.so > > > > /usr/local/lib/gnome-keyring/devel/gkm-secret-store-standalone.so > > > > /usr/local/lib/gnome-keyring/devel/gkm-ssh-store-standalone.so > > > > /usr/local/lib/gnome-keyring/devel/gkm-xdg-store-standalone.so > > > > /usr/local/lib/pkcs11/gnome-keyring-pkcs11.so > > > > /usr/local/lib/security/pam_gnome_keyring.so > > > > > > > > ..so perhaps this makes sense? > > > > > > I think I know the issue. Upstream GNOME switched to "libsecret", > > > which network-manager-openvpn was not ported to use. We'll have to > > > fix that in the NM-openvpn 0.9.8.x branch, it was already fixed in git > > > master. > > > > > > So the short answer is it's not going to work right now, but should > > > soon. > > > > John, can you test the attached patch? Let me know if this fixes the > > issue for you. Thanks! > > The one where I forget to attach the patch. Fixed. Thanks - the patch applies cleanly, but "make" fails as below. I tried substituting the libsecret CFLAGS and LIBS for @GNOMEKEYRING_CFLAGS@ and @GNOMEKEYRING_LIBS@, but it didn't help. John -- patch -Np1 -i ../0001-auth-dialog-port-to-libsecret.patch autoreconf -fi CC="gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe" CXX="g++ -flto -fuse-linker-plugin -mtune=generic -Os -pipe -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local --disable-static --localstatedir=/var --libexecdir=/usr/local/lib/NetworkManager make ... make[2]: Entering directory `/usr/src/NetworkManager-openvpn-0.9.8.4/auth-dialog' gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe -DHAVE_CONFIG_H -I. -I.. -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -pthread -I/usr/local/include/gtk-3.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/gtk-3.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/pango-1.0 -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include/libdrm -I/usr/local/include -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libpng16 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -DGDK_VERSION_MIN_REQUIRED=GDK_VERSION_3_0 -I/usr/local/include/NetworkM anager -I/usr/local/include/libnm-glib -I/usr/local/include/NetworkManager -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include @GNOMEKEYRING_CFLAGS@ -I../ -Wall -std=gnu89 -g -Wshadow -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wstrict-prototypes -Wfloat-equal -Wno-unused-parameter -Wno-sign-compare -fno-strict-aliasing -Wno-unused-but-set-variable -Werror -MT nm_openvpn_auth_dialog-main.o -MD -MP -MF .deps/nm_openvpn_auth_dialog-main.Tpo -c -o nm_openvpn_auth_dialog-main.o `test -f 'main.c' || echo './'`main.c gcc: error: @GNOMEKEYRING_CFLAGS@: No such file or directory make[2]: *** [nm_openvpn_auth_dialog-main.o] Error 1 make[2]: Leaving directory `/usr/src/NetworkManager-openvpn-0.9.8.4/auth-dialog' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/NetworkManager-openvpn-0.9.8.4' make: *** [all] Error 2 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: NetworkManager-openvpn-0.9.8.4 and gnome-keyring
> > The configure script for NetworkManager-openvpn-0.9.8.4 looks for > > gnome-keyring-1.pc, which is not present in gnome-keyring-3.10.1 > > > > Is this mean to be compiled with ''--without-gnome" for gnome-3? > > Which Linux distro do you have? The development headers are often > shipped in sub-packages, like "gnome-keyring-devel" or "gnome-keyring- > dev". It may also be named "gnome-keyring-libs-devel" or "gnome-keyring- > libs-dev". Does your distro have any packages like that? > I compiled Gnome-keyring-3.10.1 from source - it looks like the source package no longer installs gnome-keyring-1.pc since about gnome-keyring-3.4.x? The only libs installed are: /usr/local/lib/gnome-keyring/devel/gkm-gnome2-store-standalone.so /usr/local/lib/gnome-keyring/devel/gkm-secret-store-standalone.so /usr/local/lib/gnome-keyring/devel/gkm-ssh-store-standalone.so /usr/local/lib/gnome-keyring/devel/gkm-xdg-store-standalone.so /usr/local/lib/pkcs11/gnome-keyring-pkcs11.so /usr/local/lib/security/pam_gnome_keyring.so ..so perhaps this makes sense? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager-openvpn-0.9.8.4 and gnome-keyring
The configure script for NetworkManager-openvpn-0.9.8.4 looks for gnome-keyring-1.pc, which is not present in gnome-keyring-3.10.1 Is this mean to be compiled with ''--without-gnome" for gnome-3? Regards John ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.9 will not connect to wifi with non-broadcast ssid
> > > > > > -Original Message- > > > > > > From: John Frankish > > > > > > Sent: Friday, 25 April, 2014 17:41 > > > > > > To: networkmanager-list@gnome.org > > > > > > Subject: networkmanager-0.9.8.9 will not connect to wifi with > > > > > > non-broadcast ssid > > > > > > > > > > > > I've been trying to connect to a wap that does not broadcast > > > > > > the ssid for a while without success. > > > > > > > > > > > > Using the same setup with wpa_supplicant manually works using > > > > > > the wpa_supplicant.conf below. > > > > > > > > > > > > > > > > After some more checking I can confirm that > > > > > networkmanager/network- > > > > manager-applet will connect to a wap that does broadcast the ssid, > > > > which seems to confirm that the issue is with wap that do not broadcast > > > > the ssid. > > > > > > > > I've just verified that I can do both a new connection and a > > > > reconnection to a hidden-SSID access point here with 0.9.8.10, > > > > though with WEP not WPA (which shouldn't be an issue). From your logs: > > > > > > > > NetworkManager[1139]: Config: added 'ssid' value 'bobnet' > > > > NetworkManager[1139]: Config: added 'scan_ssid' value '1' > > > > > > > > NetworkManager doesn't store a supplicant config file, because the > > > > network blocks are created on-the-fly based on the NM > > > > configuration and what you type in, and a config file is pretty > > > > useless. But the logs show what NetworkManager is sending to the > > > > supplicant, which is exactly what would be written to the supplicant > > > > config file. > > > > > > > > So you can see that NM is sending scan_ssid=1. ap_scan=2 is *not* > > > > required for working WiFi drivers. It's only required for older > > > > broken drivers, and for Ad-Hoc mode. > > > > > > > > NetworkManager[1139]: (eth1): supplicant interface state: > > > > inactive -> scanning > > > > <30 seconds pass> > > > > NetworkManager[1139]: Activation (eth1/wireless): > > > > association took too long, failing activation. > > > > > > > > This is a problem much lower down, either with the AP, or with the > > > > supplicant and kernel. The scanning process for the AP should > > > > take anywhere between 1 and 10 seconds, often less than 2 or 3. > > > > > > > > To debug that, can you grab some detailed wpa_supplicant logs? > > > > Run these two commands, and the supplicant should start dumping > > > > logs to > > > > /var/log/wpa_supplicant.log: > > > > > > > > sudo dbus-send --system --print-reply > > > > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > > > > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > > > > string:DebugTimestamp variant:boolean:true > > > > > > > > sudo dbus-send --system --print-reply > > > > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > > > > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > > > > string:DebugLevel variant:string:"msgdump" > > > > > > > > You should see something like this when you ask NetworkManager to > > > > connect, or when NM tries to connect automatically: > > > > > > > > wlp12s0: State: INACTIVE -> SCANNING Scan SSID - > > > > hexdump_ascii(len=8) > > > > 66 6f 6f 62 61 72 32 32foobar22 > > > > ... > > > > nl80211: Scan SSID - hexdump_ascii(len=8) > > > > 66 6f 6f 62 61 72 32 32foobar22 > > > > ... > > > > wlp12s0: BSS: Add new id 15 BSSID <...> SSID 'foobar22' > > > > > > > Thanks for the suggestion - using wpa_supplicant -dddtu -f > > > /var/log/wpa_supplicant.log produced the attached output. > > > > > > It's odd that this times out - if I use wpa_supplicant manually it > > > connects in > > a few seconds as do windows and iOS devices. > > > > So I see with the manual bits you're setting ap_scan=2 for this network. > > Would you mind removing the ap_scan=2 for the manual c
RE: networkmanager-0.9.8.9 will not connect to wifi with non-broadcast ssid
> > > > > -Original Message- > > > > > From: John Frankish > > > > > Sent: Friday, 25 April, 2014 17:41 > > > > > To: networkmanager-list@gnome.org > > > > > Subject: networkmanager-0.9.8.9 will not connect to wifi with > > > > > non-broadcast ssid > > > > > > > > > > I've been trying to connect to a wap that does not broadcast the > > > > > ssid for a while without success. > > > > > > > > > > Using the same setup with wpa_supplicant manually works using > > > > > the wpa_supplicant.conf below. > > > > > > > > > > > > > After some more checking I can confirm that > > > > networkmanager/network- > > > manager-applet will connect to a wap that does broadcast the ssid, > > > which seems to confirm that the issue is with wap that do not broadcast > > > the ssid. > > > > > > I've just verified that I can do both a new connection and a > > > reconnection to a hidden-SSID access point here with 0.9.8.10, > > > though with WEP not WPA (which shouldn't be an issue). From your logs: > > > > > > NetworkManager[1139]: Config: added 'ssid' value 'bobnet' > > > NetworkManager[1139]: Config: added 'scan_ssid' value '1' > > > > > > NetworkManager doesn't store a supplicant config file, because the > > > network blocks are created on-the-fly based on the NM configuration > > > and what you type in, and a config file is pretty useless. But the > > > logs show what NetworkManager is sending to the supplicant, which is > > > exactly what would be written to the supplicant config file. > > > > > > So you can see that NM is sending scan_ssid=1. ap_scan=2 is *not* > > > required for working WiFi drivers. It's only required for older > > > broken drivers, and for Ad-Hoc mode. > > > > > > NetworkManager[1139]: (eth1): supplicant interface state: > > > inactive -> scanning > > > <30 seconds pass> > > > NetworkManager[1139]: Activation (eth1/wireless): association > > > took too long, failing activation. > > > > > > This is a problem much lower down, either with the AP, or with the > > > supplicant and kernel. The scanning process for the AP should take > > > anywhere between 1 and 10 seconds, often less than 2 or 3. > > > > > > To debug that, can you grab some detailed wpa_supplicant logs? Run > > > these two commands, and the supplicant should start dumping logs to > > > /var/log/wpa_supplicant.log: > > > > > > sudo dbus-send --system --print-reply > > > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > > > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > > > string:DebugTimestamp variant:boolean:true > > > > > > sudo dbus-send --system --print-reply > > > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > > > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > > > string:DebugLevel variant:string:"msgdump" > > > > > > You should see something like this when you ask NetworkManager to > > > connect, or when NM tries to connect automatically: > > > > > > wlp12s0: State: INACTIVE -> SCANNING Scan SSID - > > > hexdump_ascii(len=8) > > > 66 6f 6f 62 61 72 32 32foobar22 > > > ... > > > nl80211: Scan SSID - hexdump_ascii(len=8) > > > 66 6f 6f 62 61 72 32 32foobar22 > > > ... > > > wlp12s0: BSS: Add new id 15 BSSID <...> SSID 'foobar22' > > > > > Thanks for the suggestion - using wpa_supplicant -dddtu -f > /var/log/wpa_supplicant.log produced the attached output. > > > > It's odd that this times out - if I use wpa_supplicant manually it connects > > in > a few seconds as do windows and iOS devices. > > So I see with the manual bits you're setting ap_scan=2 for this network. > Would you mind removing the ap_scan=2 for the manual case and retrying? > Ensure that scan_ssid=1 is still present. There shouldn't be any need for > ap_scan=2 with a driver from the past 8 years, so lets just rule that out for > now. > > Also, when you're trying with NetworkManager, are you deleting the existing > stored connection and re-creating it? Or are you waiting for NM to start the > existing stored connection? > > There are two ways NM handles connections to h
RE: networkmanager-0.9.8.9 will not connect to wifi with non-broadcast ssid
> > > > -Original Message- > > > > From: John Frankish > > > > Sent: Friday, 25 April, 2014 17:41 > > > > To: networkmanager-list@gnome.org > > > > Subject: networkmanager-0.9.8.9 will not connect to wifi with > > > > non-broadcast ssid > > > > > > > > I've been trying to connect to a wap that does not broadcast the > > > > ssid for a while without success. > > > > > > > > Using the same setup with wpa_supplicant manually works using the > > > > wpa_supplicant.conf below. > > > > > > > > > > After some more checking I can confirm that networkmanager/network- > > manager-applet will connect to a wap that does broadcast the ssid, > > which seems to confirm that the issue is with wap that do not broadcast > the ssid. > > > > I've just verified that I can do both a new connection and a > > reconnection to a hidden-SSID access point here with 0.9.8.10, though > > with WEP not WPA (which shouldn't be an issue). From your logs: > > > > NetworkManager[1139]: Config: added 'ssid' value 'bobnet' > > NetworkManager[1139]: Config: added 'scan_ssid' value '1' > > > > NetworkManager doesn't store a supplicant config file, because the > > network blocks are created on-the-fly based on the NM configuration > > and what you type in, and a config file is pretty useless. But the > > logs show what NetworkManager is sending to the supplicant, which is > > exactly what would be written to the supplicant config file. > > > > So you can see that NM is sending scan_ssid=1. ap_scan=2 is *not* > > required for working WiFi drivers. It's only required for older > > broken drivers, and for Ad-Hoc mode. > > > > NetworkManager[1139]: (eth1): supplicant interface state: > > inactive -> scanning > > <30 seconds pass> > > NetworkManager[1139]: Activation (eth1/wireless): association > > took too long, failing activation. > > > > This is a problem much lower down, either with the AP, or with the > > supplicant and kernel. The scanning process for the AP should take > > anywhere between 1 and 10 seconds, often less than 2 or 3. > > > > To debug that, can you grab some detailed wpa_supplicant logs? Run > > these two commands, and the supplicant should start dumping logs to > > /var/log/wpa_supplicant.log: > > > > sudo dbus-send --system --print-reply > > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > > string:DebugTimestamp variant:boolean:true > > > > sudo dbus-send --system --print-reply > > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > > string:DebugLevel variant:string:"msgdump" > > > > You should see something like this when you ask NetworkManager to > > connect, or when NM tries to connect automatically: > > > > wlp12s0: State: INACTIVE -> SCANNING > > Scan SSID - hexdump_ascii(len=8) > > 66 6f 6f 62 61 72 32 32foobar22 > > ... > > nl80211: Scan SSID - hexdump_ascii(len=8) > > 66 6f 6f 62 61 72 32 32foobar22 > > ... > > wlp12s0: BSS: Add new id 15 BSSID <...> SSID 'foobar22' > > > Thanks for the suggestion - using wpa_supplicant -dddtu -f > /var/log/wpa_supplicant.log produced the attached output. > > It's odd that this times out - if I use wpa_supplicant manually it connects > in a > few seconds as do windows and iOS devices. > In case it's useful I've attached the log from using wpa_supplicant manually - in this case it connects in a few seconds, even via a wifi repeater, which does not broadcast the ssid. wpa_supplicant_no_ssid_repeater_manual.log.tar.gz Description: wpa_supplicant_no_ssid_repeater_manual.log.tar.gz ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.9 will not connect to wifi with non-broadcast ssid
> > > -Original Message- > > > From: John Frankish > > > Sent: Friday, 25 April, 2014 17:41 > > > To: networkmanager-list@gnome.org > > > Subject: networkmanager-0.9.8.9 will not connect to wifi with > > > non-broadcast ssid > > > > > > I've been trying to connect to a wap that does not broadcast the > > > ssid for a while without success. > > > > > > Using the same setup with wpa_supplicant manually works using the > > > wpa_supplicant.conf below. > > > > > > > After some more checking I can confirm that networkmanager/network- > manager-applet will connect to a wap that does broadcast the ssid, which > seems to confirm that the issue is with wap that do not broadcast the ssid. > > I've just verified that I can do both a new connection and a reconnection to a > hidden-SSID access point here with 0.9.8.10, though with WEP not WPA > (which shouldn't be an issue). From your logs: > > NetworkManager[1139]: Config: added 'ssid' value 'bobnet' > NetworkManager[1139]: Config: added 'scan_ssid' value '1' > > NetworkManager doesn't store a supplicant config file, because the network > blocks are created on-the-fly based on the NM configuration and what you > type in, and a config file is pretty useless. But the logs show what > NetworkManager is sending to the supplicant, which is exactly what would > be written to the supplicant config file. > > So you can see that NM is sending scan_ssid=1. ap_scan=2 is *not* required > for working WiFi drivers. It's only required for older broken drivers, and > for > Ad-Hoc mode. > > NetworkManager[1139]: (eth1): supplicant interface state: > inactive -> scanning > <30 seconds pass> > NetworkManager[1139]: Activation (eth1/wireless): association took > too long, failing activation. > > This is a problem much lower down, either with the AP, or with the > supplicant and kernel. The scanning process for the AP should take > anywhere between 1 and 10 seconds, often less than 2 or 3. > > To debug that, can you grab some detailed wpa_supplicant logs? Run these > two commands, and the supplicant should start dumping logs to > /var/log/wpa_supplicant.log: > > sudo dbus-send --system --print-reply > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > string:DebugTimestamp variant:boolean:true > > sudo dbus-send --system --print-reply > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > string:DebugLevel variant:string:"msgdump" > > You should see something like this when you ask NetworkManager to > connect, or when NM tries to connect automatically: > > wlp12s0: State: INACTIVE -> SCANNING > Scan SSID - hexdump_ascii(len=8) > 66 6f 6f 62 61 72 32 32foobar22 > ... > nl80211: Scan SSID - hexdump_ascii(len=8) > 66 6f 6f 62 61 72 32 32foobar22 > ... > wlp12s0: BSS: Add new id 15 BSSID <...> SSID 'foobar22' > Thanks for the suggestion - using wpa_supplicant -dddtu -f /var/log/wpa_supplicant.log produced the attached output. It's odd that this times out - if I use wpa_supplicant manually it connects in a few seconds as do windows and iOS devices. John wpa_supplicant_no_ssid_base.log.tar.gz Description: wpa_supplicant_no_ssid_base.log.tar.gz ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.9 will not connect to wifi with non-broadcast ssid
> > > -Original Message- > > > From: John Frankish > > > Sent: Friday, 25 April, 2014 17:41 > > > To: networkmanager-list@gnome.org > > > Subject: networkmanager-0.9.8.9 will not connect to wifi with > > > non-broadcast ssid > > > > > > I've been trying to connect to a wap that does not broadcast the > > > ssid for a while without success. > > > > To debug that, can you grab some detailed wpa_supplicant logs? Run these > two commands, and the supplicant should start dumping logs to > /var/log/wpa_supplicant.log: > > sudo dbus-send --system --print-reply > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > string:DebugTimestamp variant:boolean:true > > sudo dbus-send --system --print-reply > --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 > string:DebugLevel variant:string:"msgdump" Thanks for the suggestion. I did the following: Start the NetworkManager daemon "startx" Issued the commands: $ sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugTimestamp variant:boolean:true [method return sender=:1.5 -> dest=:1.32 reply_serial=2] $ sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"msgdump" [method return sender=:1.5 -> dest=:1.33 reply_serial=2] And then used network-manager-applet to connect ..but no /var/log/wpa_supplicant.log was created. Did I make a mistake in the sequence or the dbus commands? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.9 will not connect to wifi with non-broadcast ssid
> -Original Message- > From: John Frankish > Sent: Friday, 25 April, 2014 17:41 > To: networkmanager-list@gnome.org > Subject: networkmanager-0.9.8.9 will not connect to wifi with non-broadcast > ssid > > I've been trying to connect to a wap that does not broadcast the ssid for a > while without success. > > Using the same setup with wpa_supplicant manually works using the > wpa_supplicant.conf below. > > Apparently "scan_ssid=1" is required for non-broadcast ssid (and perhaps > also ap_scan=2). > > I cannot find where networkmanager/network-manager-applet stores the > wpa_supplicant.conf to check if it is using scan_ssid=1, is there a way to > find > out? > > The connection details are also copied below and the networkmanager > debug output attached - maybe networkmanager doesn't wait long enough > to connect? > > Regards > John After some more checking I can confirm that networkmanager/network-manager-applet will connect to a wap that does broadcast the ssid, which seems to confirm that the issue is with wap that do not broadcast the ssid. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
networkmanager-0.9.8.9 will not connect to wifi with non-broadcast ssid
I've been trying to connect to a wap that does not broadcast the ssid for a
while without success.
Using the same setup with wpa_supplicant manually works using the
wpa_supplicant.conf below.
Apparently "scan_ssid=1" is required for non-broadcast ssid (and perhaps also
ap_scan=2).
I cannot find where networkmanager/network-manager-applet stores the
wpa_supplicant.conf to check if it is using scan_ssid=1, is there a way to find
out?
The connection details are also copied below and the networkmanager debug
output attached - maybe networkmanager doesn't wait long enough to connect?
Regards
John
--
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=2
fast_reauth=1
network={
ssid="bobnet"
psk=""
scan_ssid=1
key_mgmt=WPA-PSK
proto=WPA2
pairwise=CCMP
group=CCMP
priority=5
}
--
[connection]
id=bobnet
uuid=e7c20582-ba21-44bb-9739-32f1a7087b25
type=802-11-wireless
[802-11-wireless]
ssid=bobnet
mac-address=64:27:37:22:AB:51
security=802-11-wireless-security
[802-11-wireless-security]
key-mgmt=wpa-psk
psk=
[ipv4]
method=auto
[ipv6]
method=auto
networkmanager_wifi_log
Description: networkmanager_wifi_log
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.9 will not connect to a wired network
> > > > On Tue, 2014-04-22 at 10:05 +, John Frankish wrote: > > > > > I compiled networkmanager-0.9.8.9 from source to /usr/local to use > > > > > dhcpcd (also compiled from source). > > > > > > > > > > Since networkmanager configured as above looks for > > > > > /usr/local/etc/hosts, I adjusted the source to look at /etc/hosts (it > > > > > already knew to look for /etc/resolv.conf). > > > > > > > > > > Run from the console, neworkmanager looks as though it connects to an > > > > > ipv4 wired network (I've tried two different networks), modifies > > > > > /etc/resolv.conf accordingly, but it does not actually connect -I > > > > > cannot ping the router nor google.com. > > > > > > > > > > Dhcpcd run alone from the console connects without problems. > > > > > > > > > > This is the same problem I experienced using networkmanager- 0.9.8.8 > > > > > reported in another thread. > > > > > > > > > > I've attached the networkmanager debug output and the strace output, > > > > > but neither seem to give a clue as to the problem - I believe that > > > > > either networkmanager is trying to write something to /usr/local/etc > > > > > that is in /etc (or vice versa) or there is some kind of > > > > > linux-pam/polkit permissions error, but I cannot see evidence of > > > > > either in the debug output. > > > > > > > > > > From the debug snippet below things look to have worked, but they > > > > > didn't - any troubleshooting hints would be gratefully received. > > > > > > > > The x.x.x.x/0 bits are likely the problem. Let's investigate why > > > > that's happening especially since NetworkManager says it got the > > > > right prefix from dhcpcd. > > > > > > > > Would you mind applying the attached patch to your sources? Then > > > > re-run the test and reply with the output so we can debug a bit further. > > > > > > One more thing, when things aren't working, can you provide the > > > output > > > of: > > > > > > ip addr > > > ip route > > > > > Thanks for the reply and the patch > > > > The patch applied cleanly, but unfortunately things still do not work - > > debug output attached. > > > > My system does not have the "ip" command, but the "route" command produces > > the following: > > > > $ route > > Kernel IP routing table > > Destination Gateway Genmask Flags Metric RefUse > > Iface > > default 10.180.20.1 0.0.0.0 UG0 00 eth0 > > 10.180.20.1 * 255.255.255.255 UH0 00 eth0 > > 127.0.0.1 * 255.255.255.255 UH0 00 lo > > > > Shouldn't that be 255.255.255.0? > > Yes, and that's the problem. The issue is in your logs: > > NetworkManager[6200]: nm_ip4_config_to_rtnl_addr: created > '10.180.20.104/0 inet dev (null) scope nowhere ' from '10.180.20.104/24' flags > 0xD > > What libnl version are you using? > > I've tested current NM 0.9.8.10 git and it works OK here with libnl 3.2.24... > The culprit is likely nm_ip4_config_to_rtnl_addr() which sets the rtnl address > prefix length, but not the binary address prefix length. If you're up for > another patch, try the attached and let me know if it works correctly. > Thanks - things now work with a wired connection from the console and gnome-session-3.10.x Wireless didn't want to work from gnome-session, but that's with a wap that does not broadcast the ssid, which I know causes problems for some systems. I'm using libnl-3.2.21 Thanks again for the help. John ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: NetworkManager 0.9.8.10
> -Original Message- > From: networkmanager-list [mailto:networkmanager-list- > boun...@gnome.org] On Behalf Of Dan Winship > Sent: Thursday, 24 April, 2014 20:23 > To: networkmanager-list@gnome.org > Subject: ANN: NetworkManager 0.9.8.10 > > Continuing in our tradition of delivering important GNOME bug fixes too late > for the release, we present NetworkManager 0.9.8.10 and network- > manager-applet 0.9.8.10. > > Besides fixing two bugs that affect the GNOME shell network icon (and I > think maybe also the current version of the KDE NetworkManager applet?), > 0.9.8.10 contains a number of other miscellaneous bug fixes cherry- picked > from git master; see NEWS for more details. > > (FYI, these also contain a few new bugfixes since the 0.9.8.9 release > candidates.) > > http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.9/ > http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.9/ > The news files are missing? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Future development of nm-applet
> On Wed, 2014-04-23 at 09:13 +0200, Paul Menzel wrote: > > Dear NetworkManager folks, > > > > > > I am excited for the 1.0 release! Before that happens a small question. > > > > NetworkManager is a GNOME project, could you please clarify what the > > future of the applet is now that GNOME Shell provides an “applet”(?) > > themselves? > > NM is actually more of a freedesktop.org project, but we just happen to use > a lot of the GNOME infrastructure because it's a pain to change everything > over (especially bugzilla!). > > But anyway, the GNOME desktop will continue to use and develop the > GNOME Shell network indicator and control center network panel, because > they are a much better fit for the UI and interaction design of the GNOME > Shell. > > However, we (the NetworkManager project) intend to continue to maintain > nm-applet and nm-connection-editor as standalone components that other > GTK-based desktops like LXDE and XFCE can use. While nm-applet is clearly > receiving less attention than it has in the past, it's not going to die. > > If anyone is interested in helping maintain the applet, or implement new > features, or make it look slicker, please start sending patches and cleanups! > Is this speaking of network-manager-applet or something else called nm-applet that could be used with gtk and a non-gnome window manager like fluxbox, flwm, etc? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.9 will not connect to a wired network
> > > On Tue, 2014-04-22 at 10:05 +0000, John Frankish wrote: > > > > I compiled networkmanager-0.9.8.9 from source to /usr/local to use > > > > dhcpcd (also compiled from source). > > > > > > > > Since networkmanager configured as above looks for > > > > /usr/local/etc/hosts, I adjusted the source to look at /etc/hosts (it > > > > already knew to look for /etc/resolv.conf). > > > > > > > > Run from the console, neworkmanager looks as though it connects to an > > > > ipv4 wired network (I've tried two different networks), modifies > /etc/resolv.conf accordingly, but it does not actually connect -I cannot ping > the router nor google.com. > > > > > > > > Dhcpcd run alone from the console connects without problems. > > > > > > > > This is the same problem I experienced using networkmanager-0.9.8.8 > > > > reported in another thread. > > > > > > > > I've attached the networkmanager debug output and the strace output, > > > > but neither seem to give a clue as to the problem - I believe that > > > > either networkmanager is trying to write something to /usr/local/etc > > > > that is in /etc (or vice versa) or there is some kind of > > > > linux-pam/polkit permissionserror, but I cannot see evidence of either > > > > in the debug output. > > > > > > > > From the debug snippet below things look to have worked, but they > > > > didn't - any troubleshooting hints would be gratefully received. > > > > > > The x.x.x.x/0 bits are likely the problem. Let's investigate why > > > that's happening especially since NetworkManager says it got the > > > right prefix from dhcpcd. > > > > > > Would you mind applying the attached patch to your sources? Then > > > re-run the test and reply with the output so we can debug a bit further. > > > > One more thing, when things aren't working, can you provide the output > > of: > > > > ip addr > > ip route > > > Thanks for the reply and the patch > > The patch applied cleanly, but unfortunately things still do not work - debug > output attached. > > My system does not have the "ip" command, but the "route" command > produces the following: > > $ route > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > default 10.180.20.1 0.0.0.0 UG0 00 eth0 > 10.180.20.1 * 255.255.255.255 UH0 00 eth0 > 127.0.0.1 * 255.255.255.255 UH0 00 lo > > Shouldn't that be 255.255.255.0? > I compiled iproute2 - the output is pasted below. >From the comparison of NetworkManager (not working) to uphcpdc (working), it >looks like NetworkManager is trying to assign a static ip address? Regards John -- $ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: dummy0: mtu 1500 qdisc noop state DOWN group default link/ether da:99:56:25:5d:6b brd ff:ff:ff:ff:ff:ff 3: tunl0: mtu 1480 qdisc noop state DOWN group default link/ipip 0.0.0.0 brd 0.0.0.0 4: ip_vti0: mtu 1500 qdisc noop state DOWN group default link/ipip 0.0.0.0 brd 0.0.0.0 5: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 24:b6:fd:fa:e1:60 brd ff:ff:ff:ff:ff:ff $ ip route [NetworkManager] default via 10.180.20.1 dev eth0 proto static 10.180.20.1 dev eth0 proto static scope link 127.0.0.1 dev lo scope link $ ip route [udhcpc] default via 10.180.20.1 dev eth0 10.180.20.0/24 dev eth0 proto kernel scope link src 10.180.20.126 127.0.0.1 dev lo scope link ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.9 will not connect to a wired network
> > On Tue, 2014-04-22 at 10:05 +, John Frankish wrote: > > > I compiled networkmanager-0.9.8.9 from source to /usr/local to use dhcpcd > > > (also compiled from source). > > > > > > Since networkmanager configured as above looks for /usr/local/etc/hosts, > > > I adjusted the source to look at /etc/hosts (it already knew to look for > > > /etc/resolv.conf). > > > > > > Run from the console, neworkmanager looks as though it connects to an > > > ipv4 wired network (I've tried two different networks), modifies > > > /etc/resolv.conf accordingly, but it does not actually connect -I cannot > > > ping the router nor google.com. > > > > > > Dhcpcd run alone from the console connects without problems. > > > > > > This is the same problem I experienced using networkmanager-0.9.8.8 > > > reported in another thread. > > > > > > I've attached the networkmanager debug output and the strace output, but > > > neither seem to give a clue as to the problem - I believe that either > > > networkmanager is trying to write something to /usr/local/etc that is in > > > /etc (or vice versa) or there is some kind of linux-pam/polkit > > > permissions error, but I cannot see evidence of either in the debug > > > output. > > > > > > From the debug snippet below things look to have worked, but they didn't > > > - any troubleshooting hints would be gratefully received. > > > > The x.x.x.x/0 bits are likely the problem. Let's investigate why > > that's happening especially since NetworkManager says it got the right > > prefix from dhcpcd. > > > > Would you mind applying the attached patch to your sources? Then > > re-run the test and reply with the output so we can debug a bit further. > > One more thing, when things aren't working, can you provide the output > of: > > ip addr > ip route > Thanks for the reply and the patch The patch applied cleanly, but unfortunately things still do not work - debug output attached. My system does not have the "ip" command, but the "route" command produces the following: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default 10.180.20.1 0.0.0.0 UG0 00 eth0 10.180.20.1 * 255.255.255.255 UH0 00 eth0 127.0.0.1 * 255.255.255.255 UH0 00 lo Shouldn't that be 255.255.255.0? Regards John networkmanager_log_1.tar.gz Description: networkmanager_log_1.tar.gz ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.8 will not connect to ipv4 wired network
> > On Sat, 2014-04-05 at 12:54 +, John Frankish wrote: > > > Using networkmanager-0.9.8.8 and dhcpcd-6.3.2, I am unable to > > > connect to > > a wired connection eth0. > > > > > > If networkmanager is stopped, dhcpcd will connect without problems. > > > > > > The problem appears to be that networkmanager is stuck in a loop > > > trying to > > make an ipv6 connection when the connection is ipv4 - ipv6 is disabled > > on the router. > > > > The reason is that there is another dhcpcd process running, while > > NetworkManager needs a private dhcpcd process, because it needs to > > receive the options back from the dhcpcd that it runs. More info below... > > Ah - I tried this many times, I must have copied an example where dhcpcd > was running by mistake. > > > > There is another minor issue in that networkworkmanager is looking > > > for > > hosts in /usr/local/etc rather than /etc, but adding a symlink does > > not resolve the issue. > > > > /usr/local/etc would be due to a configure-time issue, like many > > projects when you're running configure, you need to specify > > "--prefix=/usr -- sysconfdir=/etc --localstatedir=/var" to put things > > in the right place, otherwise it will default to /usr/local to avoid > > overwriting your existing installation. > > Networkmanager was compiled to /usr/local - the logic is that the base > system is under /usr and anything additional is under /usr/local. > > Since /etc/resolv.conf and /etc/hosts are on the base system, I did not move > them > > > > Is there some way to disable ipv6 in a networkmanager conf file? > > > > IPv6 is disabled in each connection profile by setting the IPv6 > > configuration "method" to "ignore". So for a keyfile, you would use: > > > > [ipv6] > > method=ignore > > > > or just pick that method in the various GUI editors. > > > > > dhcpcd[30849]: dhcpcd already running on pid 30823 > > > (/var/run/dhcpcd-eth0.pid) > > > NetworkManager[30842]: (eth0): DHCPv4 client pid 30849 exited > > > with status 1 > > > > Here, the private dhcpcd that NetworkManager spawns with the options > > that NetworkManager requires, has noticed that there is another dhcpcd > > process running. You can't have two DHCP clients running for the same > > interface, otherwise they'll fight over which one handles DHCP. So > > you don't want the one you ran manually above to continue running when > > you're using NetworkManager. I've tried many, many times to make this work (and verified no other network daemon is running). Wired from the console Wireless using network-manager-applet In all cases things appear to have worked - the correct information (by comparison with dhcpcd and udhcpc run alone) is written to /etc/resolv.conf - but it is as if networkmanager fails to hand a working network connection back to the system. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.8 will not connect to ipv4 wired network
> On Sat, 2014-04-05 at 12:54 +0000, John Frankish wrote: > > Using networkmanager-0.9.8.8 and dhcpcd-6.3.2, I am unable to connect to > a wired connection eth0. > > > > If networkmanager is stopped, dhcpcd will connect without problems. > > > > The problem appears to be that networkmanager is stuck in a loop trying to > make an ipv6 connection when the connection is ipv4 - ipv6 is disabled on the > router. > > The reason is that there is another dhcpcd process running, while > NetworkManager needs a private dhcpcd process, because it needs to > receive the options back from the dhcpcd that it runs. More info below... Ah - I tried this many times, I must have copied an example where dhcpcd was running by mistake. > > There is another minor issue in that networkworkmanager is looking for > hosts in /usr/local/etc rather than /etc, but adding a symlink does not > resolve > the issue. > > /usr/local/etc would be due to a configure-time issue, like many projects > when you're running configure, you need to specify "--prefix=/usr -- > sysconfdir=/etc --localstatedir=/var" to put things in the right place, > otherwise it will default to /usr/local to avoid overwriting your existing > installation. Networkmanager was compiled to /usr/local - the logic is that the base system is under /usr and anything additional is under /usr/local. Since /etc/resolv.conf and /etc/hosts are on the base system, I did not move them > > Is there some way to disable ipv6 in a networkmanager conf file? > > IPv6 is disabled in each connection profile by setting the IPv6 configuration > "method" to "ignore". So for a keyfile, you would use: > > [ipv6] > method=ignore > > or just pick that method in the various GUI editors. > > > dhcpcd[30849]: dhcpcd already running on pid 30823 > > (/var/run/dhcpcd-eth0.pid) > > NetworkManager[30842]: (eth0): DHCPv4 client pid 30849 exited > > with status 1 > > Here, the private dhcpcd that NetworkManager spawns with the options > that NetworkManager requires, has noticed that there is another dhcpcd > process running. You can't have two DHCP clients running for the same > interface, otherwise they'll fight over which one handles DHCP. So you don't > want the one you ran manually above to continue running when you're using > NetworkManager. Thanks for the reply - I pasted another debug log below with the ipv6 errors removed - the full log is attached. From the log, it looks as though things are working, but I cannot ping the router or google. -- Apr 7 17:33:30 box authpriv.notice sudo: tc : TTY=tty1 ; PWD=/home/tc ; USER=root ; COMMAND=/usr/local/etc/init.d/dbus start Apr 7 17:33:42 box authpriv.notice sudo: tc : TTY=tty1 ; PWD=/home/tc ; USER=root ; COMMAND=/usr/local/etc/init.d/networkmanager start $ ps aux | grep Net 6236 root /usr/local/sbin/NetworkManager 6254 root /usr/local/sbin/dhcpcd -B -K -L -G -c /usr/local/lib/NetworkManager/nm-dhcp-client.action -4 eth0 Apr 7 17:33:42 box daemon.info NetworkManager[6236]: NetworkManager (version 0.9.8.9) is starting... Apr 7 17:33:42 box daemon.info NetworkManager[6236]: Read config file /usr/local/etc/NetworkManager/nm-system-settings.conf Apr 7 17:33:42 box daemon.info NetworkManager[6236]: WEXT support is enabled Apr 7 17:33:42 box daemon.notice dbus[6232]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) Apr 7 13:33:42 box daemon.info polkitd[6241]: Started polkitd version 0.112 Apr 7 13:33:42 box authpriv.notice polkitd[6241]: Loading rules from directory /usr/local/etc/polkit-1/rules.d Apr 7 13:33:42 box authpriv.notice polkitd[6241]: Loading rules from directory /usr/local/share/polkit-1/rules.d Apr 7 13:33:42 box authpriv.notice polkitd[6241]: Error opening rules directory: Error opening directory '/usr/local/share/polkit-1/rules.d': No such file or directory (g-file-error-quark, 4) Apr 7 13:33:42 box authpriv.notice polkitd[6241]: :0: can't open /usr/local/etc/polkit-1/rules.d/50-default.rules: No such file or directory Apr 7 13:33:42 box authpriv.notice polkitd[6241]: Error compiling script /usr/local/etc/polkit-1/rules.d/50-default.rules Apr 7 13:33:42 box authpriv.notice polkitd[6241]: Finished loading, compiling and executing 1 rules Apr 7 17:33:42 box daemon.notice dbus[6232]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' Apr 7 13:33:42 box authpriv.notice polkitd[6241]: Acquired the name org.freedesktop.PolicyKit1 on the system bus Apr 7 17:33:42 box daemon.info NetworkManager[6236]: Loaded plugin keyfile: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. Apr 7 17:33:42 box daemon.info NetworkMa
RE: networkmanager-0.9.8.8 will not connect to ipv4 wired network
> > -Original Message- > > From: John Frankish > > Sent: Saturday, 05 April, 2014 16:54 > > To: 'networkmanager-list@gnome.org' > > Subject: networkmanager-0.9.8.8 will not connect to ipv4 wired network > > > > Using networkmanager-0.9.8.8 and dhcpcd-6.3.2, I am unable to connect > > to a wired connection eth0. > > > > If networkmanager is stopped, dhcpcd will connect without problems. > > > > The problem appears to be that networkmanager is stuck in a loop > > trying to make an ipv6 connection when the connection is ipv4 - ipv6 > > is disabled on the router. > > > > There is another minor issue in that networkworkmanager is looking for > > hosts in /usr/local/etc rather than /etc, but adding a symlink does > > not resolve the issue. > > > > Is there some way to disable ipv6 in a networkmanager conf file? > > To add to this, both wired and wireless connections (via network-manager- > applet) appear to connect, the log reports an ip address has been assigned, > /etc/resolv.conf is modified with the ip address of the router, but I cannot > ping the router. > > Using the gnome-control-center network panel to disable ipv6 does not help > and I notice that the dns server and gateway addresses for both wired and > wireless connections are blank. > > Both dhcpcd and udhcpc without networkmanager connect without > problems. I used the output of "nmcli dev list iface eth0" to populate the blanks in the gnome-control-center network panel: DNS section - entered dns ip Routes section - entered ip address, netmask, gateway ip ..and finally things work. I noticed that this changed "/usr/local/etc/NetworkManager/system-connections/Wired Connection 1" [802-3-ethernet] mac-address=24:B6:FD:FA:E1:60 [connection] id=Wired connection 1 uuid=ed68afcc-88f2-45a4-b920-67a8a929eb4b type=802-3-ethernet timestamp=1396795087 [ipv6] method=ignore [ipv4] method=auto dns=10.180.1.10; route1=10.180.20.123/24,10.180.20.1,0 ..by adding the last two entries. What I don't understand is why networkmanager cannot do this automatically - is it because the default "Wired Connection 1" has spaces in the name (?!) or is it some sort of dbus/polkit/linux-pam permissions issue? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: networkmanager-0.9.8.8 will not connect to ipv4 wired network
> -Original Message- > From: John Frankish > Sent: Saturday, 05 April, 2014 16:54 > To: 'networkmanager-list@gnome.org' > Subject: networkmanager-0.9.8.8 will not connect to ipv4 wired network > > Using networkmanager-0.9.8.8 and dhcpcd-6.3.2, I am unable to connect to a > wired connection eth0. > > If networkmanager is stopped, dhcpcd will connect without problems. > > The problem appears to be that networkmanager is stuck in a loop trying to > make an ipv6 connection when the connection is ipv4 - ipv6 is disabled on the > router. > > There is another minor issue in that networkworkmanager is looking for > hosts in /usr/local/etc rather than /etc, but adding a symlink does not > resolve > the issue. > > Is there some way to disable ipv6 in a networkmanager conf file? To add to this, both wired and wireless connections (via network-manager-applet) appear to connect, the log reports an ip address has been assigned, /etc/resolv.conf is modified with the ip address of the router, but I cannot ping the router. Using the gnome-control-center network panel to disable ipv6 does not help and I notice that the dns server and gateway addresses for both wired and wireless connections are blank. Both dhcpcd and udhcpc without networkmanager connect without problems. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
networkmanager-0.9.8.8 will not connect to ipv4 wired network
Using networkmanager-0.9.8.8 and dhcpcd-6.3.2, I am unable to connect to a wired connection eth0. If networkmanager is stopped, dhcpcd will connect without problems. The problem appears to be that networkmanager is stuck in a loop trying to make an ipv6 connection when the connection is ipv4 - ipv6 is disabled on the router. There is another minor issue in that networkworkmanager is looking for hosts in /usr/local/etc rather than /etc, but adding a symlink does not resolve the issue. Is there some way to disable ipv6 in a networkmanager conf file? Logs below: $ sudo dhcpcd -d eth0 dhcpcd[7246]: version 6.3.2 starting dhcpcd[7246]: all: IPv6 kernel autoconf disabled dhcpcd[7246]: eth0: IPv6 kernel autoconf disabled dhcpcd[7246]: eth0: executing `/usr/local/lib/dhcpcd/dhcpcd-run-hooks' PREINIT dhcpcd[7246]: eth0: executing `/usr/local/lib/dhcpcd/dhcpcd-run-hooks' CARRIER dhcpcd[7246]: DUID 00:01:00:01:1a:d2:d5:f9:24:b6:fd:fa:e1:60 dhcpcd[7246]: eth0: IAID fd:fa:e1:60 dhcpcd[7246]: eth0: reading lease `/var/tmp/dhcpcd-eth0.lease' dhcpcd[7246]: eth0: rebinding lease of 192.168.1.110 dhcpcd[7246]: eth0: sending REQUEST (xid 0xaf9abff6), next in 4.7 seconds dhcpcd[7246]: eth0: acknowledged 192.168.1.110 from 192.168.1.1 dhcpcd[7246]: eth0: leased 192.168.1.110 for 86400 seconds dhcpcd[7246]: eth0: renew in 43200 seconds, rebind in 75600 seconds dhcpcd[7246]: eth0: IP address 192.168.1.110/24 already exists dhcpcd[7246]: eth0: adding route to 192.168.1.0/24 dhcpcd[7246]: eth0: adding default route via 192.168.1.1 dhcpcd[7246]: eth0: writing lease `/var/tmp/dhcpcd-eth0.lease' dhcpcd[7246]: eth0: executing `/usr/local/lib/dhcpcd/dhcpcd-run-hooks' BOUND dhcpcd[7246]: forking to background dhcpcd[7246]: forked to background, child pid 7279 $ cat /etc/resolv.conf # Generated by dhcpcd from eth0 # /etc/resolv.conf.head can replace this line nameserver 192.168.1.1 # /etc/resolv.conf.tail can replace this line $ ping -c1 google.com PING google.com (173.194.113.227): 56 data bytes 64 bytes from 173.194.113.227: seq=0 ttl=52 time=126.545 ms -- $ sudo NetworkManager --no-daemon --log-level=DEBUG NetworkManager[30842]: NetworkManager (version 0.9.8.8) is starting... NetworkManager[30842]: Read config file /usr/local/etc/NetworkManager/nm-system-settings.conf NetworkManager[30842]: WEXT support is enabled NetworkManager[30842]: Loaded plugin keyfile: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. NetworkManager[30842]:keyfile: parsing Wired connection 1 ... NetworkManager[30842]:keyfile: read connection 'Wired connection 1' NetworkManager[30842]: [1396713869.172302] [nm-modem-manager.c:376] modem_manager_disappeared(): trying to start the modem manager... NetworkManager[30842]: [1396713869.172428] [nm-modem-manager.c:280] poke_modem_cb(): Requesting to (re)launch modem-manager... NetworkManager[30842]: monitoring kernel firmware directory '/lib/firmware'. NetworkManager[30842]: [1396713869.172938] [nm-firewall-manager.c:248] nm_firewall_manager_init(): firewall is not running NetworkManager[30842]: WiFi hardware radio set enabled NetworkManager[30842]: [1396713869.177240] [nm-policy-hosts.c:72] nm_policy_hosts_clean_etc_hosts(): couldn't read /usr/local/etc/hosts: (4) Failed to open file '/usr/local/etc/hosts': No such file or directory NetworkManager[30842]: WiFi enabled by radio killswitch; enabled by state file NetworkManager[30842]: WWAN enabled by radio killswitch; enabled by state file NetworkManager[30842]: WiMAX enabled by radio killswitch; enabled by state file NetworkManager[30842]: Networking is enabled by state file NetworkManager[30842]: failed to allocate link cache: (-10) Operation not supported NetworkManager[30842]: [1396713869.179832] [nm-device-ethernet.c:1607] supports_ethtool_carrier_detect(): ethtool is supported NetworkManager[30842]: [1396713869.179970] [NetworkManagerUtils.c:684] nm_utils_get_proc_sys_net_value(): (eth0): error reading /proc/sys/net/ipv6/conf/eth0/accept_ra: (4) Failed to open file '/proc/sys/net/ipv6/conf/eth0/accept_ra': No such file or directory NetworkManager[30842]: [1396713869.180089] [NetworkManagerUtils.c:684] nm_utils_get_proc_sys_net_value(): (eth0): error reading /proc/sys/net/ipv6/conf/eth0/use_tempaddr: (4) Failed to open file '/proc/sys/net/ipv6/conf/eth0/use_tempaddr': No such file or directory NetworkManager[30842]: [1396713869.180145] [nm-device-wired.c:313] constructor(): (eth0): kernel ifindex 5 NetworkManager[30842]: (eth0): carrier is ON NetworkManager[30842]: [1396713869.180634] [nm-device-ethernet.c:260] constructor(): (eth0): kernel ifindex 5 NetworkManager[30842]: [1396713869.181342] [nm-device-ethernet.c:484] update_initial_hw_address(): (eth0): read initial MAC address 24:B6:FD:FA:E1:60 NetworkManager[30842]: (eth0): new Ethernet device (driver: 'e1000e' ifindex: 5) NetworkManager[30842]: (eth0): exported as /org/freedesktop/NetworkM
