Re: NMClient.IP4Config get_addresses() not always populated when signal 'notify::ip4-config' is fired
On Mon, 2015-03-23 at 22:39 +0100, Sylvain Garaud wrote:
Hello,
You are perfectly right. I used finally the ip4config and not the dhcp4
config to get the ip. Looking at the dbus-monitor logs I thought I could
save the ip decoding step by using the dhcp4 config. But it is not enough
generic.
Just to rule out some other stuff, can you try the attached Python
program? Just run it (python notify-ips.py) and then reproduce the
issue with ethernet. Do you get output like:
notify: GParamObject 'ip4-config' : state 80
192.168.1.197/24 192.168.1.1
or do you get something else?
Thanks!
Dan
Here is the log where I simply go from wired ethernet off to on. I think I
get an ip4config signal from the line 204 in the log but it does not
include the addresses. The real one is at line 403. Not so sure what is
the expected behavior. I have the following piece of code at line 166 which
seems to work ok for that case.
https://github.com/sgaraud/gnome-extension-show-ip/blob/master/extension.js#L166
at line 173, this is for the case when I sometimes get double notifications
if I put up the ethernet com then down just before it get the dhcp4 config
and up again. At that time it seems I get some old signals.
Regards,
Sylvain
On Mon, Mar 23, 2015 at 5:58 PM, Dan Williams d...@redhat.com wrote:
On Fri, 2015-03-20 at 01:31 +0100, Sylvain Garaud wrote:
Hello Dan,
Thank you for the answer.
I am using NM lib version 0.9.10.0
I use the dbus-monitor command you provided.
It helped me greatly to understand my problem.
In most cases the ip info I am interested in was defined when the
IP4Config
propertiesChanges signal was received. But it was not always the case
depending of the network interface type and disconnection time. My
routine
using the gi.NMClient was also missing to capture some signals that I
saw
with the dbus-monitor as sometimes they were arriving in a burst.
Eventually I implemented the following solution that seems to be working
properly.
1. I register a callback on the device state-changed signal
2. Within the callback, I try immediately to get the ip address inside
the
dhcp4 config.
3. If I get it I am done, otherwise it is undefined and I simply
register a
callback on the dhcp4 options signal that hopefully will arrive later.
I tested it with several configuration and it seems to work correctly.
Getting the IP address through the DHCP4 config won't give you user
overrides, secondary IP addresses, or static IP configurations though.
This still sounds like a bug in NM or libnm-glib, and if you still have
the logs from dbus-monitor I'd like to take a look.
Thanks!
Dan
Thank you so much,
Sylvain
On Wed, Mar 18, 2015 at 3:44 PM, Dan Williams d...@redhat.com wrote:
On Sun, 2015-03-15 at 12:46 +0100, Sylvain Garaud wrote:
Hello,
I am writing a small javascript for gnome to grab the ip addresses
of my
network interfaces using imports.gi.NMClient;
Basically I get the devices and connect each device to the
notify::ip4-config signal to be able to update the ip address value
when
it
changes
Which version of NM are you using?
this.client = NMC.Client.new();
this.devices = this.client.get_devices();
for each (let device in this.devices) {
device.connect('notify::ip4-config',Lang.bind(this,this._update));
}
It works fine for the wifi connection but there is a problem with the
ethernet connection.
After turning my ethernet connection up, the signal
'notify::ip4-config'
is fired, the device state is ACTIVATED, so I try to get the ip4
config.
with ipcfg = device.get_ip4_config();
I get a not null ipcfg object, unfortunately ipcfg.get_addresses()
is not
defined yet.
So that we can narrow the issue down, could you run:
dbus-monitor --system
type='signal',sender='org.freedesktop.NetworkManager'
and reproduce the problem? This will let us know the sequence of D-BUs
events that come directly from NetworkManager, so that we can see the
raw data that libnm/libnm-glib is getting.
Dan
I see in my journalctl log few seconds later, some dhcp network
manager
message.
_update: function(device) {
let ipcfg = device.get_ip4_config();
if (ipcfg != null) {
for each(let addr in ipcfg.get_addresses()){
let num = addr.get_address();
}
}
},
How to be sure ipcfg.get_addresses() will return something ?
Could someone tell me which signal to use for being sure the ip
address
is
set when calling ipcfg.get_addresses()? I tried using the
'notify::dhcp4-config' signal instead 'notify::ip4-config' without
much
success.
Thank you very much for your help,
Sylvain
Re: Build Error on Raspberry Pi
On Tue, 2015-03-24 at 13:53 -0400, Jordan Messina wrote: I'm trying to build Network Manager 1.0 from source on a Raspberry Pi running RASPBIAN Debian Wheezy. I'm using gcc4.8. Getting the following error: Interesting; linux/if.h should get pulled in from the #include nm-platform.h in nm-ppp-manager.c. Can you do something like: #include nm-platform.h +#ifdef _LINUX_IF_H +linux if has been included! +#endif #include nm-core-internal.h in nm-ppp-manager.c and see if the compiler errors on that? If so we know linux/if.h has been found by the preprocessor. Also, what compiler flags are being used? This should tell you: grep ^CFLAGS = src/ppp-manager/Makefile Dan In file included from ppp-manager/nm-ppp-manager.c:42:0:/usr/include/linux/if_ppp.h:103:16: error: field 'b' has incomplete type struct ifreq b; ^/usr/include/linux/if_ppp.h:108:21: error: field 'b' has incomplete type struct ifreq b; ^Makefile:1499: recipe for target 'nm-ppp-manager.lo' failed make[4]: *** [nm-ppp-manager.lo] Error 1 make[4]: Leaving directory '/home/pi/NetworkManager-1.0.0/src'Makefile:2001: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/pi/NetworkManager-1.0.0/src'Makefile:1051: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/pi/NetworkManager-1.0.0/src'Makefile:608: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/pi/NetworkManager-1.0.0'Makefile:502: recipe for target 'all' failed make: *** [all] Error 2 Not sure why this is happening. Is it using the wrong PPP headers? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection failed to be established: privat-key-password-failure
On Mon, 2015-03-23 at 00:44 +0100, Thomas Schneider wrote: The OpenVPN connection fails with the following error: SIGUSR1[soft,private-key-password-failure] received, process restarting I have verified that the private-key-password is stored in Standard keyring as: VPN cert-pass secret for VPN connection. (see attachment) What version of NM and NetworkManager-openvpn? Also, you can run NM with debugging by doing this: sudo nmcli g log level debug and then recreate the error, and email me the system logs from NM privately so I can diagnose, with something like journalctl -b -u NetworkManager (if you're using the systemd journal) or by looking at /var/log/messages or /var/log/daemon.log. I'll then followup with the analysis as a reply to this thread. Thanks! Dan My config is this: [connection] id=VPN uuid=340bf0b0-5fdf-42cd-ad28-ead553655fdc type=vpn permissions= autoconnect=false secondaries= [ipv6] method=auto dns-search= ip6-privacy=0 [ipv4] method=auto dns-search= [vpn] service-type=org.freedesktop.NetworkManager.openvpn connection-type=tls auth=SHA256 tunnel-mtu=1500 cipher=AES-256-CBC comp-lzo=yes remote=dyndns cert-pass-flags=1 port=1194 dev-type=tun cert=/etc/openvpn/config/VPN/pc.crt ca=/etc/openvpn/config/VPN/pc.pem key=/etc/openvpn/config/VPN/pc.key ta=/etc/openvpn/config/VPN/ta.key I was expecting that line cert-pass-flags=1 forces usage of keyring, however this expected behavior is not working. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NMClient.IP4Config get_addresses() not always populated when signal 'notify::ip4-config' is fired
On Fri, 2015-03-20 at 01:31 +0100, Sylvain Garaud wrote:
Hello Dan,
Thank you for the answer.
I am using NM lib version 0.9.10.0
I use the dbus-monitor command you provided.
It helped me greatly to understand my problem.
In most cases the ip info I am interested in was defined when the IP4Config
propertiesChanges signal was received. But it was not always the case
depending of the network interface type and disconnection time. My routine
using the gi.NMClient was also missing to capture some signals that I saw
with the dbus-monitor as sometimes they were arriving in a burst.
Eventually I implemented the following solution that seems to be working
properly.
1. I register a callback on the device state-changed signal
2. Within the callback, I try immediately to get the ip address inside the
dhcp4 config.
3. If I get it I am done, otherwise it is undefined and I simply register a
callback on the dhcp4 options signal that hopefully will arrive later.
I tested it with several configuration and it seems to work correctly.
Getting the IP address through the DHCP4 config won't give you user
overrides, secondary IP addresses, or static IP configurations though.
This still sounds like a bug in NM or libnm-glib, and if you still have
the logs from dbus-monitor I'd like to take a look.
Thanks!
Dan
Thank you so much,
Sylvain
On Wed, Mar 18, 2015 at 3:44 PM, Dan Williams d...@redhat.com wrote:
On Sun, 2015-03-15 at 12:46 +0100, Sylvain Garaud wrote:
Hello,
I am writing a small javascript for gnome to grab the ip addresses of my
network interfaces using imports.gi.NMClient;
Basically I get the devices and connect each device to the
notify::ip4-config signal to be able to update the ip address value when
it
changes
Which version of NM are you using?
this.client = NMC.Client.new();
this.devices = this.client.get_devices();
for each (let device in this.devices) {
device.connect('notify::ip4-config',Lang.bind(this,this._update));
}
It works fine for the wifi connection but there is a problem with the
ethernet connection.
After turning my ethernet connection up, the signal 'notify::ip4-config'
is fired, the device state is ACTIVATED, so I try to get the ip4 config.
with ipcfg = device.get_ip4_config();
I get a not null ipcfg object, unfortunately ipcfg.get_addresses() is not
defined yet.
So that we can narrow the issue down, could you run:
dbus-monitor --system
type='signal',sender='org.freedesktop.NetworkManager'
and reproduce the problem? This will let us know the sequence of D-BUs
events that come directly from NetworkManager, so that we can see the
raw data that libnm/libnm-glib is getting.
Dan
I see in my journalctl log few seconds later, some dhcp network manager
message.
_update: function(device) {
let ipcfg = device.get_ip4_config();
if (ipcfg != null) {
for each(let addr in ipcfg.get_addresses()){
let num = addr.get_address();
}
}
},
How to be sure ipcfg.get_addresses() will return something ?
Could someone tell me which signal to use for being sure the ip address
is
set when calling ipcfg.get_addresses()? I tried using the
'notify::dhcp4-config' signal instead 'notify::ip4-config' without much
success.
Thank you very much for your help,
Sylvain
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Should network-manger manage virbr0 ?
On Thu, 2015-03-19 at 09:18 +0100, Franck Routier (perso) wrote: Hi list, I'm using Ubuntu and just upgraded to (still in development) Vivid. Now I see that network-manager handles my virbr0 bridge (libvirt), which it didn't before. NM will recognize and manage all network interfaces, but that does not mean that NM actually touches the interfaces. If the interface already has a configuration, NM simply assumes the existing configuration and waits for you to tell it to do something. That's a difference from older versions of NM (0.9.8 and earlier) where NM was mostly ignorant of existing configuration. We know that NM 0.9.10 still has a few edge cases where it touches interfaces and shouldn't, but almost all of those have already been fixed in NM 1.0 and later. Dan Vivid currently ships with nm 0.9.10.0. I can't make a decision whether this is a (packaging ?) bug or an intended feature, and what will be the consequences of nm mananging virbr0. Can anyone enlighten me ? thanks, Franck ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NMClient.IP4Config get_addresses() not always populated when signal 'notify::ip4-config' is fired
On Sun, 2015-03-15 at 12:46 +0100, Sylvain Garaud wrote:
Hello,
I am writing a small javascript for gnome to grab the ip addresses of my
network interfaces using imports.gi.NMClient;
Basically I get the devices and connect each device to the
notify::ip4-config signal to be able to update the ip address value when it
changes
Which version of NM are you using?
this.client = NMC.Client.new();
this.devices = this.client.get_devices();
for each (let device in this.devices) {
device.connect('notify::ip4-config',Lang.bind(this,this._update));
}
It works fine for the wifi connection but there is a problem with the
ethernet connection.
After turning my ethernet connection up, the signal 'notify::ip4-config'
is fired, the device state is ACTIVATED, so I try to get the ip4 config.
with ipcfg = device.get_ip4_config();
I get a not null ipcfg object, unfortunately ipcfg.get_addresses() is not
defined yet.
So that we can narrow the issue down, could you run:
dbus-monitor --system type='signal',sender='org.freedesktop.NetworkManager'
and reproduce the problem? This will let us know the sequence of D-BUs
events that come directly from NetworkManager, so that we can see the
raw data that libnm/libnm-glib is getting.
Dan
I see in my journalctl log few seconds later, some dhcp network manager
message.
_update: function(device) {
let ipcfg = device.get_ip4_config();
if (ipcfg != null) {
for each(let addr in ipcfg.get_addresses()){
let num = addr.get_address();
}
}
},
How to be sure ipcfg.get_addresses() will return something ?
Could someone tell me which signal to use for being sure the ip address is
set when calling ipcfg.get_addresses()? I tried using the
'notify::dhcp4-config' signal instead 'notify::ip4-config' without much
success.
Thank you very much for your help,
Sylvain
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] examples: bash: print errors int stderr
On Wed, 2015-03-18 at 20:37 +0100, Petr Vorel wrote: + whitespace Signed-off-by: Petr Vorel petr.vo...@gmail.com Thanks! Pushed to git master and nm-1-0. Dan --- examples/shell/active-wifi.sh | 2 +- examples/shell/disconnect-device.sh | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/examples/shell/active-wifi.sh b/examples/shell/active-wifi.sh index 1c9466b..2ff5419 100755 --- a/examples/shell/active-wifi.sh +++ b/examples/shell/active-wifi.sh @@ -76,7 +76,7 @@ show_active_ssids() BSSID=`get_property $ACTIVE_AP $ACCESS_POINT_IFACE HwAddress` echo Device '$INTERFACE' is connected to '$SSID' (BSSID=$BSSID) else -echo No active AP on device '$INTERFACE' +echo No active AP on device '$INTERFACE' 2 fi fi done diff --git a/examples/shell/disconnect-device.sh b/examples/shell/disconnect-device.sh index 045d64d..e8af42f 100755 --- a/examples/shell/disconnect-device.sh +++ b/examples/shell/disconnect-device.sh @@ -61,7 +61,7 @@ disconnect_device () fi done - echo Device with interface '$1' not found. + echo Device with interface '$1' not found. 2 return 1 } @@ -70,7 +70,7 @@ disconnect_device () if [ ! -n $1 ]; then echo Usage: `basename $0` interface name exit 2 -fi +fi # disconnect device disconnect_device $1 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [review] th/keyfile
Hi Thomas, About th/keyfile... libnm: add _nm_utils_hash_values_to_ptrarray() function What about g_hash_table_get_values() instead? It returns the values as a GList* instead of a GPtrArray, were you just worried about memory allocation here? The rest looks OK to me. Do we need to update any testcases for the sort ordering? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No more IPv4 address after boot up since NM 0.9.10
On Thu, 2015-03-12 at 13:30 +0100, Thomas Haller wrote: On Thu, 2015-03-12 at 07:32 -0400, Pavel Simerda wrote: - Original Message - From: Thomas Haller thal...@redhat.com To: Harald Dunkel harald.dun...@aixigo.de Cc: networkmanager. networkmanager-list@gnome.org, Pavel Simerda psime...@redhat.com Sent: Thursday, March 12, 2015 11:54:49 AM Subject: Re: No more IPv4 address after boot up since NM 0.9.10 On Thu, 2015-03-12 at 10:32 +0100, Harald Dunkel wrote: On Wed, 04 Mar 2015 18:15:43 +0100 Frederik Himpe frede...@frehi.be wrote: I still think that NM's behaviour not to touch the interface when it's up already is counter-intuitive. If I start up NM with a configuration for eth0, then I _do_ want this configuration to be applied, just like the distro specific init networking scripts would do. If you don't want NM to touch an existing interface, then it makes more sense to me to completely disable NM, or to set this specific interface unmanaged in NM. Maybe this behaviour should be configurable? I am affected by exactly the same problem, and I completely agree with Frederik. Some improvement here would be highly appreciated. ok, but what is the concrete suggestion? How about adding a autoconnect-boot argument to a connection. What about my original suggestion of onboot as a separate option from auto[1] plus a new behavior that onboot connections would be enforced even if the device is already configured? [1] https://bugzilla.gnome.org/show_bug.cgi?id=700651 ah right. that was it. ISTR the issue with that would be how to not break existing behavior that assumes that onboot is TRUE. Plus the original onboot stuff was about blocking startup, not forcefully starting the connection? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On Thu, 2015-03-12 at 09:04 -0500, Alex Ferm wrote: We use cellular modems for telemetry, and they disconnect every so often, and don't come back on-line on their own. I am using dbus via python to send Enable(False) followed by Enable(True) to reset network manager. This makes it reconnect to all the automatic connections that have been configured. What version of NetworkManager? I think 0.9.10 or later added WWAN autoconnect, which should handle this better. In any case, the Enable() mechanism is much better than I was thinking you were going to say :) If you're already using NM 0.9.10 or later and NM isn't attempting to reconnect, then it would be great to see some logs from the device so we can figure out what's going on. One more question: do you mind if the connection starts automatically when NM starts? If that's OK, then autoconnect=true + NM 0.9.10 should do what you want already unless there's a bug. Dan Alex Ferm PetroPower, LLC. 3003 E. 37th Street N. Suite 100 Wichita, KS 67219 Phone: (316) 361-0222 Toll Free: (877) 265-6581 Fax: (316) 361-0967 On 03/11/2015 07:49 PM, Stuart D. Gathman wrote: On Wed, 11 Mar 2015, Dan Williams wrote: On Wed, 2015-03-11 at 15:57 -0500, Alex Ferm wrote: Hello, I'm trying to write a python script that resets NetworkManager when the state is not NM_STATE_CONNECTED_GLOBAL. Does NetworkManager time out and retry automatically during the NM_STATE_CONNECTING state? Also, how is the NM_STATE_CONNECTED_GLOBAL determined(ie: is there a periodic ping or something?)? 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. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On Wed, 2015-03-11 at 20:49 -0400, Stuart D. Gathman wrote: On Wed, 11 Mar 2015, Dan Williams wrote: On Wed, 2015-03-11 at 15:57 -0500, Alex Ferm wrote: Hello, I'm trying to write a python script that resets NetworkManager when the state is not NM_STATE_CONNECTED_GLOBAL. Does NetworkManager time out and retry automatically during the NM_STATE_CONNECTING state? Also, how is the NM_STATE_CONNECTED_GLOBAL determined(ie: is there a periodic ping or something?)? 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... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Power management in NM
On Thu, 2015-03-12 at 14:27 +0200, Andrey Batyiev wrote: Hello I'm trying to figure out power management policies in NM. My app sometimes need to connect to Wi-Fi network even if user powered down Wi-Fi card (to save battery charge). Main problem here is an airplane/aircraft/flight mode, when user expects Wi-Fi to be offline at all times. My question is: am I correct, there is no way to distinguish between situation Wi-Fi is powered down for power savings and situation Wi-Fi is powered down because of airplane regulations? As far as I am understand right now, NM have only enable/disable switch for each device type, and there is no global airplane mode switch, right? What is your opinion on implementing such switch? From a kernel and userspace perspective, these are both the same thing. The mechanism to do this for both is setting airplane mode, because only with airplane mode does the device actually power down and save battery. There are two ways the user can set airplane mode. First is through a hardware switch on the laptop which cannot be reversed programmatically. The second is through a 'soft block' which *can* be reversed programmatically, which is typically what UI elements will do when you turn on airplane mode from the GUI or CLI. Unfortunately there's no good way to determine intent from either of these, and worse, some laptops don't have a hardware button but rely entirely on the software mechanisms to set airplane mode. My only thought is that if wifi is only soft-blocked, then perhaps the application could ask the user whether it should be allowed to connect or not, and if the user says yes then it can turn off the softblock and attempt to connect. Maybe that would work? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On Thu, 2015-03-12 at 11:54 -0400, Stuart Gathman wrote: On 03/11/2015 06:23 PM, Dan Williams wrote: On Wed, 2015-03-11 at 15:57 -0500, Alex Ferm wrote: Hello, I'm trying to write a python script that resets NetworkManager when the state is not NM_STATE_CONNECTED_GLOBAL. Does NetworkManager time out and retry automatically during the NM_STATE_CONNECTING state? Also, how is the NM_STATE_CONNECTED_GLOBAL determined(ie: is there a periodic ping or something?)? 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 general, it would be useful if NM was able to detect that networking was hosed and reset things. How would it know, however? I generally ping the gateway manually to check the connection. Are gateways always pingable? Just checking for a connection is not sufficient - e.g. when wpa_supplicant hangs (radio is operational, but incoming and outgoing packets have expired key and are discarded). Microsoft used to ping one If the packets have an expired key, then that implies that key rotation has not happened. That's done on a timer that's negotiated during the EAP or WPA-PSK setup. If you had wpa_supplicant debug logs you could probably figure out what's going on in the supplicant. of their servers. But that could be a problem anywhere in between the PC and their server. NM does that with it's connectivity checking functionality, but of course since it's phone home functionality more or less, that must be enabled by the user/admin. NM does advertise the result via dbus/nmcli, but does not yet do anything with it internally. It's also not per-interface yet, so you couldn't use the result to determine whether a specific interface was hosted or not. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
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
Re: Maintaining connection
On Thu, 2015-03-12 at 14:09 -0400, Stuart Gathman wrote: On 03/12/2015 12:40 PM, Dan Williams wrote: 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. Already did that in f19 (see log in above bugzilla) - it doesn't log anything while hung (maybe I didn't have as many 'd's). But maybe F21 will be different. It takes a little over 3 days to hang with hardware crypto. So hang on ... :-) Yeah, but that log isn't a debug log, it's just the normal messages. -dddtu will add a ton of debug info from which we might be able to find out why rekeying isn't happening. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [review] backport th/memleaks-nm-1-0
On Thu, 2015-03-12 at 16:38 +0100, Thomas Haller wrote: On Wed, 2015-03-11 at 17:14 +0100, Thomas Haller wrote: On Thu, 2015-03-05 at 12:36 +0100, Thomas Haller wrote: Hi all, more backports ready, please see: th/memleaks-nm-1-0 Looks good to me, I pushed some cherry-picks from git master for a leak I found and some suppression updates for newer glib. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On Wed, 2015-03-11 at 15:57 -0500, Alex Ferm wrote: Hello, I'm trying to write a python script that resets NetworkManager when the state is not NM_STATE_CONNECTED_GLOBAL. Does NetworkManager time out and retry automatically during the NM_STATE_CONNECTING state? Also, how is the NM_STATE_CONNECTED_GLOBAL determined(ie: is there a periodic ping or something?)? 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? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No (more) OpenVPN on Debian8 (Jessie)
On Thu, 2015-03-05 at 19:00 +0100, system_error wrote: Hello developers, I have a Problem whit Jessie and my OpenVPN. I am looking for help at the Debian Forum first, but i get no Answers :( (0) Maybe only developers can help by this issue? I use following packages: network-manager | 0.9.10.0-6 network-manager debug | 0.9.10.0-6 network-manager-openvpn | 0.9.10.0-1 network-manager-openvpn-gnome | 0.9.10.0-1 #I start Networkconnections at NM-Manager (Jessie / Cinnamon) Mar 5 14:55:31 desktop dbus[521]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' #I select my *.conf file, i get from my VPN-Provider (it's works on Wheezy!) Mar 5 14:55:31 desktop systemd[1]: Failed to reset devices.list on /system.slice: Invalid argument Mar 5 14:55:31 desktop dbus[521]: [system] Successfully activated service 'org.freedesktop.hostname1' #NM-Manager (Window) crashes. My LAN was still allive (whitout VPN) Mar 5 14:55:45 desktop kernel: [ 1140.258095] nm-connection-e[2123]: segfault at 1326510 ip 01326510 sp 7fff11ebda18 error 15 So this looks like a crash in the editor, and based on some other traces Michael provided last week could be an issue in the NM OpenVPN plugin. I tried to reproduce the issue (with a given sample .ovpn file) last week but couldn't using 0.9.10.2. Are you able to provide a openvpn connection file that I can try the import with? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManagerFailed to read classid file: Object not found
On Fri, 2015-03-06 at 11:02 +0100, Thomas Haller wrote: On Thu, 2015-03-05 at 12:10 -0800, Ali Nematollahi wrote: Hi guys I am trying to use apt-get to install NM on my TI distribution of Linux. It installs everything fine, and I have the systemd and dbus all installed. When I try to start the NM after the installation is over, it comes back with the following error message: What is TI? NetworkManagerFailed to read classid file: Object not found How do you try to start NetworkManager? Where do you see this message? Is there some context around this message? If you use systemd, then you would normally start NetworkManager via systemd. What gives systemctl status NetworkManager I can't figure out what that means and I haven't been able to find any info on the web that could fix the problem. I can't get the NM to work and I'm really stuck trying to figure it out. I might be missing a library or something. Can someone help me troubleshoot this please? apt-get should install all the required libraries. Unless there is a problem with your distribution or these packages. This message appears to come from libnl3, actually. See classid_init() and rtnl_tc_read_classid_file(), I think it's looking for /etc/libnl/classid. Do you have that file? You might need to configure libnl3 with the right --prefix and --sysconfdir. Thomas, maybe this warning should be downgraded to a debug or something? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 0.9.10.2 released
Hi, I'm pleased to announce the release of NetworkManager 0.9.10.2, the latest stable release in the 0.9.10.x series. We do however recommend that users upgrade to the NetworkManager 1.0 stable series, which is D-Bus and C API backwards compatible, and includes stability and cooperation enhancements, a smaller footprint, and enhanced CLI capabilities over 0.9.10. The 0.9.10.2 release is mostly a bugfix release, but it does resolve a huge number of issues and memory leaks. An overview of the changes in 0.9.10.2 is here http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=nm-0-9-10 Thanks to everyone who tested and contributed patches and translations! https://download.gnome.org/sources/NetworkManager/0.9/NetworkManager-0.9.10.2.tar.xz https://download.gnome.org/sources/network-manager-applet/0.9/network-manager-applet-0.9.10.2.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/0.9/NetworkManager-vpnc-0.9.10.2.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/0.9/NetworkManager-openvpn-0.9.10.2.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/0.9/NetworkManager-openconnect-0.9.10.2.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/0.9/NetworkManager-pptp-0.9.10.2.tar.xz Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No more IPv4 address after boot up since NM 0.9.10
On Mon, 2015-03-02 at 22:03 +0100, Frederik Himpe wrote: On ma, 2015-03-02 at 14:22 -0600, Dan Williams wrote: I also have netconsole activated via this line in a file in /etc/modprobe.d: options netconsole netconsole=@192.168.5.205/eth0,@192.168.5.128/24:77:03:f0:16:64 Could this be related in some way? Yes, that might well bring the interface into IFF_UP state before NM starts, at which point the interface might already be assigned both IPv4 and IPv6 LL addresses before NM starts, leading to the behavior you see. OK, I removed all this netconsole stuff, rebuild my initrd and deleted the eth0 network connection in NM, and at the next reboot, everything was working. I am not sure whether this is a really satisfying solution though: what if I would want to debug potential kernel errors during boot, then NM will cause your these kind of troubles? Well, I don't think NM is causing any kind of troubles at all, it's just noticing that the interface is configured already when it starts, and tries very hard not to mess with the interface. The kernel is setting the interface IFF_UP, and that causes the kernel to assign an IPv6LL address to the interface, and then start IPv6 SLAAC on it. That results in the interface receiving an global IPv6 address, and that's what NM is noticing and not touching, because the interface has already been configured... NetworkManager has no idea whether the administrator of the system expects the interface to remain configured that way or not, and NM reconfiguring the interface could (for example) badly break bootup when your filesystem is on the network. One option would be to put something like ip addr flush dev eth0 in your rc.local if you know you don't care about the kernel configuration after bootup... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No more IPv4 address after boot up since NM 0.9.10
On Mon, 2015-03-02 at 20:54 +0100, Frederik Himpe wrote: On ma, 2015-03-02 at 20:43 +0100, Thomas Haller wrote: The question is, who configures that interface? Don't do that if you don't want it. Maybe some script that ups the interface and enables SLAAC? I have no idea. Does not the kernel automatically configure the IPv6 using SLAAC without any user space intervention? Or should I set /proc/sys/net/ipv6/conf/*/accept_ra to 0 in order to use NM? Yes, it might, if something is setting the interface IFF_UP before NM starts. I also have netconsole activated via this line in a file in /etc/modprobe.d: options netconsole netconsole=@192.168.5.205/eth0,@192.168.5.128/24:77:03:f0:16:64 Could this be related in some way? Yes, that might well bring the interface into IFF_UP state before NM starts, at which point the interface might already be assigned both IPv4 and IPv6 LL addresses before NM starts, leading to the behavior you see. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCPv6 DDNS registration with FQDN
On Thu, 2015-02-26 at 11:12 +0100, Alexander Groß wrote: The patch was applied successfully and I was able to build on Fedora 21 with these commands (if you have opinions about these, I'm happy to learn more about your build system - I'm still a Linux noob): $ ./autogen.sh \ --prefix=/usr\ --sysconfdir=/etc\ --localstatedir=/var \ --with-nmtui $ make $ make install The DHCP packets look good now and I got the occasional DDNS update to happen successfully. I write occassional, because there's a new outstanding issue. Excellent. I'll merge the patch then. Windows DHCP has the option to protect DNS entries with a DHCID RR https://tools.ietf.org/html/draft-ietf-dnsext-dhcid-rr-13 next to the A/ RR to prevents name squatting (examples https://technet.microsoft.com/en-us/library/dd759188.aspx?f=255MSPPError=-2147217396). It's not really Windows-specific, but from my 30 minute research there seems to be a problem with two dhclient instances (-4 and -6) requesting IPv4 and IPv6 addresses in short succession. For illustration, let's say IPv4 is the first DHCP server transaction to finish. The DHCP server will request a DDNS update with a DHCID computed based on the DHCPv4 request. The DHCID RR is placed next to the A RR in DNS. The last string is the DHCID: Yes, the interaction between DHCPv6 DUID and the IPv4 client ID is a bit more complicated than just treating the two separately as used to be the case. I don't think we can ignore existing client IDs since that would break stable IP addresses for many people, but we can start using the DUID to create the v4 ClientID for new leases, I think. That'll take a bit more work though. 30,02/26/15,00:15:39,DNS Update Request,172.16.0.27,fedora.wghoch4.local,,,0,6,,AAIB9bp2uTdfLzJh0EvCVjZaAX8wFfhJnVtyWlwdswZmz6A=, 32,02/26/15,00:15:40,DNS Update Successful,172.16.0.27,fedora.wghoch4.local,,,0,6,,AAIB9bp2uTdfLzJh0EvCVjZaAX8wFfhJnVtyWlwdswZmz6A=, When the DHCPv6 transaction finishes a couple of milliseconds later, the DHCPv6 server will request a DDNS update with a DHCID computed based on the DHCPv6 request, which is different: 11022,02/26/15,00:15:41,DNS IPV6 Update Request,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.localAAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=, 11024,02/26/15,00:15:41,DNS IPV6 Update Successful,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.localAAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=, The DNS server will check the second DHCID against the one it already knows and reject the DDNS update (the log above says it was successful, but Windows logs generally suck ;-) It's easy to confirm that the DHCID RR is actually the culprit. Just delete it from the DNS, re-request DHCPv6 and the RR shows up. My dhclient man page has the following snippet: -df duid-lease-file Path to a secondary lease file. If the primary lease file doesn't contain a DUID this file will be searched. The DUID read from the secondary will be written to the primary. This option can be used to allow an IPv4 instance of the client to share a DUID with an IPv6 instance. After starting one of the instances the second can be started with this option pointing to the lease file of the first instance. There is no default. If no file is specified no search is made for a DUID should one not be found in the main lease file. The DUID https://tools.ietf.org/html/rfc3315#section-9 is a main contributor to the DHCID. As both IPv4 and IPv6 addresses are requested by/for the same interface it seems NM should make sure to use the same DUID for its requests. Yes, it should, according to http://www.ietf.org/rfc/rfc4361.txt . I've filed https://bugzilla.gnome.org/show_bug.cgi?id=745243 to track the issue. Thanks for your help! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCPv6 DDNS registration with FQDN
On Fri, 2015-02-06 at 10:39 +0100, Alexander Groß wrote:
On Thu, Feb 5, 2015 at 1:02 AM, Dan Williams d...@redhat.com wrote:
The question is why it was done that way
originally, which I haven't looked into yet but will do.
The commit that added the code is 90b995. It hasn't been change since.
Can you rebuild with the attached patch and see if that makes things
work for you? If so I'll go ahead and commit it, and backport to 0.9.10
and 1.0.
Thanks!
Dan
dhclient only supports fqdn.fqdn for server DDNS updates with
DHCPv6. And even though the underlying DHCP options that fqdn.fqdn
controls allow non-qualified hostnames on the wire, dhclient does
not. So we must require a fully-qualified name for DHCPv6.
Second, while no-client-updates seems like it should be off, doing
that apparently makes dhclient set the O flag to 1 which appears to
be a bug, and results in the server not doing the DDNS update. So
we must stop setting that option too.
Found by: Alexander Groß
---
src/dhcp-manager/nm-dhcp-dhclient-utils.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/src/dhcp-manager/nm-dhcp-dhclient-utils.c
b/src/dhcp-manager/nm-dhcp-dhclient-utils.c
index 46e8e0b..54381a0 100644
--- a/src/dhcp-manager/nm-dhcp-dhclient-utils.c
+++ b/src/dhcp-manager/nm-dhcp-dhclient-utils.c
@@ -39,8 +39,8 @@
#define HOSTNAME4_TAGsend host-name
#define HOSTNAME4_FORMAT HOSTNAME4_TAG \%s\; # added by NetworkManager
-#define HOSTNAME6_TAGsend fqdn.fqdn
-#define HOSTNAME6_FORMAT HOSTNAME6_TAG \%s\; # added by NetworkManager
+#define FQDN_TAGsend fqdn.fqdn
+#define FQDN_FORMAT FQDN_TAG \%s\; # added by NetworkManager
#define ALSOREQ_TAG also request
@@ -57,7 +57,7 @@ add_also_request (GPtrArray *array, const char *item)
}
static void
-add_hostname (GString *str, const char *format, const char *hostname)
+add_hostname4 (GString *str, const char *format, const char *hostname)
{
char *plain_hostname, *dot;
@@ -109,7 +109,7 @@ add_ip4_config (GString *str, GBytes *client_id, const char
*hostname)
g_string_append (str, ; # added by NetworkManager\n);
}
- add_hostname (str, HOSTNAME4_FORMAT \n, hostname);
+ add_hostname4 (str, HOSTNAME4_FORMAT \n, hostname);
g_string_append_c (str, '\n');
@@ -125,13 +125,17 @@ add_ip4_config (GString *str, GBytes *client_id, const
char *hostname)
}
static void
-add_ip6_config (GString *str, const char *hostname)
+add_hostname6 (GString *str, const char *hostname)
{
- add_hostname (str, HOSTNAME6_FORMAT \n, hostname);
- g_string_append (str,
-send fqdn.encoded on;\n
-send fqdn.no-client-update on;\n
-send fqdn.server-update on;\n);
+ /* dhclient only supports the fqdn.fqdn for DHCPv6 and requires a fully-
+* qualified name for this option, so we must require one here too.
+*/
+ if (hostname strchr (hostname, '.')) {
+ g_string_append_printf (str, FQDN_FORMAT \n, hostname);
+ g_string_append (str,
+send fqdn.encoded on;\n
+send fqdn.server-update on;\n);
+ }
}
static GBytes *
@@ -232,7 +236,7 @@ nm_dhcp_dhclient_create_config (const char *interface,
if (hostname) {
if (strncmp (p, HOSTNAME4_TAG, strlen
(HOSTNAME4_TAG)) == 0)
continue;
- if (strncmp (p, HOSTNAME6_TAG, strlen
(HOSTNAME6_TAG)) == 0)
+ if (strncmp (p, FQDN_TAG, strlen (FQDN_TAG)) ==
0)
continue;
}
@@ -290,7 +294,7 @@ nm_dhcp_dhclient_create_config (const char *interface,
g_string_append_c (new_contents, '\n');
if (is_ip6) {
- add_ip6_config (new_contents, hostname);
+ add_hostname6 (new_contents, hostname);
add_also_request (alsoreq, dhcp6.name-servers);
add_also_request (alsoreq, dhcp6.domain-search);
add_also_request (alsoreq, dhcp6.client-id);
--
2.1.0
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] wwan: don't assume DNS info is always available
On Tue, 2015-02-17 at 17:20 +0100, Aleksander Morgado wrote:
Fixes segfault with e.g. Ericsson modems that reply just with IP+gateway,
without DNS info.
Thanks, made a small change (reduced the patch to for (i = 0; dns
dns[i]...) and pushed to 0.9.10, 1.0, and git master.
Dan
[mm-port-serial-at.c:440] debug_log(): (ttyACM8): -- 'AT*E2IPCFG?CR'
[mm-port-serial-at.c:440] debug_log(): (ttyACM8): -- 'CRLF*E2IPCFG:
(1,10.191.64.12)(2,10.191.64.10)CRLF'
[mm-port-serial-at.c:440] debug_log(): (ttyACM8): -- 'CRLFOKCRLF'
[mm-port-serial.c:1296] mm_port_serial_close(): (ttyACM8) device open count
is 1 (close)
[mm-port.c:95] mm_port_set_connected(): (wwan0): port now connected
[mm-base-bearer.c:488] connect_ready(): Connected bearer
'/org/freedesktop/ModemManager1/Bearer/0'
[mm-iface-modem.c:1392] __iface_modem_update_state_internal(): Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (connecting -
connected)
info Activation (ttyACM8) Stage 3 of 5 (IP Configure Start) started...
info (ttyACM8): device state change: config - ip-config (reason 'none')
[50 70 0]
info Activation (ttyACM8) Stage 4 of 5 (IPv6 Configure Timeout)
scheduled...
info Activation (ttyACM8) Stage 3 of 5 (IP Configure Start) complete.
info (ttyACM8): IPv4 static configuration:
info address 10.191.64.12/28
info gateway 10.191.64.10
Errore di segmentazione
http://lists.freedesktop.org/archives/modemmanager-devel/2015-February/001758.html
---
src/devices/wwan/nm-modem-broadband.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/devices/wwan/nm-modem-broadband.c
b/src/devices/wwan/nm-modem-broadband.c
index 97d05ee..696c43a 100644
--- a/src/devices/wwan/nm-modem-broadband.c
+++ b/src/devices/wwan/nm-modem-broadband.c
@@ -708,11 +708,13 @@ static_stage3_ip4_done (NMModemBroadband *self)
/* DNS servers */
dns = mm_bearer_ip_config_get_dns (self-priv-ipv4_config);
- for (i = 0; dns[i]; i++) {
- if ( ip4_string_to_num (dns[i], address_network)
- address_network 0) {
- nm_ip4_config_add_nameserver (config, address_network);
- nm_log_info (LOGD_MB, DNS %s, dns[i]);
+ if (dns) {
+ for (i = 0; dns[i]; i++) {
+ if ( ip4_string_to_num (dns[i], address_network)
+ address_network 0) {
+ nm_ip4_config_add_nameserver (config,
address_network);
+ nm_log_info (LOGD_MB, DNS %s, dns[i]);
+ }
}
}
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: is anyone actually still using WiMAX
On Tue, 2015-02-10 at 09:53 -0500, Dan Winship wrote: While taking cheap potshots at WiMAX during devconf.cz, we started wonder whether anyone would care (or even notice) if we dropped support for it in NM 1.2, given that: - WiMAX seems to be a dying technology - the Intel WiMAX driver for Linux has never worked very well, and the SDK appears to no longer be supported - NM's WiMAX support requires a hacked up version of the Intel WiMAX SDK that supports libnl3, which exists only in a git repository whose location has never been terribly well advertised, suggesting most distros probably don't build it anyway. - Fedora dropped it a few releases back and there was no uproar Of course this would not affect people using WiMAX via external hotspots (assuming such people and hotspots still exist). Side note: here in the US, Clear/Sprint (the only national WiMAX provider) will be shutting down their WiMAX network in June 2015 and transitioning the spectrum over to TDD-LTE. Yota in Russia moved to TDD-LTE in 2013, and I think the only major networks left are UQ in Taiwan/Japan and KT in South Korea... Also, Intel devices are the only ones supported by NM right now, and they haven't made the hardware or updated drivers since 2012. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [review] dcbw/0910-memleaks
On Tue, 2015-02-10 at 15:44 +0100, Lubomir Rintel wrote: On Tue, 2015-02-10 at 15:10 +0100, Dan Williams wrote: Hi, Review request for this; most are cherry-picks (with fixup) for thaller's git master memleak fixes. Anything that has my commit authorship is new though and should get a look. It allows valgrind-enabled 'make check' to pass on 0.9.10. Looks good to me. Passed a compile-check with Werror too. Thanks, merged to nm-0-9-10. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
On Thu, 2015-01-29 at 10:24 -0500, Jeremy Moles wrote: On 01/28/2015 01:23 PM, Dan Williams wrote: On Wed, 2015-01-28 at 11:43 -0500, Jeremy Moles wrote: On 01/12/2015 12:50 PM, Dan Williams wrote: On Mon, 2015-01-12 at 12:44 -0500, Jeremy Moles wrote: On 01/12/2015 12:42 PM, Dan Williams wrote: On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote: On 01/12/2015 12:34 PM, Dan Williams wrote: On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: On 01/12/2015 10:46 AM, Dan Williams wrote: On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the config (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different port numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for powering on a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: For the time being, I can only provide the information with the machine being directly booted into Linux. When I have additional access later today, I will provide the results of these commands after having booted into Windows first. For now, however, read on... # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images error: couldn't list stored images: QMI protocol error (71): 'InvalidQmiCommand' # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' # qmicli -d /dev/cdc-wdm0 --dms-lget-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26' qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility
[review] dcbw/0910-memleaks
Hi, Review request for this; most are cherry-picks (with fixup) for thaller's git master memleak fixes. Anything that has my commit authorship is new though and should get a look. It allows valgrind-enabled 'make check' to pass on 0.9.10. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager 1.2 planning process
Hi, DanW, thaller, jklimes, lrintel and I have gone through a big list of things we need to work on, things we'd like to work on, thinks we'd love to have but may not have time to work on, etc, and put it all up here. It's not set in stone but a starting point for the 1.2 cycle: https://wiki.gnome.org/Projects/NetworkManager/12FeaturesPlanning If anyone has suggestions, questions, wants things clarified, things they would like to claim or work on, lets start that discussion here. What do you think? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
On Tue, 2015-02-03 at 23:15 +0100, Ferry Toth wrote: On my home wifi network I have 1 2.4GHz and 1 5GHz AP (is actually 1 fritz box). With one machine (chromebook running kubuntu 14.10 and AR9462 abgn wifi) When automatically reconnecting to 5GHz after resume half of the time the connection fails and retries indefinitely. It seems to fail more when moving the laptop to another location in house while it sleeps (so the list of visible networks actually changes). When this happens it is almost impossible to reconnect manually. (what works sometimes is disconnecting the connection that is building, disable the wifi, enable again, wait a bit then manually connect to the other (2.4GHz) AP) Strangely: disabling autoconnect on resume and then manually connecting always works. Other strange thing: Another machine (NUC with intel wifi and same kubuntu 14.10) always works. To me, it seems to be some interference between rescanning and connecting. I have no idea what is the difference in the state machine when autoconnecting vs. manual. I've provided log's on bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=726121 I updated the bug with some thoughts after looking at the logs. It looks to me like the issues are exclusively driver and/or supplicant problems. In the failed automatic log, the access point and the device don't agree on state, so the access point rejects the device. That starts a reconnect attempt which then apparently fails at the driver level because the AP never responds to teh driver's association attempts. Later on, the supplicant enters the scanning state but has to time that out because the driver never notifies the supplicant that the scan has finished. Even later, the supplicant screws up by trying to associate with 00:00:00:00:00:00 and then it simply falls over. One thing you could do is try to set up a resume-time script that just does 'rmmod ath9k; modprobe ath9k' and see if that fixes most of your issues; if so then it's usually an indication of driver bugs. Given that iwlwifi works fine on the machine, I think the issues are specific to the ath9k driver, and not the mac80211 stack (which iwlwifi also uses). Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCPv6 DDNS registration with FQDN
On Tue, 2015-02-03 at 12:05 +0100, Alexander Groß wrote: I have some more findings after several debugging sessions. According to RFC 4704, section 4.2 https://tools.ietf.org/html/rfc4704#section-4.2: The Domain Name part of the option carries all or part of the FQDN of a DHCPv6 client. ... A client MAY be configured with a fully qualified domain name or with a partial name that is not fully qualified. ... To send a fully qualified domain name, the Domain Name field is set to the DNS-encoded domain name including the terminating zero-length label. To send a partial name, the Domain Name field is set to the DNS-encoded domain name without the terminating zero-length label. According to this, Windows clients send a partial host name, e.g. FOO, without a terminating NULL character. dhclient, on the other hand, always sends a FQDN including the terminating NULL making the value fully qualified. I found a possibly unrelated discussion about this issue here: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1088682 As such, send fqdn.fqdn foo.example.local. must always be a fully qualified domain name (as NULL is automatically appended), otherwise the DDNS update won't happen in the correct DNS zone. Any idea how to achieve that given that NM always overwrites fqdn.fqdn values found in custom (merged) dhclient6.confs? http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dhcp-manager/nm-dhcp-dhclient-utils.c#n232 So the short answer here is, you're right, NM is doing some wrong stuff with the DHCPv6 hostname. It is chopping off the FQDN when using dhclient, and that's likely a mis-interpretation of how the dhclient config was supposed to work. The question is why it was done that way originally, which I haven't looked into yet but will do. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux
On Wed, 2015-02-04 at 00:47 +0100, poma wrote: On 03.02.2015 18:43, David Herrmann wrote: Hi On Tue, Feb 3, 2015 at 6:36 PM, poma pomidorabelis...@gmail.com wrote: On 02.02.2015 19:58, David Herrmann wrote: As I'm not really interested in hacking on network-managers, I've decided to stop working on MiracleCast. If, some day, there's a working P2P stack on linux, I might resurrect it. But it sounds more likely that I'll refer to the Intel solution (WYSIWIDI) instead. There're also gstreamer plugins for WFD now, so maybe give them a try? gst-rtsp-server-wfd https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md Pre-conditions: This module is running on established p2p connection with wifi direct, which means that you have to setup this network environment to run this module. I hope this link would be very helpful. ( http://cgit.freedesktop.org/~dvdhrm/miracle ) You are referring to them, they are referring to you. :) They provide a gstreamer plugin for Miracast, but quite frankly didn't bother hacking on Wifi P2P. Hence, they refer to my miracle-wifid hack to provide a P2P link. If NM provides a P2P API, you can just set it up via nmcli and then use the gst modules to run Miracast (or you can just use the ConnMan API right now). Thanks David Well at least there is an open RFE - Network Manager [enh] Add support for WiFi P2P (aka WiFi Direct) https://bugzilla.gnome.org/show_bug.cgi?id=734073 And in this thread I see Patrik Flykt - ConnMan. Connman WiFi p2p API evaluation https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00018.html Let's see if NetworkMan can learn from ConnMan. :) Of course it can learn something :) We'd rather have NetworkManager share an API with ConnMan here instead of needlessly re-inventing the wheel. I think we came to quasi-agreement in the mail thread you link to, but need to write up a final spec and get agreement from Patrik. This might also be a good project for a community member to help out with too. So if anyone is interested in the NetworkManager side of P2P/Direct (and I know some are) please raise your hand! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: applet: clear notification actions before adding new ones
On Mon, 2015-01-26 at 17:51 -0500, Mathieu Trudel-Lapierre wrote:
Make sure we only ever have one of the Don't show this again button that
will trigger disabling notifications. Otherwise we end up with multiple
instances of the same button in notifications because one gets added every
time a new notification stacks on top of an existing one.
Thanks! Pushed to 0.9.10, 1.0, and git master.
Dan
---
src/applet.c |1 +
1 file changed, 1 insertion(+)
Index: b/src/applet.c
===
--- a/src/applet.c
+++ b/src/applet.c
@@ -924,6 +924,7 @@ applet_do_notify (NMApplet *applet,
notify_notification_set_timeout (notify, NOTIFY_EXPIRES_DEFAULT);
if (applet_notify_server_has_actions () action1) {
+ notify_notification_clear_actions (notify);
notify_notification_add_action (notify, action1, action1_label,
action1_cb, action1_user_data,
NULL);
}
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
On Thu, 2015-01-29 at 10:24 -0500, Jeremy Moles wrote: On 01/28/2015 01:23 PM, Dan Williams wrote: On Wed, 2015-01-28 at 11:43 -0500, Jeremy Moles wrote: On 01/12/2015 12:50 PM, Dan Williams wrote: On Mon, 2015-01-12 at 12:44 -0500, Jeremy Moles wrote: On 01/12/2015 12:42 PM, Dan Williams wrote: On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote: On 01/12/2015 12:34 PM, Dan Williams wrote: On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: On 01/12/2015 10:46 AM, Dan Williams wrote: On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the config (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different port numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for powering on a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: For the time being, I can only provide the information with the machine being directly booted into Linux. When I have additional access later today, I will provide the results of these commands after having booted into Windows first. For now, however, read on... # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images error: couldn't list stored images: QMI protocol error (71): 'InvalidQmiCommand' # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' # qmicli -d /dev/cdc-wdm0 --dms-lget-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26' qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility
Re: Gobi 3000 (1199:901F)
On Wed, 2015-01-28 at 11:43 -0500, Jeremy Moles wrote: On 01/12/2015 12:50 PM, Dan Williams wrote: On Mon, 2015-01-12 at 12:44 -0500, Jeremy Moles wrote: On 01/12/2015 12:42 PM, Dan Williams wrote: On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote: On 01/12/2015 12:34 PM, Dan Williams wrote: On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: On 01/12/2015 10:46 AM, Dan Williams wrote: On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the config (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different port numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for powering on a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: For the time being, I can only provide the information with the machine being directly booted into Linux. When I have additional access later today, I will provide the results of these commands after having booted into Windows first. For now, however, read on... # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images error: couldn't list stored images: QMI protocol error (71): 'InvalidQmiCommand' # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' # qmicli -d /dev/cdc-wdm0 --dms-lget-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26' qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility is that the machine's rfkill handling isn't known to Linux, but since Windows knows, when you warm-boot to Linux the WWAN
Re: Add WPS information parsing in foreach_property_cb
On Sun, 2015-01-25 at 21:36 +0800, Awk Jiang wrote: Hi all, I start working on adding WPS function into NM. At the beginning, I add the WPS information during foreach_property_cb as the patch. Because I am foreign to contribute code in community, please feel free to give me any suggestion. Thanks. This looks good, thanks! Do you need/want some pointers on where to go from here? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 0.9.10.1 (0.9.10.2-rc1) testing release
Hi, It's past time for a bug-fix release for NetworkManager 0.9.10, so here's a testing release candidate. Please help test if you're using 0.9.10 already, so that we can get the release out next week. There are a ton of fixes, many already cherry-picked by distros, but many new ones as well. Lets make it solid! https://download.gnome.org/sources/NetworkManager/0.9/NetworkManager-0.9.10.1.tar.xz https://download.gnome.org/sources/network-manager-applet/0.9/network-manager-applet-0.9.10.1.tar.xz Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: outdated version requirements in libnm-gtk.pc.in
On Thu, 2015-01-22 at 15:55 +0100, Michael Biebl wrote:
Hi,
had a look at nm-applet 1.0.0, specifically src/libnm-gtk/libnm-gtk.pc.in.
It contains
nmversion=0.8.998
Requires: NetworkManager = ${nmversion} libnm-util = ${nmversion}
libnm-glib = ${nmversion} gtk+-3.0 = 2.91.4
That nmversion looks outdated, so does the gtk version.
Would be great if those version requirements could be updated.
Done in git master and nma-1-0.
Dan
Btw, is there a libnm port of nm-applet planned?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: automake warnings about option 'subdir-objects' is disabled
On Thu, 2015-01-22 at 16:03 +0100, Michael Biebl wrote: Hi, during build, I get the following warning: automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. clients/cli/Makefile.am:49: warning: source file '$(srcdir)/../common/nm-polkit-listener.c' is in a subdirectory, clients/cli/Makefile.am:49: but option 'subdir-objects' is disabled clients/tui/Makefile.am:35: warning: source file '$(srcdir)/../common/nm-secret-agent-simple.c' is in a subdirectory, ... I get that too with subdir-objects and automake 1.13.4. Maybe it's related to http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928 ? If so, then we can't use subdir-objects until automake 1.16... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Not sure on confirmation
On Mon, 2015-01-19 at 18:01 -0800, Garrison Ricketson wrote: Hello , I just joined the mailinglist and am not sure if it confirmed all right. My reason for joining the list is I have some problem with network manager,not working. I will explain the details, if and when I am actually on the list. I see the mail, I think you're subscribed. Welcome! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unavailable, managed device.
On Tue, 2015-01-20 at 10:16 +0100, Léo Peltier wrote: $ rfkill list 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no There is no wpa_supplicant running. So that would be the issue. NetworkManager tries to start the supplicant via D-Bus service actiavation if it's not already running, so either there's an issue with D-Bus service activation, or you're running systemd and you have the supplicant masked, or you could just try making sure the supplicant is running when NM starts and ensure that it's launched with the -u option. Does that make things work? Dan On 01/19/2015 08:30 PM, Dan Williams wrote: Some quick things that I can think of: 1) rfkill - what does 'rfkill list' say? 2) wpa_supplicant - is the supplicant running, and was it spawned with the -u option? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unavailable, managed device.
On Mon, 2015-01-19 at 16:40 +0100, Léo Peltier wrote: Hi, I currently trying to get NM to handle a virtual wlan device and can't get it to work. Its the second connection of an Intel 7260, the first one being used as an access point managed outside of NM. The OS is an Ubuntu Server 12.04 running NM 0.9.4.0-0ubuntu4.4.1 uname: 3.13.0-43-generic #72~precise1-Ubuntu SMP i686 i386 When I do everything manually through ip/iw/iwlist everything works fine but I now need to integrate it with the rest of our software that handles the network configuration using NM via DBus. Some quick things that I can think of: 1) rfkill - what does 'rfkill list' say? 2) wpa_supplicant - is the supplicant running, and was it spawned with the -u option? Dan I create the iface using the following command: iw dev wlan0 interface add wlan1 type station Here's what NM gives me: $ nmcli dev list iface wlan1 GENERAL.DEVICE: wlan1 GENERAL.TYPE: 802-11-wireless GENERAL.VENDOR: Intel Corporation GENERAL.PRODUCT:Wireless 7260 GENERAL.DRIVER: iwlwifi GENERAL.HWADDR: F8:16:54:55:A5:9C GENERAL.STATE: 20 (unavailable) GENERAL.REASON: 2 (Device is now managed) GENERAL.UDI: /sys/devices/pci:00/:00:1c.5/:02:00.0/net/wlan1 GENERAL.IP-IFACE: GENERAL.NM-MANAGED: yes GENERAL.FIRMWARE-MISSING: no GENERAL.CONNECTION: not connected CAPABILITIES.CARRIER-DETECT:no CAPABILITIES.SPEED: unknown WIFI-PROPERTIES.WEP:yes WIFI-PROPERTIES.WPA:yes WIFI-PROPERTIES.WPA2: yes WIFI-PROPERTIES.TKIP: yes WIFI-PROPERTIES.CCMP: yes Syslog: info (wlan1): using nl80211 for WiFi device control warn (wlan1): driver supports Access Point (AP) mode info (wlan1): new 802.11 WiFi device (driver: 'iwlwifi' ifindex: 28) info (wlan1): exported as /org/freedesktop/NetworkManager/Devices/4 info (wlan1): now managed info (wlan1): device state change: unmanaged - unavailable (reason 'managed') [10 20 2] info (wlan1): bringing up device. info (wlan1): preparing device. info (wlan1): deactivating device (reason 'managed') [2] I have [ifupdown] managed=false in my NetworkManager.conf and wlan1 does not appear in `/etc/network/interfaces`. Nothing is disabled in `/var/lib/NetworkManager/NetworkManager.state`. Can someone point me the right direction to get out of this unavailable state? Thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the config (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different port numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for powering on a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility is that the machine's rfkill handling isn't known to Linux, but since Windows knows, when you warm-boot to Linux the WWAN rfkill is disabled. What model laptop is this? (if it's a laptop) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Aw: Re: Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root?
On Sat, 2015-01-10 at 14:12 +0100, Thomas Schneider wrote: Hi! I checked if this could be related to pklocalauthority that is documented here (http://www.freedesktop.org/software/polkit/docs/0.105/pklocalauthority.8.html) Checking the relevant config file for NetworkManager looks good to me. But it's not clear why manfred cannot utilize NetworkManager as he belongs to group netdev. user@pc1-asus:~$ sudo cat /var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.NetworkManager.pkla [Adding or changing system-wide NetworkManager connections] Identity=unix-group:netdev;unix-group:sudo Action=org.freedesktop.NetworkManager.settings.modify.system ResultAny=no ResultInactive=no ResultActive=yes user@pc1-asus:~$ id manfred uid=1005(manfred) gid=1005(manfred) Gruppen=1005(manfred),117(netdev),1013(verwandte),126(tbb),127(openvpn),128(fcron) Try this: pkaction -v -a org.freedesktop.NetworkManager.settings.modify.system What do you get when running this as the user 'manfred'? Also when you do this, please grab the results of 'loginctl show-session X' where X is the session for 'manfred'. I know you sent the mail to me private with this output, but I want to make sure that loginctl and pkaction output is from the same run. Thanks! Dan Should I now go with the new compilation of NetworkManager using --with-session-tracking=[ck|systemd]? Is there a way to identify which options have been used with the packaged shipped by the distribution? THX Gesendet: Freitag, 09. Januar 2015 um 23:13 Uhr Von: Dan Williams d...@redhat.com An: Thomas Schneider c.mo...@web.de Cc: poma pomidorabelis...@gmail.com, networkmanager-list@gnome.org Betreff: Re: Aw: Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root? On Fri, 2015-01-09 at 20:49 +0100, Thomas Schneider wrote: Hi, here's an update on your questions Let's start with the version of nmcli: user@pc1-asus:~$ nmcli -v nmcli-Werkzeug, Version 0.9.10.0 Now permissions: user@pc1-asus:~$ nmcli general permissions BEFUGNIS WERT org.freedesktop.NetworkManager.enable-disable-network nein Ok, this indicates that PolicyKit is denying the permissions to these users. The most likely reason is that NM has been built with --with-session-tracking=[ck|systemd] and something is not properly setting up the login sessions with ConsoleKit or systemd. PolicyKit has a concept of active (eg, using the computer right now) and inactive (idle or non-human users) sessions. NetworkManager uses these for fast-user-switching and some permissions control. It's likely that all users on your machine are considered inactive according to PolicyKit and thus being denied. What do you get for the following commands? ck-list-sessions loginctl loginctl show-session X (repeat for all sessions from 'loginctl') if you're using ConsoleKit, your session manager needs to tell ConsoleKit that it's starting a new session. I'm not quite sure how that happens with systemd, but it does somehow. Alternatively, if you don't care about user permissions and want to allow any user to control networking you can build NM with --with-session-tracking=none and --with-polkit=no to disable this functionality. Dan org.freedesktop.NetworkManager.enable-disable-wifi nein org.freedesktop.NetworkManager.enable-disable-wwan nein org.freedesktop.NetworkManager.enable-disable-wimax nein org.freedesktop.NetworkManager.sleep-wake nein org.freedesktop.NetworkManager.network-control nein org.freedesktop.NetworkManager.wifi.share.protected nein org.freedesktop.NetworkManager.wifi.share.open nein org.freedesktop.NetworkManager.settings.modify.system nein org.freedesktop.NetworkManager.settings.modify.own Legitimierung org.freedesktop.NetworkManager.settings.modify.hostname Legitimierung Output when running nm-applet w/o root permission: user@pc1-asus:~$ nm-applet (nm-applet:1167): libnm-glib-CRITICAL **: nm_secret_agent_register: assertion 'priv-registered == FALSE' failed (nm-applet:1167): nm-applet-WARNING **: VPN Connection activation failed: (org.freedesktop.NetworkManager.PermissionDenied) Not authorized to control networking. Error message in /var/log/syslog: Jan 9 20:41:34 pc1-asus NetworkManager[5393]: warn Failed to activate 'Netzwerk-Thomas-VPN': Not authorized to control networking. The current config file for the required VPN connection is: user@pc1-asus:~$ sudo cat /etc/NetworkManager/system-connections/VPN [connection] id=VPN uuid=a6ae2fac-4776-4f74-962c-a63113xx type=vpn permissions=user:user:; autoconnect=false [vpn] service-type=org.freedesktop.NetworkManager.openvpn connection-type=tls auth=SHA256 remote=mydyndns cipher=AES-256-CBC comp-lzo=yes tunnel-mtu=1500 cert-pass-flags=1 cert=/etc/openvpn/config/server.crt ca=/etc/openvpn/config/server.pem key
Re: Gobi 3000 (1199:901F)
On Mon, 2015-01-12 at 12:44 -0500, Jeremy Moles wrote: On 01/12/2015 12:42 PM, Dan Williams wrote: On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote: On 01/12/2015 12:34 PM, Dan Williams wrote: On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: On 01/12/2015 10:46 AM, Dan Williams wrote: On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the config (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different port numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for powering on a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: For the time being, I can only provide the information with the machine being directly booted into Linux. When I have additional access later today, I will provide the results of these commands after having booted into Windows first. For now, however, read on... # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images error: couldn't list stored images: QMI protocol error (71): 'InvalidQmiCommand' # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' # qmicli -d /dev/cdc-wdm0 --dms-lget-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26' qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility is that the machine's rfkill handling isn't known to Linux, but since Windows knows, when you warm-boot to Linux the WWAN rfkill is disabled. What model laptop is this? (if it's a laptop) This is a Lenovo W540 with the Gobi 5000 Lenovo-certified card installed. Under
Re: Gobi 3000 (1199:901F)
On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: On 01/12/2015 10:46 AM, Dan Williams wrote: On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the config (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different port numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for powering on a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: For the time being, I can only provide the information with the machine being directly booted into Linux. When I have additional access later today, I will provide the results of these commands after having booted into Windows first. For now, however, read on... # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images error: couldn't list stored images: QMI protocol error (71): 'InvalidQmiCommand' # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' # qmicli -d /dev/cdc-wdm0 --dms-lget-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26' qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility is that the machine's rfkill handling isn't known to Linux, but since Windows knows, when you warm-boot to Linux the WWAN rfkill is disabled. What model laptop is this? (if it's a laptop) This is a Lenovo W540 with the Gobi 5000 Lenovo-certified card installed. Under Linux, can you use 'sudo minicom -D /dev/ttyUSBx' where x is the number of each of the USB serial ports, and run at!pcinfo on each one in turn? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org
Re: Gobi 3000 (1199:901F)
On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote: On 01/12/2015 12:34 PM, Dan Williams wrote: On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: On 01/12/2015 10:46 AM, Dan Williams wrote: On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the config (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different port numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for powering on a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: For the time being, I can only provide the information with the machine being directly booted into Linux. When I have additional access later today, I will provide the results of these commands after having booted into Windows first. For now, however, read on... # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images error: couldn't list stored images: QMI protocol error (71): 'InvalidQmiCommand' # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' # qmicli -d /dev/cdc-wdm0 --dms-lget-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26' qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility is that the machine's rfkill handling isn't known to Linux, but since Windows knows, when you warm-boot to Linux the WWAN rfkill is disabled. What model laptop is this? (if it's a laptop) This is a Lenovo W540 with the Gobi 5000 Lenovo-certified card installed. Under Linux, can you use 'sudo minicom -D /dev/ttyUSBx' where x is the number of each of the USB serial ports, and run at!pcinfo on each one
Re: Connman WiFi p2p API evaluation
On Fri, 2015-01-09 at 19:01 +0100, Bastien Nocera wrote: On Thu, 2015-01-08 at 16:04 -0600, Dan Williams wrote: Hi, Thomas asked me to look at the Connman P2P/Direct APIs to see if we can share some of the interfaces. I think that's a worthwhile goal, so here's a short writeup of where the APIs stand WRT to NetworkManager's current D-Bus API. Quick question. Would the support in NM require the P2P support in the driver being handled by cfg80211? Yes. WEXT has no capabilities to handle P2P, if that's what you're asking. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the config (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different port numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for powering on a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How Embedded is NetworkManager
On Fri, 2015-01-09 at 17:45 +, Richard Willis wrote: I'm posting this question first just to ascertain if using NetworkManager is possible in the embedded project I am working on. This project uses multiple networking interfaces (Eth, WiFi, GSM-Radio, Bluetooth) but runs as a headless black box, gathering telemetry information and providing some gateway support. NetworkManager would be a very good fit for this device, but I am concerned that NetworkManager may have link dependencies for GUI support, something the product does not have. I'm interesting in hearing if anyone has tried running NetworkManager without any GUI.. is it possible? FYI, product is similar to a BeagleBone Black.. OS is a variant of Yocto, but we can run Debian Wheezy for initial experimentations. In addition to the other replies, if you want to build for a single-user embedded system, there are some configure-time options you might want: --with-session-tracking=none (don't require consolekit or systemd) --with-suspend-resume=upower (don't require systemd) --with-selinux=no (don't require libselinux) --enable-teamdctl=no (don't use libteam) --enable-polkit=no (don't use PolicyKit) --with-libsoup=no (don't do connectivity checking) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Aw: Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root?
On Fri, 2015-01-09 at 20:49 +0100, Thomas Schneider wrote: Hi, here's an update on your questions Let's start with the version of nmcli: user@pc1-asus:~$ nmcli -v nmcli-Werkzeug, Version 0.9.10.0 Now permissions: user@pc1-asus:~$ nmcli general permissions BEFUGNIS WERT org.freedesktop.NetworkManager.enable-disable-networknein Ok, this indicates that PolicyKit is denying the permissions to these users. The most likely reason is that NM has been built with --with-session-tracking=[ck|systemd] and something is not properly setting up the login sessions with ConsoleKit or systemd. PolicyKit has a concept of active (eg, using the computer right now) and inactive (idle or non-human users) sessions. NetworkManager uses these for fast-user-switching and some permissions control. It's likely that all users on your machine are considered inactive according to PolicyKit and thus being denied. What do you get for the following commands? ck-list-sessions loginctl loginctl show-session X (repeat for all sessions from 'loginctl') if you're using ConsoleKit, your session manager needs to tell ConsoleKit that it's starting a new session. I'm not quite sure how that happens with systemd, but it does somehow. Alternatively, if you don't care about user permissions and want to allow any user to control networking you can build NM with --with-session-tracking=none and --with-polkit=no to disable this functionality. Dan org.freedesktop.NetworkManager.enable-disable-wifi nein org.freedesktop.NetworkManager.enable-disable-wwan nein org.freedesktop.NetworkManager.enable-disable-wimax nein org.freedesktop.NetworkManager.sleep-wakenein org.freedesktop.NetworkManager.network-control nein org.freedesktop.NetworkManager.wifi.share.protected nein org.freedesktop.NetworkManager.wifi.share.open nein org.freedesktop.NetworkManager.settings.modify.systemnein org.freedesktop.NetworkManager.settings.modify.own Legitimierung org.freedesktop.NetworkManager.settings.modify.hostname Legitimierung Output when running nm-applet w/o root permission: user@pc1-asus:~$ nm-applet (nm-applet:1167): libnm-glib-CRITICAL **: nm_secret_agent_register: assertion 'priv-registered == FALSE' failed (nm-applet:1167): nm-applet-WARNING **: VPN Connection activation failed: (org.freedesktop.NetworkManager.PermissionDenied) Not authorized to control networking. Error message in /var/log/syslog: Jan 9 20:41:34 pc1-asus NetworkManager[5393]: warn Failed to activate 'Netzwerk-Thomas-VPN': Not authorized to control networking. The current config file for the required VPN connection is: user@pc1-asus:~$ sudo cat /etc/NetworkManager/system-connections/VPN [connection] id=VPN uuid=a6ae2fac-4776-4f74-962c-a63113xx type=vpn permissions=user:user:; autoconnect=false [vpn] service-type=org.freedesktop.NetworkManager.openvpn connection-type=tls auth=SHA256 remote=mydyndns cipher=AES-256-CBC comp-lzo=yes tunnel-mtu=1500 cert-pass-flags=1 cert=/etc/openvpn/config/server.crt ca=/etc/openvpn/config/server.pem key=/etc/openvpn/config/server.key ta=/etc/openvpn/config/ta.key [ipv6] method=auto ip6-privacy=0 [ipv4] method=auto This config file works perfectly when calling sudo nmcli. I have identified that any user without root permission can utilize NetworkManager and ncmli respectively. In other words, the user needs to be member and run any command with sudo. This is also true for using any device connected via USB, e.g. scanner or USB memory stick. THX Gesendet: Donnerstag, 08. Januar 2015 um 17:39 Uhr Von: Dan Williams d...@redhat.com An: poma pomidorabelis...@gmail.com Cc: Thomas Schneider c.mo...@web.de, networkmanager-list@gnome.org Betreff: Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root? On Wed, 2015-01-07 at 23:42 +0100, poma wrote: On 07.01.2015 18:29, Dan Williams wrote: On Mon, 2015-01-05 at 19:14 +0100, Thomas Schneider wrote: Hello! I have installed latest version of NetworkManager and nmcli respectively + OpenVPN plugin or NetworkManager. user@pc1-asus:~$ apt-cache policy network-manager network-manager: Installiert: 0.9.10.0-5 Installationskandidat: 0.9.10.0-5 Versionstabelle: *** 0.9.10.0-5 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status user@pc1-asus:~$ apt-cache policy network-manager-gnome network-manager-gnome: Installiert: 0.9.10.0-2 Installationskandidat: 0.9.10.0-2 Versionstabelle: *** 0.9.10.0-2 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status user@pc1-asus:~$ apt-cache policy network-manager-openvpn network-manager-openvpn: Installiert: 0.9.10.0-1 Installationskandidat
Re: Connman WiFi p2p API evaluation
On Fri, 2015-01-09 at 22:58 +0100, Bastien Nocera wrote: Vendor WEXT extensions do have that capability though (I recently ripped out that vendor support in a Realtek driver). NM's implementation would be via wpa_supplicant, and I'm 110% sure that the supplicant will never support P2P through the WEXT driver :) So in the end, yeah, it'll be nl80211/cfg80211 only. Dan On 9 Jan 2015, at 20:25, Dan Williams d...@redhat.com wrote: On Fri, 2015-01-09 at 19:01 +0100, Bastien Nocera wrote: On Thu, 2015-01-08 at 16:04 -0600, Dan Williams wrote: Hi, Thomas asked me to look at the Connman P2P/Direct APIs to see if we can share some of the interfaces. I think that's a worthwhile goal, so here's a short writeup of where the APIs stand WRT to NetworkManager's current D-Bus API. Quick question. Would the support in NM require the P2P support in the driver being handled by cfg80211? Yes. WEXT has no capabilities to handle P2P, if that's what you're asking. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Connman WiFi p2p API evaluation
Hi, Thomas asked me to look at the Connman P2P/Direct APIs to see if we can share some of the interfaces. I think that's a worthwhile goal, so here's a short writeup of where the APIs stand WRT to NetworkManager's current D-Bus API. doc/wifi-p2p-overview.txt doc/technology-api.txt doc/peer-api.txt The largest issue is that all the interfaces start with net.connman. If we're going to coordinate on API we should grab some neutral suffix to org.freedeskop. instead. The second issue is that the APIs have some property-related things that aren't org.fdo.DBus.Properties conformant. I think that's a legacy Connman thing, but eg I don't think we want to support the legacy net.connman.Peer.GetProperties() style functions or signals. Summary (the following from wifi-p2p-overview.txt) === WiFi P2P is supported as follows: - if hardware and wpa_supplicant supports it, a p2p technology will appear in the technology list * this appears to refer to the Connman Manager object's GetTechnologies() method. It looks like Technologies are somewhat like NM's devices, but I'm not sure whether you'll get two Technology objects for two separate wifi interfaces? Patrik? Anyway, one issue is that even if p2p is supported on a specific wifi interface, that interface may have different capabilities that impact how p2p can be used. I don't think we can divorce it entirely from the wifi interface it will be using, which the Connman interfaces appear to do. Might be able to work something out here though (see way below). - p2p technology, as for wifi technology, supports a Scan() method. Such method will trigger a P2P find process. The results will be available through the Manager interface, comparable to services being available through this same interface after a Scan() on wifi technology. * Scan() for p2p discovery sounds fine to me, but we'll have to figure out whether this should be on the WiFi device itself, or whether a global method is OK. I can see arguments both ways, but I guess most client apps using P2P won't care about wifi at all really, just about P2P. - the result of a p2p Scan() consists into a list of peer objects * This we might be able to implement. It looks like these are top-level objects in Connman instead, with no relation to their parent WiFi interface through which they will be reached. But like I said above, perhaps most clients using P2P don't actually care how the peer is found? and thus just care about P2P and not the parent wifi interface. - it is then possible to access peer information, connecting and disconnecting it via the Peer API. * As above, the Peer API might be something we can mostly use as-is if we can get a namespace change. API Usage (also from wifi-p2p-overview.txt) = The UI willing to access to WiFi P2P technology should proceed this way: - Request Manager.GetTechnologies() and figure out from the result if p2p technology is provided. What comes next implies this successful case. * I'd rather have a separate org.fdo.XXX.WiFiP2P interface on the top-level object that has a Capabilities properties with flags like none, client, group owner. That would be more generic and then NM wouldn't have to deal with technologies. This interface would also have the Scan() method to find peers. - Add a listener to signal Manager.PeersChanged(): this signal will provide the results of a p2p technology Scan(). * I'd rather have this be signal on org.fdo.XXX.WiFiP2P instead, and coupled with an ao type Peers property that is an array of object paths to peers. There would also be PropertiesChanged signals for Peers. - From the p2p technology object, request a Technology.Scan() method. This will run for a while a P2P find process. * I'd rather have this on org.fdo.XXX.WiFiP2P, and it would emit changes to the Peers property as above. - If P2P peers are found, it will be signaled through Manager.PeersChanged(). Objects are Peer objects. UI might use Manager.GetPeers() instead, if listening to a signal is not the preferred way. * as above, I'd rather have a different dbus interface for these. - Once selected the proper Peer object, request a Peer.Connect() method on it so it will connect to it. Peer.Disconnect() will disconnect. * this should be mostly fine. --- The biggest question in my mind is whether the P2P operations can be (or should be) completely divorced from the WiFi interface they will be using. Do clients care about the WiFi interface? Quite possibly they don't; imagine a scenario in which you connect to a camera with P2P, where the Photos app doesn't care about wifi, it just wants to find some remote cameras it can connect to. I think there are restrictions in the drivers sometimes with whether they can be a Group Owner or client at the same time as a WiFi STA though, so clearly there would have to arbitration in some cases to warn the user they'd have to disconnect from their AP to do some of the P2P stuff. --- Assuming
Re: DNS not working on openvpn connection.....don't know why?
On Wed, 2015-01-07 at 11:37 -0600, Dan Williams wrote: On Thu, 2014-12-25 at 19:57 +, Another Sillyname wrote: Happy Crimbles everyone..now time for your Christmas quiz!! I am connecting to a free vpn service freevpn.me using the NetworkManager openvpn functionality in Fed21 x86_64. However once I connect to he vpn I cannot resolve names anymore. As freevpn.me is totally free their website isn't full of helpful info and googling has got me nowhere. I've added a DNS server entry in the NM part to no effect... ping IPs when the vpn is up works fine so I'm pretty sure it's a resolver issue. As it's totallly free could anyone with 10 minutes spare try it and see if you get the same result. Now that everyone is back from the holidays... :) As Michael asked, do you have resolvconf installed at all? Could you paste the non-working resolv.conf file into an email reply? Ok, you've sent the resolv.conf and they are identical, which seems to indicate that the VPN plugin was not sending the right nameservers to NM from the VPN itself. You should see something like this in the NM logs: NetworkManager[20412]: info VPN connection 'My VPN' (IP4 Config Get) reply received from old-style plugin. NetworkManager[20412]: info VPN Gateway: a.b.c.d NetworkManager[20412]: info IPv4 configuration: NetworkManager[20412]: infoInternal Address: 1.2.3.4 NetworkManager[20412]: infoInternal Prefix: 32 NetworkManager[20412]: infoInternal Point-to-Point Address: 1.2.3.5 NetworkManager[20412]: infoInternal DNS: e.f.g.h NetworkManager[20412]: infoInternal DNS: i.j.k.l NetworkManager[20412]: infoDNS Domain: 'mycorp.com' NetworkManager[20412]: info No IPv6 configuration Does anything like that show up and if so, what nameservers does it give? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: networkmanager-openvpn tls-version-min setting (for TLSv1.2)
On Mon, 2014-12-29 at 11:52 +0800, Anthony Alba wrote: Playing around with Fedora 21/nm-openvpn it turns out that the version of openvpn 2.3.6 in F21 supports TLSv1.2 cipher suites, however for backward compatibility reasons openvpn = 2.3.4 forces TLSv1 for the Control Channel. If I have a server running 2.3.6 --tls-version-min=1.0, I would like to be able to set nm-openvpn clinet to use --tls-version-min=1.2 thus availing myself of TLSv1.2. I don't believe it's supported yet, and if you are willing to work on a patch that's great! I've filed this bug to track it: https://bugzilla.gnome.org/show_bug.cgi?id=742604 so it doesn't get lost. For the UI side I think the option should probably be a dropdown box in the Security tab of the Advanced dialog, much like HMAC Auth one. Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root?
On Wed, 2015-01-07 at 23:42 +0100, poma wrote: On 07.01.2015 18:29, Dan Williams wrote: On Mon, 2015-01-05 at 19:14 +0100, Thomas Schneider wrote: Hello! I have installed latest version of NetworkManager and nmcli respectively + OpenVPN plugin or NetworkManager. user@pc1-asus:~$ apt-cache policy network-manager network-manager: Installiert: 0.9.10.0-5 Installationskandidat: 0.9.10.0-5 Versionstabelle: *** 0.9.10.0-5 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status user@pc1-asus:~$ apt-cache policy network-manager-gnome network-manager-gnome: Installiert: 0.9.10.0-2 Installationskandidat: 0.9.10.0-2 Versionstabelle: *** 0.9.10.0-2 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status user@pc1-asus:~$ apt-cache policy network-manager-openvpn network-manager-openvpn: Installiert: 0.9.10.0-1 Installationskandidat: 0.9.10.0-1 Versionstabelle: *** 0.9.10.0-1 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status user@pc1-asus:~$ apt-cache policy network-manager-openvpn-gnome network-manager-openvpn-gnome: Installiert: 0.9.10.0-1 Installationskandidat: 0.9.10.0-1 Versionstabelle: *** 0.9.10.0-1 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status All maintained connections are working. This includes OpenVPN connection type, too. However, in order to use either nm-applet or command-line client nmcli, I need to be root. The issue I'm facing is that with older release I could use either nm-applet or nmcli without root authorization. This becomes a critical issue in a multi-user desktop PC where most user neither have root authorization nor can utilize sudo. Question: How can I ensure that both, nm-applet and nmcli, can be used without root authorization? It's certainly intended that they can all be used without root. When you try to run 'nmcli' as a normal user, what error do you get? What is the output of nmcli gen perm as a normal user? $ nmcli -v nmcli tool, version 0.9.10.0-14.git20140704.fc21 $ nmcli general permissions PERMISSION VALUE org.freedesktop.NetworkManager.enable-disable-networkyes org.freedesktop.NetworkManager.enable-disable-wifi yes org.freedesktop.NetworkManager.enable-disable-wwan yes org.freedesktop.NetworkManager.enable-disable-wimax yes org.freedesktop.NetworkManager.sleep-wakeno org.freedesktop.NetworkManager.network-control yes org.freedesktop.NetworkManager.wifi.share.protected yes org.freedesktop.NetworkManager.wifi.share.open yes org.freedesktop.NetworkManager.settings.modify.systemyes org.freedesktop.NetworkManager.settings.modify.own yes org.freedesktop.NetworkManager.settings.modify.hostname auth Is this expected output? Yes, that is expected output for permissive installs. What manages the sleep state? The sleep-wake permission is actually unused. It was previously used for the private Sleep() dbus method, the only user of which was pm-utils scripts. Unfortunately the pm-utils scripts didn't wait for a dbus reply, which meant NM couldn't determine the UID of the caller, which meant polkit permission couldn't be used. So instead, the Sleep() method is locked to root and the permission isn't used. When upower or systemd are active, NetworkManager listens internally for suspend/resume signals from those services instead of using permissions or a D-Bus method. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Launch failed on freshly compiled nm into libnm
On Sat, 2015-01-03 at 15:11 +0100, Thomas Haller wrote: On Wed, 2014-12-24 at 11:13 +0100, Fabrice Dossin wrote: Hello, I just compiled NetworkManager on an rpi and have issues starting it : NetworkManager[4591]: info NetworkManager (version 1.0.0) is starting... NetworkManager[4591]: info Read config: /etc/NetworkManager/NetworkManager.conf NetworkManager[4591]: info WEXT support is enabled NetworkManager[4591]: info DNS: /etc/resolv.conf is immutable; not managing NetworkManager[4591]: info init! NetworkManager[4591]: info update_system_hostname NetworkManager[4591]: infointerface-parser: parsing file /etc/network/interfaces NetworkManager[4591]: infointerface-parser: finished parsing file /etc/network/interfaces ** libnm:ERROR:../libnm-core/nm-setting.c:1760:constructed: assertion failed: (_priv_esi-info) Aborted Did someone has an idea where to search ? Hi Fabrice, Can you obtain a backtrace of the assertion? And what is the content of your /etc/network/interfaces ? Hmm, I don't see a Loaded plugin: ifupdown: message which I'd expect to see there: nm_log_info (LOGD_SETTINGS, Loaded plugin %s: %s, pname, pinfo); One thing to double-check: have you installed NM on this Pi before? If so, perhaps the old plugins are still around and getting loaded instead? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root?
On Mon, 2015-01-05 at 19:14 +0100, Thomas Schneider wrote: Hello! I have installed latest version of NetworkManager and nmcli respectively + OpenVPN plugin or NetworkManager. user@pc1-asus:~$ apt-cache policy network-manager network-manager: Installiert: 0.9.10.0-5 Installationskandidat: 0.9.10.0-5 Versionstabelle: *** 0.9.10.0-5 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status user@pc1-asus:~$ apt-cache policy network-manager-gnome network-manager-gnome: Installiert: 0.9.10.0-2 Installationskandidat: 0.9.10.0-2 Versionstabelle: *** 0.9.10.0-2 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status user@pc1-asus:~$ apt-cache policy network-manager-openvpn network-manager-openvpn: Installiert: 0.9.10.0-1 Installationskandidat: 0.9.10.0-1 Versionstabelle: *** 0.9.10.0-1 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status user@pc1-asus:~$ apt-cache policy network-manager-openvpn-gnome network-manager-openvpn-gnome: Installiert: 0.9.10.0-1 Installationskandidat: 0.9.10.0-1 Versionstabelle: *** 0.9.10.0-1 0 500 http://ftp.debian.org/debian/ jessie/main i386 Packages 100 /var/lib/dpkg/status All maintained connections are working. This includes OpenVPN connection type, too. However, in order to use either nm-applet or command-line client nmcli, I need to be root. The issue I'm facing is that with older release I could use either nm-applet or nmcli without root authorization. This becomes a critical issue in a multi-user desktop PC where most user neither have root authorization nor can utilize sudo. Question: How can I ensure that both, nm-applet and nmcli, can be used without root authorization? It's certainly intended that they can all be used without root. When you try to run 'nmcli' as a normal user, what error do you get? What is the output of nmcli gen perm as a normal user? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Preventing nm from disconneting network while going to suspend.
On Tue, 2015-01-06 at 17:45 +0100, Thomas Haller wrote: On Mon, 2015-01-05 at 22:16 +0200, Ahmet Gereklioğlu wrote: Is there a way to prevent nm from disconneting network while the computer goes to suspend? As far as I searched I found solutions like putting this command line to a script under pm-utils such as /etc/pm/sleep.d/55NetworkManager The command line is:nmcli nm sleep false However in the version 0.9.10 it is not applicable due to syntax change. Is there a way in version 0.9.10 Thanks I only find http://askubuntu.com/a/367056/354040 , which however calls `nmcli nm sleep false` to achieve something different then prevent nm from disconneting network. Can you explain why you want that in first place, and how that worked for you pre-0.9.10 ? I think in old times, pm-utils actively called `nmcli nm sleep false| true` to notify hibernation/resume. This nmcli command is no longer present, but the DBUS function is still there... so, you could directly call the DBUS function... *BUT* `nmcli nm sleep false` does not what you seemingly think it does. It would not prevent NM from sleeping. It just sends an event to NM you just woke up. NM now listens to events from systemd/upower which also brings it to sleep. Hence, NM will receive a notification from upower/systemd and disconnect the network. You cannot easily suppress those events AFAIS. Sending an event you just woke up together with upower saying system going to hibernate will not solve your problem. Note that with NM 0.9.10 and later, devices that meet these criteria are *not* disconnected on suspend: 1) software/virtual interfaces (bridge, bond, vlan, etc) 2) Wake-on-LAN enabled via ethtool So if your intention is to get wake-on-LAN working, it should already work if you have set it up with ethtool for the interface. If not, what is the scenario you're trying to achieve? Perhaps knowing that can help us figure out how to achieve it :) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DNS not working on openvpn connection.....don't know why?
On Thu, 2014-12-25 at 19:57 +, Another Sillyname wrote: Happy Crimbles everyone..now time for your Christmas quiz!! I am connecting to a free vpn service freevpn.me using the NetworkManager openvpn functionality in Fed21 x86_64. However once I connect to he vpn I cannot resolve names anymore. As freevpn.me is totally free their website isn't full of helpful info and googling has got me nowhere. I've added a DNS server entry in the NM part to no effect... ping IPs when the vpn is up works fine so I'm pretty sure it's a resolver issue. As it's totallly free could anyone with 10 minutes spare try it and see if you get the same result. Now that everyone is back from the holidays... :) As Michael asked, do you have resolvconf installed at all? Could you paste the non-working resolv.conf file into an email reply? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
On Mon, 2014-12-22 at 21:46 +0100, Aleksander Morgado wrote: Are you suggesting that by default NM should try with IPv4 or IPv6 PDP context types if both are enabled and IPV4V6 fails? Yes, I think that would be the best solution. In QMI modems it is ModemManager the one connecting separately IPv4 and IPv6 WDS sessions when IPv4v6 is requested. Yep, when that's possible that's even better. My Nokia 21M-02 does pretty much the same in the firmware. But I'm not so sure if we can rely on such functionality always being possible? MBIM allows to request IPv4v6 or separate IPv4 and IPv6; currently we try one or the other, because the ModemManager API allows asking for both cases. The fact that in QMI we default to separate IPv4 and IPv6 is because we can do so using different WDS clients on the same control port, but maybe we shouldn't, and instead just expose we support separate IPv4 and IPv6? Nope. As discussed recently, we need to be aware of the distintion between IPV4, IPV6 and IPV4V6 on QMI modems as well. Your first QMI WDS start network command will select one of these types. The second start network command can only succeed if the selected type was IPV4V6. On the other hand, as Tore points out, there might be situations where you want to select IPV4 or IPV6 explicitly, even if the modem appears to support IPV4V6. So you need the full context type choice for QMI as well. The odd two-step dual-stack connection does not change this. The PDP type is always selected by the first connection. Is that true even if we use different separate WDS clients? If either IPv4v6 and IPv4+IPv6 are selected for a QMI modem, MM's logic will create separate WDS clients, each of them with a different Set IP Family Preference set before calling Start Network. Are we achieving something correct with this logic? Or not? And if not, how are we supposed to request IPv4v6 using only QMI? (i.e. not with the default profile being configured via AT commands). I verified a while back that this is what Verizon's connection manager did on Windows with the UML290 to achieve a working dual-stack connection. And yes, all 3 PDP contexts in the modem were IPV4V6. AFAIK there is no way to get a dual-stack connection without starting two WDS clients and setting the IP Family Preference. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.0.0 released!
Hi, I'm very happy to announce that after more than 10 years of development and 10 years of making the world a better place, NetworkManager 1.0 has been released! This release brings a more modern GObject-based client library, many bug fixes and updated translations, more flexible routing, hugely improved nmcli with password support, improved nmtui, a light-weight internal DHCP client, configure and quit mode, Bluetooth DUN support with Bluez5, VPN connection persistence, improved cooperation with external tools, expanded manpages and documentation, WWAN IPv6 support, and much much more. Full release notes are below... A huge thanks to everyone who contributed to this release (and there are many of you!), and to everyone who's been a part of the NetworkManager project over the past 10 years. Let's make the next 10 even better! Grab NetworkManager, the applet/editor, and the VPN plugins here: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager-1.0.0.tar.xz https://download.gnome.org/sources/network-manager-applet/1.0/network-manager-applet-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.0/NetworkManager-openconnect-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-openswan/1.0/NetworkManager-openswan-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.0/NetworkManager-openvpn-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.0/NetworkManager-pptp-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.0/NetworkManager-vpnc-1.0.0.tar.xz Cheers, Dan - This is a new stable release of NetworkManager. Notable changes include the following features and fixes. * New client library: libnm A new GObject-based client library, libnm, has been written, merging the existing libnm-util and libnm-glib and simplifying the API while using modern GLib APIs (such as using GDBus rather than dbus-glib, and providing gio-style asynchronous operations). IP addresses, routes, hardware addresses, and other properties are now represented as strings rather than binary types, allowing much simplified code for most languages including C, Python, and Javascript. For more information see https://wiki.gnome.org/Projects/NetworkManager/libnm libnm-util and libnm-glib are still available for backward compatibility, and the D-Bus interface remains fully compatible with 0.9.10. * New internal DHCP client A faster, lighter-weight internal DHCP client based on code from systemd-networkd has been added, and may be selected with the dhcp=internal option in NetworkManager.conf or in a configuration snippet. (Note that it does not yet support as many DHCP options as dhclient, and does not support DHCPv6.) * Configure interfaces and then quit mode A new 'configure-and-quit=yes' option has been added for environments with less dynamic network configuration. With this option set in NetworkManager.conf, available interfaces will be configured and NetworkManager will quit, spawning small nm-iface-helper processes for each interface that uses DHCP and/or IPv6, to preserve DHCP leases and IPv6 address lifetimes. No helper will be spawned for purely static IP configurations. * Improved cooperation with non-NetworkManager network configuration NetworkManager now does a better job of not interfering with devices which it did not create itself. (In particular, it no longer sets IFF_UP on externally-created devices.) * Improvements to nmcli nmcli now supports password requests and PolicyKit authorizations, allowing fully command-line based activation of connections that require passwords. (Note that activation of VPNs is not yet supported, because of the additional complexity of VPN password properties.) 'nmcli dev connect interface' will now automatically create a connection if none exists. This command is now a more useful shortcut to activate a network interface by device name. 'nmcli dev delete interface' lets you delete unused software devices (bridge, bond, team, etc). * IPv6 configuration improvements IPv6 router advertisement MTUs are now respected WWAN connections now support IPv6 if the modem and provider support IPv6. When running on 3.17 and later kernels, NetworkManager will handle IPv6 link-local address assignment to ensure that IPv6 connectivity is not enabled on interfaces that are up but not active. This means that until an IPv6-enabled connection is started, the interface will have no IPv6 link-local address. (If external tools add IPv6 addresses to the interface, NetworkManager will immediately create the IPv6 link-local address to ensure compliance with RFCs. IPv6 interface configuration that exists before NetworkManager starts is left unchanged.) Manually-configured static IPv6 configuration is kept even if automatic configuration fails. Previously, a connection configured for automatic IPv6 addressing (SLAAC) with additional static
Re: NetworkManager permissions
On Thu, 2014-12-18 at 11:44 +0100, Peter Magnusson wrote: Hi Dan, Thank you for the reply! This sounds like a good solution to me, unfortunately we are indeed using Gnome Shell UI so that would cause a problem. So what you are saying is that right now there is no way to achieve this while using gnome shell ? There might be something we can do in NM itself though, given the way the shell and most other clients create new connections. But either way, best thing to do would be to file a bug at http://bugzilla.redhat.com against RHEL7 and assign to the NetworkManager component so it doesn't get lost. Does that sound OK? Thanks! Dan On Wed, Dec 17, 2014 at 4:53 PM, Dan Williams d...@redhat.com wrote: On Thu, 2014-11-27 at 11:59 +0100, Peter Magnusson wrote: Im having some problems with permissions on NetworkManager. We are in the process of migrating our clients from RHEL 6.6 to RHEL 7. The clients connect to our wireless network using eap-tls, we provide the configuration,certificate and keys for this from our central configurationserver so that the connection is transparent to the user. In RHEL6.6 the password for the privatekey(pkcs12 used for authentication) was not visible to the users only to administrators. This was achieved by setting the connection as system wide in which case the configfile was stored under /etc/sysconfig/network-scripts and only accessible by root. In RHEL7 and NM version 0.9.9.1-28.git20140326.4dba720.el7_0.2 (lbuild from git) we can still limit the permissions to NM config using polkit but when doing this we also limit the possiblity for the user to add new wifi-networks. So what i would like to achieve is to limit access to existing connections (or connections not added by user) but i still want the users to be able to add new wificonnections. Is this possible ? I looked into this yesterday, and I think the way forward here is to restrict the user's permissions for modify.system, but allow them permissions for modify.own (own == self, not possession). This will prevent the user from being able to change any connection that is in /etc and does not have specific permissions. But it allows the user to create new connections that are restricted to that user only. There's one catch though; if you're using the GNOME Shell UI on RHEL 7.0 it doesn't set the necessary flags to create these user-specific connections when the modify.system permission is denied. We can work on fixing that though. Do you think this solution would work for you? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The short road to 1.0 (ANN: 0.995 released)
On Thu, 2014-12-18 at 11:15 -0600, Robby Workman wrote: On Wed, 17 Dec 2014 09:56:59 -0600 Dan Williams d...@redhat.com wrote: On Fri, 2014-12-12 at 16:05 -0600, Dan Williams wrote: Hi everyone! The 1.0 release is imminent. We've been cleaning out the 1.0 tracker bug [1] for more than a month. With your help we'll get there next week! A holiday present for everyone! We're getting very close to 1.0, so this is last call for any showstopper bugs that you can find. Thanks! It's all working well here, best I can tell. Awesome, thanks for the feedback. We found one issue with external software devices last night, but that's now been fixed and I think 1.0 is good to go. Absolute last call now :) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager permissions
On Thu, 2014-11-27 at 11:59 +0100, Peter Magnusson wrote: Im having some problems with permissions on NetworkManager. We are in the process of migrating our clients from RHEL 6.6 to RHEL 7. The clients connect to our wireless network using eap-tls, we provide the configuration,certificate and keys for this from our central configurationserver so that the connection is transparent to the user. In RHEL6.6 the password for the privatekey(pkcs12 used for authentication) was not visible to the users only to administrators. This was achieved by setting the connection as system wide in which case the configfile was stored under /etc/sysconfig/network-scripts and only accessible by root. In RHEL7 and NM version 0.9.9.1-28.git20140326.4dba720.el7_0.2 (lbuild from git) we can still limit the permissions to NM config using polkit but when doing this we also limit the possiblity for the user to add new wifi-networks. So what i would like to achieve is to limit access to existing connections (or connections not added by user) but i still want the users to be able to add new wificonnections. Is this possible ? I looked into this yesterday, and I think the way forward here is to restrict the user's permissions for modify.system, but allow them permissions for modify.own (own == self, not possession). This will prevent the user from being able to change any connection that is in /etc and does not have specific permissions. But it allows the user to create new connections that are restricted to that user only. There's one catch though; if you're using the GNOME Shell UI on RHEL 7.0 it doesn't set the necessary flags to create these user-specific connections when the modify.system permission is denied. We can work on fixing that though. Do you think this solution would work for you? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Notification disjoint - VPN now failed, notifications showing still connected.
On Wed, 2014-12-17 at 14:45 +, Another Sillyname wrote: I have setup a VPN on a Laptop using Fedora 21 x86_64. The VPN works fine however the gnome notifications are not reflecting the true state of the VPN. In Network Settings you can connect to XXXVPN using the ON/OFF switch. If you then do a 'nmcli connections show --active' you will get the correct information regarding the VPN and also the tun will show active on a separate line. ifconfig reports the 'hard' settings for the nic together with the relevant VPN settings. I had noticed on a couple of occasions the VPN had dropped however the gnome settings were still showing active. So if the VPN gets dropped (NOT manually disconnected) Gnome settings will still show the VPN as connected. nmcli connections show --active will still show the VPN as active, however the 'tun' line has now disappeared confirming the VPN is down. If this happens, then it seems that the VPN you're using isn't notifying the NM VPN plugin about the failure, or there's a bug in the plugin. But we'll need some logs for that. Based on what you describe, I think this VPN drop thing is a bug in NM or the VPN plugin. Can you grab some /var/log/messages about that? Also very useful is to run the specific VPN plugin with --debug --persist which will dump a ton of information that we can use to figure it out. eg: /usr/libexec/nm-vpnc-service --debug --persist /usr/libexec/nm-openvpn-service --debug --persist Dan ifconfig shows the 'hard' settings for the nic but no entry for the VPN. This means there's a disjoint in what is being reported via Gnome/NetworkManager and the actuality of the status of the VPN. In effect there would appear to be a need to 'actively poll' the tun to ensure the VPN is still active and if the tun fails NetworkManager needs to be updated accordingly. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The short road to 1.0 (ANN: 0.995 released)
On Fri, 2014-12-12 at 16:05 -0600, Dan Williams wrote: Hi everyone! The 1.0 release is imminent. We've been cleaning out the 1.0 tracker bug [1] for more than a month. With your help we'll get there next week! A holiday present for everyone! We're getting very close to 1.0, so this is last call for any showstopper bugs that you can find. Thanks! Dan The 1.0 release will be huge step forward in functionality, cooperation, client APIs, configurable routing, nmcli/nmtui, DHCP, IPv6, reduced footprint, and tons more. It just doesn't stop. I'm looking forward to 1.0 and I hope you are too! I've branched git master for 1.0 and released 0.995/1.0-rc1 tarballs. Hammer on these so we can make 1.0 as solid as ever. Please file bugs at bugzilla.gnome.org, or drop by #nm on freenode. Let's get this done. http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.995/NetworkManager-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.995/network-manager-applet-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openconnect/0.995/NetworkManager-openconnect-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openswan/0.995/NetworkManager-openswan-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openvpn/0.995/NetworkManager-openvpn-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-pptp/0.995/NetworkManager-pptp-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-vpnc/0.995/NetworkManager-vpnc-0.995.0.0.tar.xz Thanks, Dan [1] https://bugzilla.gnome.org/showdependencytree.cgi?id=682947 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[review] merge: fix all defects found by coverity (bgo #741122)
Jirka, Reviewed the merged branch on git master, it looks fine to me to include in the nm-1-0. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote: On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote: NetworkManager sets logind inhibitor lock to monitor for suspend events. So it implicitly requires logind to be present when NM starts. NM doesn't actually require that, it just wants to know about the signals that logind sends and have a chance to respond to them. If logind isn't running, NM shouldn't really care. But perhaps expectation is not matching reality in the code. Any idea what it needs the inhibitor for? To be aware of suspend/resume events of course. NM may want to disconnect the network cleanly before suspending, and on resume may need to clean up network connections and restart certain operations. logind is ordered after nss-user-lookup.target. If we have remote user database, it means that logind depends on network to be up and running. If network is provided by NetworkManager we have a loop. Due to the fact that NetworkManager service itself does not declare dependency on logind, it can be pretty hard to recognize. Any idea how it can be solved nicely? I can only think of delaying inhibitor logic in NM until logind is started. Not sure what side effects it may have. Yeah, I figure if they want to be able to run in early parts of boot they should watch logind's bus name and create their inhibitor only after it appears. Does logind get D-Bus autolaunched? NM is just creating a bus proxy for the logind DBus service, and then attempting to call a D-Bus method on logind to take an inhibitor. It doesn't actually care that much about the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to prohibit logind from launching. Perhaps NM is requesting logind to start through D-Bus autolaunch, but since the network isn't up yet logind then fails itself? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote: В Mon, 15 Dec 2014 11:34:17 -0600 Dan Williams d...@redhat.com пишет: On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote: On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote: NetworkManager sets logind inhibitor lock to monitor for suspend events. So it implicitly requires logind to be present when NM starts. NM doesn't actually require that, it just wants to know about the signals that logind sends and have a chance to respond to them. If logind isn't running, NM shouldn't really care. But perhaps expectation is not matching reality in the code. Any idea what it needs the inhibitor for? To be aware of suspend/resume events of course. NM may want to disconnect the network cleanly before suspending, and on resume may need to clean up network connections and restart certain operations. logind is ordered after nss-user-lookup.target. If we have remote user database, it means that logind depends on network to be up and running. If network is provided by NetworkManager we have a loop. Due to the fact that NetworkManager service itself does not declare dependency on logind, it can be pretty hard to recognize. Any idea how it can be solved nicely? I can only think of delaying inhibitor logic in NM until logind is started. Not sure what side effects it may have. Yeah, I figure if they want to be able to run in early parts of boot they should watch logind's bus name and create their inhibitor only after it appears. Does logind get D-Bus autolaunched? Yes. NM is just creating a bus proxy for the logind DBus service, and then attempting to call a D-Bus method on logind to take an inhibitor. It doesn't actually care that much about the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to prohibit logind from launching. Perhaps NM is requesting logind to start through D-Bus autolaunch, but since the network isn't up yet logind then fails itself? systemd tries to launch logind service which now waits for services it is ordered After and eventually times out. NM patch filed for review by NM dev team: https://bugzilla.gnome.org/show_bug.cgi?id=741572 Also, I don't think logind should fail if there is no network; no reason for it to crash and burn just because everything isn't quite ready when it starts. I presume it's got capability to deal with sporadic network outages, and that's not really different than waiting for networking to show up soon after it starts. But not my department... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
The short road to 1.0 (ANN: 0.995 released)
Hi everyone! The 1.0 release is imminent. We've been cleaning out the 1.0 tracker bug [1] for more than a month. With your help we'll get there next week! A holiday present for everyone! The 1.0 release will be huge step forward in functionality, cooperation, client APIs, configurable routing, nmcli/nmtui, DHCP, IPv6, reduced footprint, and tons more. It just doesn't stop. I'm looking forward to 1.0 and I hope you are too! I've branched git master for 1.0 and released 0.995/1.0-rc1 tarballs. Hammer on these so we can make 1.0 as solid as ever. Please file bugs at bugzilla.gnome.org, or drop by #nm on freenode. Let's get this done. http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.995/NetworkManager-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.995/network-manager-applet-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openconnect/0.995/NetworkManager-openconnect-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openswan/0.995/NetworkManager-openswan-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openvpn/0.995/NetworkManager-openvpn-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-pptp/0.995/NetworkManager-pptp-0.995.0.0.tar.xz http://ftp.gnome.org/pub/gnome/sources/NetworkManager-vpnc/0.995/NetworkManager-vpnc-0.995.0.0.tar.xz Thanks, Dan [1] https://bugzilla.gnome.org/showdependencytree.cgi?id=682947 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unusual behavior
On Thu, 2014-12-11 at 20:17 -0200, T. Kin gway wrote: Hi! I'd sent this email because I need a specific answer. Two days ago I upgraded my linux distro to a newer version that comes with gnome 3.14, when I started the system by the first time checked the active services thru netstat and saw something unusual, the NetworkManager was connected to two https addresses (one was of a university, they may be mirrors). I never saw the NetworkManager of my previous gnome connected to any address, then I removed the system and today I did a clean install using the ISO image of the distro and NetworkManager had the same behavior and it was always switching the connected address, never stopped. Does NM need to be connected to work? Is this behavior normal to the NM used in version 3.14 of Gnome? It could be NetworkManager's connectivity detection. Check /etc/NetworkManager/NetworkManager.conf and see if there is a [connectivity] section, and also look in /etc/NetworkManager/conf.d/ to see if there is a snippet there for connectivity too. Your distro (Fedora 21 perhaps?) might have enabled connectivity checking by default. NetworkManager's connectivity detection periodically contacts a user-configurable HTTP address to check whether you have network connectivity or not. GNOME and other clients use this to show WiFi hotspot logins and indicate network state. But it can be turned off quite easily. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-applet-1.0 Access Point mode
On Fri, 2014-12-05 at 06:47 +0100, poma wrote: Will this go sotobrazzo, otherwise what is the current state of the AP support? Unfortunately the same issues as before are still an issue, WRT the connection editor and AP mode. So at this point I don't think it will hit 1.0. https://bugzilla.gnome.org/show_bug.cgi?id=734589#c8 If anyone has time to pick some of this up, I can certainly advise. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Priorize one AP or other
On Fri, 2014-11-21 at 10:39 -0200, José Queiroz wrote: Hi, I'm almost sure that someone, in the past, asked this. Imagine that you're working on a ESS, where one of the APs is pretty stable, and the other is older, slower, and falty. But, for some reason, NM seems to prefer to connect to the last one, even when it's signal is weaker than the other. Is there any way to tell NM to connect to the first one, and only roam to the other if the first is unavailable? Yes there is! We've just added an autoconnect-priority option to the upcoming NM 1.0 release that lets you manually prioritize the better AP over the weaker AP when connecting to them automatically. Currently that process is based on the AP you last used, which sometimes is not the best choice, as you have seen. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: activation stage already scheduled
On Wed, 2014-11-19 at 18:24 +0100, D.S. Ljungmark wrote: So, I have some small arm boxes out in the world, and at least one of them is... misbehaving. It's rotated all journals, so it's hard to see what started this, however: root@modio:~# journalctl -u NetworkManager |grep 'error' |wc -l 17051 The errors persisted until I killed NetworkManager and then everything came up as it should. uncertain what happened. And I hope I can't reproduce it. NetworkManager --version 0.9.10.0 uname -a Linux modio 3.17.2-bone5 #1 Thu Oct 30 19:55:17 UTC 2014 armv7l GNU/Linux Debian packages from Jessie. snippet from part of that -second- below: I can't quite tell because the log messages that would tell me are long gone, but I think the cause of this is IPv6 router advertisement timeout mishandling. I believe we have fixed that in NM 0.9.10.x which we hope to release soon. Relevant patch is (I think): http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-0-9-10id=3351e3a6aeb1ab1222802b8857c757e590f5a0d7 you'll also probably want the following if IPv6 is used at all. http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-0-9-10id=1e96e68e36ad0fb158e3a91e00c7fdc1d109f69d Or, you could set the ipv6.method=ignore for the time being in the connection configuration for that interface. Does that help at all? Dan Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.279189] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.310462] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.325419] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.327484] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.338799] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.351628] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.365748] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.375169] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.377461] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.391430] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.394526] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.409356] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.420293] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.432451] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.447322] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.462336] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.464379] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.478861] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.481982] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.495960] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.505470] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.507762] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18
Re: activation stage already scheduled
On Wed, 2014-11-19 at 21:22 +0100, D.S. Ljungmark wrote: That night help. We so use ipv6 so disabling it would be temporary if so. Do you know what causes it? If I cab change something in the network setups? I think it's a result of NM mishandling the lifetime on the rdnss/dnssd options. If you can live without those, then perhaps turning them off would work. But that would mean statically configured IPv6 DNS. Dan Otherwise, is there more negative impact of this other than eating all my log space? On 19 Nov 2014 20:28, Dan Williams d...@redhat.com wrote: On Wed, 2014-11-19 at 18:24 +0100, D.S. Ljungmark wrote: So, I have some small arm boxes out in the world, and at least one of them is... misbehaving. It's rotated all journals, so it's hard to see what started this, however: root@modio:~# journalctl -u NetworkManager |grep 'error' |wc -l 17051 The errors persisted until I killed NetworkManager and then everything came up as it should. uncertain what happened. And I hope I can't reproduce it. NetworkManager --version 0.9.10.0 uname -a Linux modio 3.17.2-bone5 #1 Thu Oct 30 19:55:17 UTC 2014 armv7l GNU/Linux Debian packages from Jessie. snippet from part of that -second- below: I can't quite tell because the log messages that would tell me are long gone, but I think the cause of this is IPv6 router advertisement timeout mishandling. I believe we have fixed that in NM 0.9.10.x which we hope to release soon. Relevant patch is (I think): http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-0-9-10id=3351e3a6aeb1ab1222802b8857c757e590f5a0d7 you'll also probably want the following if IPv6 is used at all. http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-0-9-10id=1e96e68e36ad0fb158e3a91e00c7fdc1d109f69d Or, you could set the ipv6.method=ignore for the time being in the connection configuration for that interface. Does that help at all? Dan Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.279189] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.310462] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.325419] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.327484] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.338799] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.351628] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.365748] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.375169] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.377461] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.391430] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.394526] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.409356] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.420293] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.432451] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.447322] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.462336] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.464379] [devices/nm-device.c:2026] activation_source_schedule(): activation stage already scheduled Nov 18 21:35:38 modio NetworkManager[286]: error [1416346538.478861
Re: Support for HP lt4112 Gobi 4G Modem
On Fri, 2014-11-14 at 20:23 +0100, Martin Hauke wrote: Hi, after i've got a shiny new laptop (HP Zbook 14) discovered that the integrated 4G-Modem was not supported :/ It's a HP lt4112 Gobi 4G Modem (which is a HP-branded Huawei ME906E) http://consumer.huawei.com/en/solutions/m2m-solutions/products/tech-specs/me906e-en.htm Despite the cards description has Gobi in it's name none of the existing gobi layouts in the qcserial driver worked. So i've modified the qcserial and the qmi_wwan driver (against kernel 3.16.6) and after some testing i've got the following layout: I see that QMI works on the device, and that would be the preferred method to manage it. If you keep the qmi_wwan changes, the ModemManager should be able to handle the device as a QMI device and use the cdc-wdm0 interface for control (QMI commands) and the network interface for data. MBIM might work too, but Im not sure what the driver binding situation would be there yet. Since QMI seems to work lets try that first. Dan ## HP lt4112 Gobi 4G Modem # 1st USB Configuration Descriptor: - 0 - HP Mobile Connect - PC UI Interface // AT-capable modem port 1 - HP Mobile Connect - Application Interface // DM/DIAG 2 - HP Mobile Connect - Modem // AT-capable modem port 3 - HP Mobile Connect - PCSC Interface // CCID compatible SC 4 - HP Mobile Connect - Network Card// QMI/net 5 - HP Mobile Connect - GPS Interface // NMEA - # 2nd USB Configuration Descriptor: -- 0 - HP lt4112 Gobi 4G Module// ??? 1 - MBIM Data // ??? 1 - MBIM Data // ??? 2 - HP Mobile Connect - GPS Interface // ??? -- Now I'm able to establish a ppp-based internet connection on both AT-compatible modem ports. The modem has to be initialized with AT+CFUN otherwise it won't work! If you ever need to reboot the modem through the AT-port use AT$QCPWRDN I've also tested the DM/DIAG port (see attachment). The modem supports GPS/GLONASS and after issueing AT^WPDGP on one of the AT-ports you'll see NMEA-output on the NMEA-interface (speed 9600, 8N1) So far i've seen the following NEMA-sentences: GPGSV,GPGGA,GPVTG,GPGSA,GPRMC. You can stop receiving GNSS with AT^WPEND on an AT-port. There's also a QMI-port. I haven't done much with it yet - but at least some qmicli commands seem to work as expected (see attachment). Interestingly the device also expose a CCID compatible smartcard interface. Unfortunately my naive approach to add support to the pcsc-lite ccid driver adding USB vendor/product-id/description to ifd-ccid.bundle/Contents/Info.plist did not work (see attachment). Has anyone worked with those types of PCSC-interfaces before? Finally there's seems to be MBIM support for this device but i've no clue how to activate that. I've attached the patches and some debug-logs for further information. best regards, Martin ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Support for HP lt4112 Gobi 4G Modem
On Fri, 2014-11-14 at 22:43 +0100, Martin Hauke wrote: Hi, On 14.11.2014 21:12, Dan Williams wrote: I see that QMI works on the device, and that would be the preferred method to manage it. If you keep the qmi_wwan changes, the ModemManager should be able to handle the device as a QMI device and use the cdc-wdm0 interface for control (QMI commands) and the network interface for data. MBIM might work too, but Im not sure what the driver binding situation would be there yet. Since QMI seems to work lets try that first. I've just tested an LTE-connection via qmi/wwan with ModemManager 1.0.0 without any problems. However the maximum downlinkspeed wasn't better than before with the AT-interface and was nearly the same as on Windows 8.1 (which seems to use MBIM). Are there any known issues with ModemManager when exposing the AT- and the QMI-interfaces in parallel ? There aren't any known issues, but you usually cannot use them in parallel for data sessions. eg, you cannot typically have a ppp session going on the AT port *and* a QMI data session on the 'net' port at the same. Firmware really doesn't like this, in my experience. Note that ModemManager *may* use the AT port for some operations if the device's QMI (or MBIM) firmware doesn't expose certain functionality. But some devices expose multiple AT ports (like yours does) and ModemManager will only use one. Interestingly the device also expose a CCID compatible smartcard interface. Unfortunately my naive approach to add support to the pcsc-lite ccid driver adding USB vendor/product-id/description to ifd-ccid.bundle/Contents/Info.plist did not work (see attachment). Has anyone worked with those types of PCSC-interfaces before? Any thoughts on this? It would be really cool to have this working since you can then send raw APDUs to the SIM. ModemManager doesn't claim the PCSC port, so I guess any external application that could speak the right protocol over that port could use it for PCSC stuff. I haven't looked into it though. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bug in Network-Manager with virtual interfaces / new plugin
On Fri, 2014-10-24 at 19:05 +0200, Nicolas Boulicault wrote: Hi there, Michael asked to forward this to the list, so here it is... The patch 0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch (debian Jessie) messes up with my virtual interfaces (vmware vmnet1/vmnet8). Could you run NM with --log-level=debug and reproduce the issue so that we can get an idea of what NM is doing? The goal is to still recognize these interfaces, but *not* touch them, simply represent their current external state through the NM APIs and command-line tools. So if NM is somehow screwing up those devices by changing their configuration, that would be a bug in NM, and we need to find it and fix it. Thanks! Dan Even if I set them manually unmanaged (from /etc/network/interfaces or using keyfile plugin), they finally appear connected and make me lose my internet connection if my ethernet link is down and I'm using WIFI. I'm not sure exactly what's going on with the internals of Network-Manager in this case but setting the default unmanaged flag on the interfaces seems to have some negative side effects. However, I think the idea of not managing the virtual interfaces is OK, in particular for not expert users. You'll find enclosed a small plugin that detects those virtual interfaces and adds them to the unmanaged list. This is based on the keyfile plugin. Please feel free to use it (or not). (0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch has to be reverted for this plugin to work) Thanks for your work anyway. Nicolas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hitspot automatic connect
On Fri, 2014-10-24 at 11:18 +0200, Andreas Müller wrote: On Fri, Oct 24, 2014 at 10:43 AM, Thomas Haller thal...@redhat.com wrote: On Fri, 2014-10-24 at 10:19 +0200, Andreas Müller wrote: Hi, Now my question: What does it need to start hotspot automatically after boot? If there is no setting available I could create a script/app using Networkmanager's dbus I would be very happy if somebody could help me because for me this is the last part of the puzzle and solving would make me run in happy mode :) you certainly could use the DBUS interface. But maybe it's easier to use nmcli connection up? Thomas Thomas, you are my hero of the day - thanks a lot. If there are no other WiFi connections defined on the system (nmcli con | grep wireless) and the AP connection is the only one, and set autoconnect=true, then NM will always bring that connection up when starting. If you do have other wifi connections that you periodically use, you could set all of them autoconnect=no, and NM will ignore them and always start the AP connection. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: veth won't be configured in libvirt managed LXC container
On Sun, 2014-10-19 at 16:03 +0200, Lubomir Rintel wrote: On Fri, 2014-10-17 at 09:28 -0400, Dan Winship wrote: There's a bunch of discussion about this in https://bugzilla.gnome.org/show_bug.cgi?id=731014. The short answer is it's complicated, because veths get used for a bunch of different things in different situations... I'm not sure I understand the outcome there. I'm not sure there was a concrete outcome yet. There are really two cases here: 1) inside the container/VM - treat like normal Ethernet, including default DHCP if that's enabled in the NM configuration 2) on the host - treat as default-unmanaged and assume connections that are configured by Docker/LXC/libvirt/etc without touching the interfaces. We used to always do #1, but now we always do #2 because of Docker. It would be great to do both at the appropriate time... does that all make sense? Not assuming assuming the connection on a device that is in fact not configured does not imply doing DHCP on that device. If the user won't The question is, what does configured mean? NM considers an interface with only an IPv6LL address to be configured, because that's a valid network configuration. Unfortunately the kernel assigns an IPv6LL address automatically on IFF_UP, whether the administrator intends that or not. So NM doesn't know whether the administrator *intends* the IPv6LL-only configuration, or whether they did nothing. We don't have a solution for this yet. (Tangent: technically any interface that is IFF_UP is configured because something/someone explicitly set that. This would also handle L2-only configurations, which is something we want to do. Unfortunately, you have to set the device IFF_UP to get carrier events, and then the kernel assigns IPv6LL address too :( The ideal situation for all this would be (a) treat any IFF_UP interface as configured and assume it's connection even if L2-only, (b) enable carrier detection without IFF_UP, (c) don't always set IFF_UP on devices. We investigated kernel changes to disambiguate carrier detection from IFF_UP, but that was a non-starter as it would require changes to every single driver, or complicated core changes to work around having to change every driver...) create a connection for the veth device NM won't touch it anyway, would it? It shouldn't touch veth automatically because they are default unmanaged, which means you have to explicitly activated/deactivate them. Dan -- Dan Lubo On 10/16/2014 07:08 AM, Lubomir Rintel wrote: Hi, currently it is impossible to get useful network configuration for LXC containers on boot. (At least if they're managed via libvirt; I have no idea if anything is different with native LXC tooling). They're supposed to obtain their configuration via DHCP, but instead connection is assumed. Firstly because there's an IPv6 local link address that (I think) gets assigned when libvirt ups the interface and secondly because it's a software link. Why do we assume connection on all software links? Virtual ethernet devices are supposed to behave much like ordinary ethernet devices; they have carrier detection, etc. I'm following up with the patches that resolve the problem for me, but I'm not quite sure about the special case for veth. Thoughts? Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN + dnsmasq = split dns?
On Tue, 2014-10-21 at 07:09 +0200, Olav Morken wrote: On Mon, Oct 20, 2014 at 16:20:03 -0500, Dan Williams wrote: On Fri, 2014-10-10 at 21:17 +0200, Olav Morken wrote: Hi, I am trying to set up Network Manager to connect to an OpenVPN server, and have trouble understanding how it applies the DNS settings it receives from the server. Sorry for the late reply... Which version of NM do you have, and what distro? It's XUbuntu 14.04 with network-manager 0.9.8.8-0ubuntu7 (I guess I should have been clearer about it being included at the end of my original message :) ) Basically, as far as I can tell, it automatically assumes that I want to use split dns, and limits the DNS servers it receives from the OpenVPN servers to the domains it assumes belongs to this configuration. However, it also ignores the existing DNS servers it has configured. By default, NM will not do split DNS, which means when the VPN is connected, the VPN nameservers replace the existing nameservers. This is required to ensure that if for some reason the VPN nameservers cannot be contacted, that your queries don't fall back to the non-VPN nameservers and return bogus (and potentially malicious) results. But, if you add dns=dnsmasq to the /etc/NetworkManager/NetworkManager.conf file and install 'dnsmasq', then NM will run in split DNS mode. Here, NM will spawn a private copy of dnsmasq and send it configuration to direct any queries ending in the domain passed back from the openvpn server (or entered into the NM configuration for that VPN connection) to the VPN nameservers, and everything else to the non-VPN nameservers. That is quite a large change in behavior for someone running with dnsmasq. I also think it is the wrong behavior when we are pushing a default route over the VPN. With a default route over the VPN it is likely that we would want all traffic, including DNS traffic over the VPN. It is also likely that the user would end up trying to contact the local DNS servers over the VPN, which would break. If you want everything to go to the VPN nameservers, then 'dns=dnsmasq' isn't what you want, since that is what enables this local caching nameserver configuration. I guess you just want the non-local-caching configuration, where you can just not specify dns=. That leaves us with a dnsmasq configured with two nameservers it will query for two specific subdomains, and no nameservers it will use for other domains. The result is that dnsmasq is only willing to respond to DNS queries for those subdomains, and respond with REFUSED for every other domain. I assume that this is not the way it is supposed to work, since that would mean that everyone connecting to a VPN would be unable to access most of the Internet. I therefore assume that there is something wrong with my configuration. That sounds like a bug; do you know if you have any custom dnsmasq configuration on that system? Also check two thigns: 1) /etc/resolv.conf should have 127.0.0.1 as the only namesever 2) Look in /var/run/NetworkManager (or /run/NetworkManager) for the 'dnsmasq.conf' file which is what NM sends to dnsmasq (the only caveat here is that if you run Ubuntu, this procedure may not apply as the info is sent to dnsmasq over D-Bus) I wasn't aware the Ubuntu had such significant changes to Network Manager. In that case, I think the behavior we am seeing is Ubuntu-specific. There is no customization of the dnsmasq settings on this system. (In fact the behavior has been observed on several different Ubuntu installations.) From the logs (included at the end of my original message): dnsmasq[1464]: setting upstream servers from DBus dnsmasq[1464]: using nameserver 198.51.100.168#53 for domain 0.192.in-addr.arpa dnsmasq[1464]: using nameserver 198.51.100.168#53 for domain example.org dnsmasq[1464]: using nameserver 198.51.100.57#53 for domain 0.192.in-addr.arpa dnsmasq[1464]: using nameserver 198.51.100.57#53 for domain example.org Nothing in the log about the original (non-VPN) DNS servers, so I am guessing they were removed. I think with Ubuntu, dns=dnsmasq might be enabled by default. Can you check /etc/NetworkManager/NetworkManager.conf and if so, remove that line? Let us know what the results are! For what it is worth, after futher testing we have determined that it is the IPv6 configuration that breaks the DNS config. We have seen three different behaviors, depending on the VPN config: 1. VPN with only IPv4 address and default route: The DNS servers are added as global DNS servers. 2. VPN with both IPv4 and IPV6 addresses and default routes, but only IPv4 DNS servers pushed through VPN configuration: The DNS servers are added as local DNS servers, with no global DNS servers. 3. VPN with both IPv4 and IPV6 addresses and default routes
Re: NetworkManager master builds for Fedora in COPR
On Thu, 2014-10-16 at 13:21 +0200, Lubomir Rintel wrote: Hi, I'm doing regular builds of NetworkManager packages for Fedora for my own testing/development purposes. I made COPR projects recently so that the packages get published and it's easy for me to update my machines; and I thought that someone else might find it useful too: There's two projects, lkundrak/NetworkManager [1], which builds master code and lkundrak/NetworkManager-integration [2] which merges my branches that are pending review. [1] https://copr.fedoraproject.org/coprs/lkundrak/NetworkManager/ [2] https://copr.fedoraproject.org/coprs/lkundrak/NetworkManager-integration/ The builds are triggered manually, around once a day. As usual with COPR repositories, use it at your own risk (i.e. not in production and only if you know how to restore to good package versions if anything breaks). Thanks for doing this! I've wanted to do it for a while but never got around to it... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN + dnsmasq = split dns?
On Fri, 2014-10-10 at 21:17 +0200, Olav Morken wrote: Hi, I am trying to set up Network Manager to connect to an OpenVPN server, and have trouble understanding how it applies the DNS settings it receives from the server. Sorry for the late reply... Which version of NM do you have, and what distro? Basically, as far as I can tell, it automatically assumes that I want to use split dns, and limits the DNS servers it receives from the OpenVPN servers to the domains it assumes belongs to this configuration. However, it also ignores the existing DNS servers it has configured. By default, NM will not do split DNS, which means when the VPN is connected, the VPN nameservers replace the existing nameservers. This is required to ensure that if for some reason the VPN nameservers cannot be contacted, that your queries don't fall back to the non-VPN nameservers and return bogus (and potentially malicious) results. But, if you add dns=dnsmasq to the /etc/NetworkManager/NetworkManager.conf file and install 'dnsmasq', then NM will run in split DNS mode. Here, NM will spawn a private copy of dnsmasq and send it configuration to direct any queries ending in the domain passed back from the openvpn server (or entered into the NM configuration for that VPN connection) to the VPN nameservers, and everything else to the non-VPN nameservers. That leaves us with a dnsmasq configured with two nameservers it will query for two specific subdomains, and no nameservers it will use for other domains. The result is that dnsmasq is only willing to respond to DNS queries for those subdomains, and respond with REFUSED for every other domain. I assume that this is not the way it is supposed to work, since that would mean that everyone connecting to a VPN would be unable to access most of the Internet. I therefore assume that there is something wrong with my configuration. That sounds like a bug; do you know if you have any custom dnsmasq configuration on that system? Also check two thigns: 1) /etc/resolv.conf should have 127.0.0.1 as the only namesever 2) Look in /var/run/NetworkManager (or /run/NetworkManager) for the 'dnsmasq.conf' file which is what NM sends to dnsmasq (the only caveat here is that if you run Ubuntu, this procedure may not apply as the info is sent to dnsmasq over D-Bus) Let us know what the results are! Dan I am however unable to tell what makes it choose this behavior. I tried to look at the code, and found the location where it adds the domains[1], but I was unable to find a way to override this behavior. Does anyone have any suggestions for what may trigger this behavior, and what I can do to avoid it? (Configuration details and logs from network manager included below.) Best regards, Olav Morken [1] http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns-manager/nm-dns-dnsmasq.c?id=60cce4004284242f0891160e21979a3027da6e0e#n234 Configuration: Both the client and server have IPv6 enabled. The VPN configuration on the client side doesn't contain anything too exiting. It uses a TCP connection to port 443, a TUN device, and username+password authentication. Both the IPv4 and the IPv6 settings are set to Automatic(VPN) The OpenVPN server is configured with a TUN device and topology subnet. It pushes the following (slightly anonymized) options to the client: push dhcp-option DNS 198.51.100.57 push dhcp-option DNS 198.51.100.168 push dhcp-option DOMAIN example.org push redirect-gateway def1 bypass-dhcp push route-ipv6 2000::/3 Software versions: XUbuntu 14.04 network-manager 0.9.8.8-0ubuntu7 network-manager-openvpn 0.9.8.2-1ubuntu4 openvpn 2.3.2-7ubuntu3 Log from connection: NetworkManager[924]: info IPv4 configuration: NetworkManager[924]: info Internal Gateway: 192.0.2.1 NetworkManager[924]: info Internal Address: 192.0.2.2 NetworkManager[924]: info Internal Prefix: 25 NetworkManager[924]: info Internal Point-to-Point Address: 0.0.0.0 NetworkManager[924]: info Maximum Segment Size (MSS): 0 NetworkManager[924]: info Forbid Default Route: no NetworkManager[924]: info Internal DNS: 198.51.100.57 NetworkManager[924]: info Internal DNS: 198.51.100.168 NetworkManager[924]: info DNS Domain: 'example.org' NetworkManager[924]: info IPv6 configuration: NetworkManager[924]: info Internal Address: 2001:db81:4561::1000 NetworkManager[924]: info Internal Prefix: 64 NetworkManager[924]: info Internal Point-to-Point Address: 2001:db81:4561::1 NetworkManager[924]: info Maximum Segment Size (MSS): 0 NetworkManager[924]: info Static Route: 2000::/3 Next Hop: 2000:: NetworkManager[924]: info Forbid Default Route: no NetworkManager[924]: info DNS Domain: 'example.org' NetworkManager[924]: info VPN connection 'example-openvpn-config' (IP Config Get) complete. NetworkManager[924]: info Policy set
Re: Notifications not showing, when applet is disabled
On Sat, 2014-10-18 at 17:43 +0200, Hendrik Rosendahl wrote: Hi everyone, I noticed, that no notification is displayed, if the applet is disabled by the gsettings. How to reproduce: 1. Start nm-applet, if it isn't already 2. Make sure, that you get a notification, when interacting with NetworkManager (e.g. connecting to a network) 3. Execute gsettings set org.gnome.nm-applet show-applet 'false' 4. Interact with NetworkManager (e.g. through nmtui) to repeat the steps in 1. 5. Notice, that there is no notification shown What I expected: As the option only says show-applet, we should still see the notifications. Solution? I had a look at the source and with this diff I could produce the expected behavior: diff --git a/src/applet.c b/src/applet.c index 81e2ac5..7d411c7 100644 --- a/src/applet.c +++ b/src/applet.c @@ -884,9 +884,6 @@ applet_do_notify (NMApplet *applet, g_return_if_fail (summary != NULL); g_return_if_fail (message != NULL); - if (!gtk_status_icon_is_embedded (applet-status_icon)) - return; - /* if we're not acting as a secret agent, don't notify either */ if (!applet-agent) return; It is running on my system right now, but I don't know if this breaks anything else. The originating commit b74deac92d8192591ddbb62f2e2b1b7101a5e95d doesn't say why the notification shouldn't be shown, if the applet isn't visible. But in my opinion it doesn't make sense to not show the notification, only because the applet isn't shown. Additionally we now have the gsettings to control what should be shown, which wasn't the case when this commit was made, as far as I can tell. Please excuse any formal mistakes I made, as it is my first time using a mailing list. Thanks for the report and investigation. I believe the original intent was that when nm-applet wasn't being shown it shouldn't provide any user interaction other than it's secret agent, because if it's not being shown, whatever other UI *is* shown should be providing those notifications. I'm not sure we ever thought about running the applet hidden, but only providing notifications. If that's useful to you, I'd be happy to take a patch that adds a new GSetting called notify-when-hidden that turns the notifications back on in this case. Would you be able to work on a patch for that? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unhandled vpnc request
On Tue, 2014-10-14 at 20:54 +0200, Christian Hesse wrote: Hello everybody, with latest networkmanager-vpn (git master, commit 3161854) connection break ever now and then. The log contains these lines: ** (nm-vpnc-service:23836): WARNING **: Unhandled vpnc request 'vpnc: ' vpnc: recvfrom: Message too long warn VPN plugin failed: login-failed (0) info VPN plugin state changed: stopped (6) info VPN plugin state change reason: login-failed (10) It's a bug, and I've pushed a fix to git master. Can you try now? Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RTL8188SU(rtl8192su) rtl8192sufw-ap.bin
On Tue, 2014-10-14 at 02:59 +0200, poma wrote: Realtek RTL8188SU/RTL8191SU/RTL8192SU driver https://github.com/chunkeey/rtl8192su RTL8188SU It looks like everything worked correctly here for AP mode, at least from the NM logs. Is that correct? Dan - lsusb Bus 002 Device 003: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter ~~ - lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M ... |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=rtl8192su, 480M ~~~ - ethtool -i wlp0s4f1u3 driver: rtl8192su ... ~~~ - /usr/lib/firmware/rtlwifi/rtl8192sufw.bin eq https://github.com/chunkeey/rtl8192su/raw/master/firmwares/rtl8192sufw-ap.bin ~ - iwconfig wlp0s4f1u3 wlp0s4f1u3 IEEE 802.11bgn Mode:Master Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:off ~ - ifconfig wlp0s4f1u3 wlp0s4f1u3: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 10.42.0.1 netmask 255.255.255.0 broadcast 10.42.0.255 inet6 fe80::201:2ff:fe03:405 prefixlen 64 scopeid 0x20link ether 00:01:02:03:04:05 txqueuelen 1000 (Ethernet) RX packets 77 bytes 7421 (7.2 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 126 bytes 27469 (26.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 - iw wlp0s4f1u3 info Interface wlp0s4f1u3 ifindex 5 wdev 0x10001 addr 00:01:02:03:04:05 ssid RTL8188SU(rtl8192su) type AP wiphy 1 channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz ~ - iw list Wiphy phy1 max # scan SSIDs: 4 max scan IEs length: 2257 bytes RTS threshold: 2347 Coverage class: 0 (up to 0m) Device supports RSN-IBSS. Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP (00-0f-ac:4) * CMAC (00-0f-ac:6) Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * AP/VLAN * monitor * mesh point * P2P-client * P2P-GO Band 1: Capabilities: 0x1862 HT20/HT40 Static SM Power Save RX HT20 SGI RX HT40 SGI No RX STBC Max AMSDU length: 7935 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 16 usec (0x07) HT TX/RX MCS rate indexes supported: 0-7, 32 Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps * 5.5 Mbps * 11.0 Mbps * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) * 2472 MHz [13] (20.0 dBm) * 2484 MHz [14] (disabled) Supported commands: * new_interface * set_interface * new_key * start_ap * new_station * new_mpath * set_mesh_config * set_bss * authenticate * associate * deauthenticate * disassociate * join_ibss * join_mesh * set_tx_bitrate_mask * frame * frame_wait_cancel * set_wiphy_netns * set_channel * set_wds_peer * probe_client * set_noack_map * register_beacons * start_p2p_device *
Re: Ad-Hoc network creation took too long, failing activation
On Thu, 2014-10-09 at 00:24 +0200, poma wrote: On 08.10.2014 20:31, Dan Williams wrote: On Wed, 2014-10-08 at 00:10 +0200, poma wrote: Starting Network Manager... info NetworkManager (version 0.9.10.0-5.git20140704.fc21) is starting... info WEXT support is enabled info WiFi hardware radio set enabled info Loaded device plugin: /usr/lib/NetworkManager/libnm-device-plugin-wifi.so info WiFi enabled by radio killswitch; enabled by state file info Networking is enabled by state file Started Network Manager. info (ra0): driver does not support SSID scans (scan_capa 0x00). info (ra0): using WEXT for WiFi device control info (ra0): new 802.11 WiFi device (driver: 'usb' ifindex: 5) info (ra0): exported as /org/freedesktop/NetworkManager/Devices/4 info (ra0): device state change: unmanaged - unavailable (reason 'managed') [10 20 2] info (ra0): preparing device warn (ra0): error 100 getting card mode error [1412709645.317223] [platform/wifi/wifi-utils-wext.c:160] wifi_wext_set_mode(): (ra0): error setting mode 2 Ugh, looks like you're using WEXT, which is historically quite problematic because different drivers expected different sequences of WEXT requests. Any driver that uses WEXT and is not upstream is automatically suspect, unfortunately... info wpa_supplicant started info (ra0) supports 1 scan SSIDs info (ra0): supplicant interface state: starting - ready info (ra0): device state change: unavailable - disconnected (reason 'supplicant-available') [20 30 42] info (ra0): supplicant interface state: ready - disconnected info (ra0) supports 1 scan SSIDs info startup complete info (ra0): supplicant interface state: disconnected - inactive ... info (ra0): disconnecting for new activation request. info (ra0): device state change: activated - deactivating (reason 'none') [100 110 0] info NetworkManager state is now DISCONNECTING info (ra0): device state change: deactivating - disconnected (reason 'none') [110 30 0] info (ra0): deactivating device (reason 'none') [0] info (ra0): canceled DHCP transaction, DHCP client pid 1144 info NetworkManager state is now DISCONNECTED info Activation (ra0) starting connection 'bla' info Activation (ra0) Stage 1 of 5 (Device Prepare) scheduled... warn Connection disconnected (reason -3) info (ra0): supplicant interface state: completed - disconnected info Activation (ra0) Stage 1 of 5 (Device Prepare) started... info (ra0): device state change: disconnected - prepare (reason 'none') [30 40 0] info NetworkManager state is now CONNECTING info Activation (ra0) Stage 2 of 5 (Device Configure) scheduled... info Activation (ra0) Stage 1 of 5 (Device Prepare) complete. info Activation (ra0) Stage 2 of 5 (Device Configure) starting... info (ra0): device state change: prepare - config (reason 'none') [40 50 0] info Activation (ra0/wireless): connection 'bla' has security, and secrets exist. No new secrets needed. info Config: added 'ssid' value 'bla' info Config: added 'mode' value '1' info Config: added 'frequency' value '2412' info Config: added 'key_mgmt' value 'NONE' info Config: added 'auth_alg' value 'OPEN' info Config: added 'wep_key0' value 'omitted' info Config: added 'wep_tx_keyidx' value '0' info Activation (ra0) Stage 2 of 5 (Device Configure) complete. info Config: set interface ap_scan to 2 info (ra0): supplicant interface state: disconnected - associating warn Activation (ra0/wireless): Ad-Hoc network creation took too long, failing activation. The driver did not emit the SIOCGIWAP event, indicating that it had successfully completed Ad-Hoc AP setup. This is a driver bug. info (ra0): device state change: config - failed (reason 'supplicant-timeout') [50 120 11] info NetworkManager state is now DISCONNECTED warn Activation (ra0) failed for connection 'bla' warn Connection disconnected (reason -3) info (ra0): supplicant interface state: associating - disconnected info (ra0): device state change: failed - disconnected (reason 'none') [120 30 0] info (ra0): deactivating device (reason 'none') [0] warn (ra0): error 100 getting card mode error [1412717534.522258] [platform/wifi/wifi-utils-wext.c:160] wifi_wext_set_mode(): (ra0): error setting mode 2 IBSS works via Wicd although not reliable. BTW AP/WPA2, is it possible at all? NM supports AP mode if wpa_supplicant supports it on the device, but given the information you've provided here, the driver looks very fragile and I wouldn't expect it to work. WPA2 may be possible, but again the driver is quite suspect. The driver is just bad, I'm afraid... Dan Thanks, whether the same(Ad-Hoc/IBSS WEXT == unsupported) applies to this module also Could you do the following to get supplicant debug logs in this case? They can be enabled by dbus, but it's sometimes easier to just: 1) mv /usr/sbin/wpa_supplicant
Re: Ensuring predictable MAC address for bond interface
On Wed, 2014-10-08 at 07:54 +0200, Thomas Haller wrote: On Tue, 2014-10-07 at 20:25 -0700, Ed Swierk wrote: For these experiments I upgraded to NetworkManager 0.9.10.0. I tried setting primary=eth0 in the bond options. This option has an effect in only one case: if I start with only eth1 plugged in (i.e. carrier up), and then plug in eth0, the bond driver will switch the active slave from eth1 to eth0 (whereas normally it leaves eth1 active, switching to eth0 only when link drops on eth1). But this has no effect on the MAC address of the bond device--either way, the bond device gets eth1's MAC address and keeps it, since eth1 was the first enslaved device. I also experimented with setting ignore-carrier=eth0,eth1 in the main section of NetworkManager.conf, in the hope of tricking the nm_device_state_changed() logic into transitioning the slave devices to DISCONNECTED and enslaving them regardless of their carrier state. This works, sort of: now NetworkManager starts up, creates the bond device, and enslaves eth0 and eth1, whether or not they are plugged in. The bond device gets eth0's MAC address. It's still pretty easy to mess things up, for example by bringing down the bond device (via nmcli conn down) and then bringing up eth1. I'm getting the sense that I'm fighting a losing battle against a fundamental aspect of NetworkManager, which is to react dynamically to link events, and only secondarily try to guarantee a certain configuration. I'm going to try systemd-networkd next, and see if it's a better fit for my application. I think that the concept order of how slaves are attached to bond master does not mean anything for NetworkManager, hence there is no ~first~ slave. (of course, whenever you attach slaves to a bond, one of those will be the first. But that is random in case of autoconnect and nothing that you can configure or that NM anticipates). Is it possible to set the mac address when creating the bond? If yes, we could add a configuration option similar to NM_SETTING_BRIDGE_MAC_ADDRESS. Yeah, the kernel allows that, and we should add this option to bonds like we did for bridges, as you suggest. We could make NM_SETTING_BOND_MAC_ADDRESS be a hex string, or alternatively, an interface name -- so we would look at the interfaces and take it's MAC address. That gets complicated though, since if the slave that you specify doesn't exist, you cannot set up the bond. I'd rather handle that in editors, like we do for the MAC Address boxes of other interface types with a dropdown suggesting interfaces you can choose. But we should do this either way. Dan Thomas On Tue, Oct 7, 2014 at 7:34 AM, Dan Williams d...@redhat.com wrote: On Mon, 2014-10-06 at 12:51 -0700, Ed Swierk wrote: I'm using NetworkManager on a server with two wired Ethernet interfaces (eth0 and eth1) configured as slaves of a bond in active-backup mode. I'd like the bond interface to always be assigned eth0's MAC address. This is easy with old-school static network configuration like ifupdown: just make eth0 the first slave of the bond interface, and Linux will copy eth0's MAC address to the bond. When NetworkManager starts up and reads system-interface config files, it creates the bond interface right away, but doesn't add a slave until it notices that the slave's link is up (i.e. carrier is 1). And of course the link state depends on lots of things, like whether a cable is plugged in and the state of the switch or host at the other end. Thus whether eth0 or eth1 gets enslaved to the bond first is unpredictable, meaning the bond interface's MAC address is unpredictable. This is troublesome in some environments, such as ones where a DHCP server assigns IP addresses based on the MAC address of the client. Does setting the primary bond option when in active-backup mode to eth0 make things better? In nm-connection-editor it'll be in the page for Bond options, in nmtui it'll be in about the same place, and in nmcli you'd do: nmcli con mod Bond1 +bond.options primary=eth0 and then re-activate the connection. Let me know if that does/doesn't help. (note; this may only work with 0.9.10+) Dan NetworkManager already treats a bond slave interface differently when its link goes down, leaving it in DISCONNECTED state rather than switching it to UNAVAILABLE. So there's precedent for having a bond
Re: [MM PATCH] port-serial: fix forced closing after b28230411
On Wed, 2014-10-08 at 00:29 +0200, Aleksander Morgado wrote:
On Tue, Oct 7, 2014 at 11:06 PM, Dan Williams d...@redhat.com wrote:
b28230411 moved up the self-priv-forced_close = TRUE, which
caused mm_port_serial_close() to just return without actually
closing the port and cleaning up.
Also, cancel the reopen separately from closing the port since
the two operations are actually independent of each other.
Looks good to me; I'd get it also in the mm-1-4 branch as well.
Pretty sure I did that already...
Dan
---
src/mm-port-serial.c | 43 +++
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/src/mm-port-serial.c b/src/mm-port-serial.c
index 9b74900..3af1b8e 100644
--- a/src/mm-port-serial.c
+++ b/src/mm-port-serial.c
@@ -1270,33 +1270,31 @@ mm_port_serial_is_open (MMPortSerial *self)
{
g_return_val_if_fail (self != NULL, FALSE);
g_return_val_if_fail (MM_IS_PORT_SERIAL (self), FALSE);
return !!self-priv-open_count;
}
-void
-mm_port_serial_close (MMPortSerial *self)
+static void
+_close_internal (MMPortSerial *self, gboolean force)
{
const char *device;
int i;
g_return_if_fail (MM_IS_PORT_SERIAL (self));
-/* If we forced closing the port, open_count will be 0 already.
- * Just return without issuing any warning */
-if (self-priv-forced_close)
-return;
-
-g_return_if_fail (self-priv-open_count 0);
+if (force)
+self-priv-open_count = 0;
+else {
+g_return_if_fail (self-priv-open_count 0);
+self-priv-open_count--;
+}
device = mm_port_get_device (MM_PORT (self));
-self-priv-open_count--;
-
mm_dbg ((%s) device open count is %d (close), device,
self-priv-open_count);
if (self-priv-open_count 0)
return;
if (self-priv-connected_id) {
g_signal_handler_disconnect (self, self-priv-connected_id);
@@ -1398,43 +1396,48 @@ mm_port_serial_close (MMPortSerial *self)
self-priv-cancellable_id);
self-priv-cancellable_id = 0;
}
g_clear_object (self-priv-cancellable);
}
+void
+mm_port_serial_close (MMPortSerial *self)
+{
+g_return_if_fail (MM_IS_PORT_SERIAL (self));
+
+if (!self-priv-forced_close)
+_close_internal (self, FALSE);
+}
+
static void
port_serial_close_force (MMPortSerial *self)
{
-g_return_if_fail (self != NULL);
g_return_if_fail (MM_IS_PORT_SERIAL (self));
/* If already forced to close, return */
if (self-priv-forced_close)
return;
mm_dbg ((%s) forced to close port, mm_port_get_device (MM_PORT
(self)));
/* Mark as having forced the close, so that we don't warn about
incorrect
* open counts */
self-priv-forced_close = TRUE;
-/* If already closed, done */
-if (!self-priv-open_count !self-priv-reopen_ctx)
-return;
-
/* Cancel port reopening if one is running */
port_serial_reopen_cancel (self);
-/* Force the port to close */
-self-priv-open_count = 1;
-mm_port_serial_close (self);
+/* If already closed, done */
+if (self-priv-open_count 0) {
+_close_internal (self, TRUE);
-/* Notify about the forced close status */
-g_signal_emit (self, signals[FORCED_CLOSE], 0);
+/* Notify about the forced close status */
+g_signal_emit (self, signals[FORCED_CLOSE], 0);
+}
}
/*/
/* Reopen */
typedef struct {
MMPortSerial *self;
--
1.9.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ad-Hoc network creation took too long, failing activation
On Wed, 2014-10-08 at 00:10 +0200, poma wrote: Starting Network Manager... info NetworkManager (version 0.9.10.0-5.git20140704.fc21) is starting... info WEXT support is enabled info WiFi hardware radio set enabled info Loaded device plugin: /usr/lib/NetworkManager/libnm-device-plugin-wifi.so info WiFi enabled by radio killswitch; enabled by state file info Networking is enabled by state file Started Network Manager. info (ra0): driver does not support SSID scans (scan_capa 0x00). info (ra0): using WEXT for WiFi device control info (ra0): new 802.11 WiFi device (driver: 'usb' ifindex: 5) info (ra0): exported as /org/freedesktop/NetworkManager/Devices/4 info (ra0): device state change: unmanaged - unavailable (reason 'managed') [10 20 2] info (ra0): preparing device warn (ra0): error 100 getting card mode error [1412709645.317223] [platform/wifi/wifi-utils-wext.c:160] wifi_wext_set_mode(): (ra0): error setting mode 2 Ugh, looks like you're using WEXT, which is historically quite problematic because different drivers expected different sequences of WEXT requests. Any driver that uses WEXT and is not upstream is automatically suspect, unfortunately... info wpa_supplicant started info (ra0) supports 1 scan SSIDs info (ra0): supplicant interface state: starting - ready info (ra0): device state change: unavailable - disconnected (reason 'supplicant-available') [20 30 42] info (ra0): supplicant interface state: ready - disconnected info (ra0) supports 1 scan SSIDs info startup complete info (ra0): supplicant interface state: disconnected - inactive ... info (ra0): disconnecting for new activation request. info (ra0): device state change: activated - deactivating (reason 'none') [100 110 0] info NetworkManager state is now DISCONNECTING info (ra0): device state change: deactivating - disconnected (reason 'none') [110 30 0] info (ra0): deactivating device (reason 'none') [0] info (ra0): canceled DHCP transaction, DHCP client pid 1144 info NetworkManager state is now DISCONNECTED info Activation (ra0) starting connection 'bla' info Activation (ra0) Stage 1 of 5 (Device Prepare) scheduled... warn Connection disconnected (reason -3) info (ra0): supplicant interface state: completed - disconnected info Activation (ra0) Stage 1 of 5 (Device Prepare) started... info (ra0): device state change: disconnected - prepare (reason 'none') [30 40 0] info NetworkManager state is now CONNECTING info Activation (ra0) Stage 2 of 5 (Device Configure) scheduled... info Activation (ra0) Stage 1 of 5 (Device Prepare) complete. info Activation (ra0) Stage 2 of 5 (Device Configure) starting... info (ra0): device state change: prepare - config (reason 'none') [40 50 0] info Activation (ra0/wireless): connection 'bla' has security, and secrets exist. No new secrets needed. info Config: added 'ssid' value 'bla' info Config: added 'mode' value '1' info Config: added 'frequency' value '2412' info Config: added 'key_mgmt' value 'NONE' info Config: added 'auth_alg' value 'OPEN' info Config: added 'wep_key0' value 'omitted' info Config: added 'wep_tx_keyidx' value '0' info Activation (ra0) Stage 2 of 5 (Device Configure) complete. info Config: set interface ap_scan to 2 info (ra0): supplicant interface state: disconnected - associating warn Activation (ra0/wireless): Ad-Hoc network creation took too long, failing activation. The driver did not emit the SIOCGIWAP event, indicating that it had successfully completed Ad-Hoc AP setup. This is a driver bug. info (ra0): device state change: config - failed (reason 'supplicant-timeout') [50 120 11] info NetworkManager state is now DISCONNECTED warn Activation (ra0) failed for connection 'bla' warn Connection disconnected (reason -3) info (ra0): supplicant interface state: associating - disconnected info (ra0): device state change: failed - disconnected (reason 'none') [120 30 0] info (ra0): deactivating device (reason 'none') [0] warn (ra0): error 100 getting card mode error [1412717534.522258] [platform/wifi/wifi-utils-wext.c:160] wifi_wext_set_mode(): (ra0): error setting mode 2 IBSS works via Wicd although not reliable. BTW AP/WPA2, is it possible at all? NM supports AP mode if wpa_supplicant supports it on the device, but given the information you've provided here, the driver looks very fragile and I wouldn't expect it to work. WPA2 may be possible, but again the driver is quite suspect. The driver is just bad, I'm afraid... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ensuring predictable MAC address for bond interface
On Mon, 2014-10-06 at 12:51 -0700, Ed Swierk wrote: I'm using NetworkManager on a server with two wired Ethernet interfaces (eth0 and eth1) configured as slaves of a bond in active-backup mode. I'd like the bond interface to always be assigned eth0's MAC address. This is easy with old-school static network configuration like ifupdown: just make eth0 the first slave of the bond interface, and Linux will copy eth0's MAC address to the bond. When NetworkManager starts up and reads system-interface config files, it creates the bond interface right away, but doesn't add a slave until it notices that the slave's link is up (i.e. carrier is 1). And of course the link state depends on lots of things, like whether a cable is plugged in and the state of the switch or host at the other end. Thus whether eth0 or eth1 gets enslaved to the bond first is unpredictable, meaning the bond interface's MAC address is unpredictable. This is troublesome in some environments, such as ones where a DHCP server assigns IP addresses based on the MAC address of the client. Does setting the primary bond option when in active-backup mode to eth0 make things better? In nm-connection-editor it'll be in the page for Bond options, in nmtui it'll be in about the same place, and in nmcli you'd do: nmcli con mod Bond1 +bond.options primary=eth0 and then re-activate the connection. Let me know if that does/doesn't help. (note; this may only work with 0.9.10+) Dan NetworkManager already treats a bond slave interface differently when its link goes down, leaving it in DISCONNECTED state rather than switching it to UNAVAILABLE. So there's precedent for having a bond interface with one or more link-down slave interfaces. I think the easiest way to achieve a stable MAC address is to extend that behavior to the startup case: as soon as NetworkManager sees an interface that's configured as a bond slave, it should move it from UNAVAILABLE to DISCONNECTED. That way the first configured slave interface, rather than the first one with link up, is enslaved to the bond. I couldn't figure out a way to configure this in NetworkManager 0.9.8.10, nor in mainline code. As a proof of concept, I hacked nm_device_state_changed() in src/nm-device.c: in the second switch(state), UNAVAILABLE case, I force the transition to DISCONNECTED for eth0 and eth1. This works as I'd hoped: both interfaces are enslaved right away, with eth0 always first. I didn't see any easy way to implement this behavior cleanly, though. This new behavior should apply only to bond slave interfaces. At the point where nm_device_state_changed() is called, there's not yet a corresponding connection for eth0 or eth1, so I can't check whether the interface is configured as a bond slave. I thought I'd ask for advice before spending more time on this. Any help would be appreciated! --Ed ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[MM PATCH] port-serial: fix forced closing after b28230411
b28230411 moved up the self-priv-forced_close = TRUE, which
caused mm_port_serial_close() to just return without actually
closing the port and cleaning up.
Also, cancel the reopen separately from closing the port since
the two operations are actually independent of each other.
---
src/mm-port-serial.c | 43 +++
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/src/mm-port-serial.c b/src/mm-port-serial.c
index 9b74900..3af1b8e 100644
--- a/src/mm-port-serial.c
+++ b/src/mm-port-serial.c
@@ -1270,33 +1270,31 @@ mm_port_serial_is_open (MMPortSerial *self)
{
g_return_val_if_fail (self != NULL, FALSE);
g_return_val_if_fail (MM_IS_PORT_SERIAL (self), FALSE);
return !!self-priv-open_count;
}
-void
-mm_port_serial_close (MMPortSerial *self)
+static void
+_close_internal (MMPortSerial *self, gboolean force)
{
const char *device;
int i;
g_return_if_fail (MM_IS_PORT_SERIAL (self));
-/* If we forced closing the port, open_count will be 0 already.
- * Just return without issuing any warning */
-if (self-priv-forced_close)
-return;
-
-g_return_if_fail (self-priv-open_count 0);
+if (force)
+self-priv-open_count = 0;
+else {
+g_return_if_fail (self-priv-open_count 0);
+self-priv-open_count--;
+}
device = mm_port_get_device (MM_PORT (self));
-self-priv-open_count--;
-
mm_dbg ((%s) device open count is %d (close), device,
self-priv-open_count);
if (self-priv-open_count 0)
return;
if (self-priv-connected_id) {
g_signal_handler_disconnect (self, self-priv-connected_id);
@@ -1398,43 +1396,48 @@ mm_port_serial_close (MMPortSerial *self)
self-priv-cancellable_id);
self-priv-cancellable_id = 0;
}
g_clear_object (self-priv-cancellable);
}
+void
+mm_port_serial_close (MMPortSerial *self)
+{
+g_return_if_fail (MM_IS_PORT_SERIAL (self));
+
+if (!self-priv-forced_close)
+_close_internal (self, FALSE);
+}
+
static void
port_serial_close_force (MMPortSerial *self)
{
-g_return_if_fail (self != NULL);
g_return_if_fail (MM_IS_PORT_SERIAL (self));
/* If already forced to close, return */
if (self-priv-forced_close)
return;
mm_dbg ((%s) forced to close port, mm_port_get_device (MM_PORT (self)));
/* Mark as having forced the close, so that we don't warn about incorrect
* open counts */
self-priv-forced_close = TRUE;
-/* If already closed, done */
-if (!self-priv-open_count !self-priv-reopen_ctx)
-return;
-
/* Cancel port reopening if one is running */
port_serial_reopen_cancel (self);
-/* Force the port to close */
-self-priv-open_count = 1;
-mm_port_serial_close (self);
+/* If already closed, done */
+if (self-priv-open_count 0) {
+_close_internal (self, TRUE);
-/* Notify about the forced close status */
-g_signal_emit (self, signals[FORCED_CLOSE], 0);
+/* Notify about the forced close status */
+g_signal_emit (self, signals[FORCED_CLOSE], 0);
+}
}
/*/
/* Reopen */
typedef struct {
MMPortSerial *self;
--
1.9.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] openvpn: add support to change interface name
On Tue, 2014-09-30 at 21:07 +0200, Christian Hesse wrote:
Christian Hesse m...@eworm.de on Mon, 2014/09/29 14:46:
By default interface name is 'tun' or 'tap' with an incrementing number
(tun0, tun1, ... or tap0, tap1, ...). By specifying 'Interface name' in
vpnc config you can change the name to something more descriptice.
The vpnc part has been merge with some changes. So questions arise:
* Do you want to update the UI file for GTK+ 3.4 and get an updated patch for
that?
I just did that and pushed it. Perhaps you wanted to do it yourself? :)
But it's really tedious and I figured you didn't...
* Do you want the interface name widget on Advanced dialog? I suppose yes.
Yeah, lets do that, on the first tab page where stuff like ports and
tun/tap are.
* Any other changes?
One other style change, when there's code like:
+ g_object_set (G_OBJECT (s_con),
+ NM_SETTING_CONNECTION_INTERFACE_NAME,
str, NULL);
if it all fits on one line within about 100 characters, then let's put
it on one line. If it's longer than that, then multi-line, but in that
case lets do some { } and align it like so (two places to do this...):
+ if (str strlen (str)) {
+ g_object_set (G_OBJECT (s_con),
+ NM_SETTING_CONNECTION_INTERFACE_NAME, str,
+ NULL);
+ }
Sound OK? Thanks!
Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] vpnc: add support to change interface name
On Mon, 2014-09-29 at 10:27 +0200, Christian Hesse wrote: By default interface name is 'tun' with an incrementing number (tun0, tun1, ...). By specifying 'Interface name' in vpnc config you can change the name to something more descriptice. Pushed this, thanks! After some consideration though, I moved the interface name UI widget to the Advanced dialog, since I don't think most users would need to enter anything in there. Hopefully that's OK with you :) Dan --- properties/nm-vpnc-dialog.ui | 89 +--- properties/nm-vpnc.c | 43 - src/nm-vpnc-service.c| 13 ++- 3 files changed, 114 insertions(+), 31 deletions(-) diff --git a/properties/nm-vpnc-dialog.ui b/properties/nm-vpnc-dialog.ui index 168782e..6c46785 100644 --- a/properties/nm-vpnc-dialog.ui +++ b/properties/nm-vpnc-dialog.ui @@ -555,7 +555,7 @@ config: DPD idle timeout (our side) 0/property object class=GtkTable id=table2 property name=visibleTrue/property property name=can_focusFalse/property -property name=n_rows8/property +property name=n_rows9/property property name=n_columns3/property property name=column_spacing6/property property name=row_spacing6/property @@ -574,8 +574,8 @@ config: DPD idle timeout (our side) 0/property packing property name=left_attach2/property property name=right_attach3/property -property name=top_attach4/property -property name=bottom_attach5/property +property name=top_attach5/property +property name=bottom_attach6/property /packing /child child @@ -593,8 +593,8 @@ config: DPD idle timeout (our side) 0/property packing property name=left_attach2/property property name=right_attach3/property -property name=top_attach2/property -property name=bottom_attach3/property +property name=top_attach3/property +property name=bottom_attach4/property /packing /child child @@ -611,8 +611,8 @@ config: DPD idle timeout (our side) 0/property packing property name=left_attach1/property property name=right_attach2/property -property name=top_attach5/property -property name=bottom_attach6/property +property name=top_attach6/property +property name=bottom_attach7/property /packing /child child @@ -626,8 +626,8 @@ config: IPSec secret lt;group_passwordgt;/property packing property name=left_attach1/property property name=right_attach2/property -property name=top_attach4/property -property name=bottom_attach5/property +property name=top_attach5/property +property name=bottom_attach6/property property name=y_options/property /packing /child @@ -641,8 +641,8 @@ config: IPSec secret lt;group_passwordgt;/property property name=mnemonic_widgetgroup_password_entry/property /object packing -property name=top_attach4/property -property name=bottom_attach5/property +property name=top_attach5/property +property name=bottom_attach6/property property name=x_optionsGTK_FILL/property property name=y_options/property /packing @@ -657,6 +657,8 @@ config: IPSec secret lt;group_passwordgt;/property property name=mnemonic_widgetgateway_entry/property /object packing +property name=top_attach1/property +property name=bottom_attach2/property property name=x_optionsGTK_FILL/property property name=y_options/property /packing @@ -666,13 +668,27 @@ config: IPSec secret lt;group_passwordgt;/property property name=visibleTrue/property property name=can_focusFalse/property property name=xalign0/property +property name=label translatable=yes_Interface name:/property +property name=use_underlineTrue/property +property
Re: Question about cgdcont -- ip, ipv4v6, ipv6 -- MM-- NM?
On Tue, 2014-09-30 at 21:52 +0200, Thomas Schäfer wrote: Hi, I am testing a little bit ipv6 (v6 only and v4/v6-dualstack) mobile connections via UMTS and LTE. While modemmamanger mmcli -m 0 --simple-connect=apn=internet,ip-type=ipv4v6 mmcli -m 0 --simple-connect=apn=internet,ip-type=ipv6 works. (using qmi, mbim and/or at+cgdcont ) I want to go up - to networkmanager. So I am missing the possibility to configure the apn-type via NM . (gsm section) https://developer.gnome.org/NetworkManager/unstable/ref-settings.html http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/libnm-util/nm-setting-gsm.h How is it possible to set the IP-version? You configure the IPv4 and IPv6 methods, and optionally set may-fail. The logic is in src/devices/wwan/nm-modem.c::nm_modem_get_connection_ip_type(). So, if your modems supports IPV4V6: ip4-method=auto, ip6-method=auto = IPV4V6 ip4-method=auto, ip6-method=ignore = IP ip4-method=disabled, ip6-method=auto = IPV6 If the modem does not support IPV4V6, then NM will use the may-fail property: ip4-method=auto, ip6-method=auto, ip6-may-fail=yes = IP ip4-method=auto, ip6-method=auto, ip4-may-fail=yes = IPV6 Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RTL8188SU(rtl8192su) - unavailable
On Mon, 2014-09-29 at 11:29 +0200, poma wrote: [platform/nm-platform.c:806] nm_platform_link_set_up(): link: setting up 'wlp0s4f1u1' (4) [platform/nm-linux-platform.c:2356] link_change_flags(): link: change 4: flags set 'up' (1) [platform/nm-linux-platform.c:2250] link_change(): Netlink error changing link 4: UP mtu 0 (1) driver 'rtl8192su' udi '/sys/devices/pci:00/:00:04.1/usb2/2-1/2-1:1.0/net/wlp0s4f1u1': No such device (wlp0s4f1u1): preparing device This is likely the core problem, and it's also probably the cause of the wpa_supplicant failures too. You can test this out without NM running by simply doing: ifconfig wlp0s4f1u1 up and see if it returns an error or not. Does it? Does anything show up in 'dmesg'? If we can't get 'ifconfig up' working for the device, clearly NM won't work either... Dan [devices/nm-device.c:6396] nm_device_remove_pending_action(): (wlp0s4f1u1): remove_pending_action (0): 'autoconf6' not pending (expected) [platform/nm-linux-platform.c:1965] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/disable_ipv6' to '1' (current value is identical) [platform/nm-linux-platform.c:1967] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/accept_ra' to '0' (current value is '1') [platform/nm-linux-platform.c:1965] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/wlp0s4f1u1/use_tempaddr' to '0' (current value is identical) [devices/nm-device.c:7024] nm_device_set_hw_addr(): (wlp0s4f1u1): no MAC address change needed [devices/nm-device.c:5095] nm_device_set_ip4_config(): (wlp0s4f1u1): clear IP4Config instance (/org/freedesktop/NetworkManager/IP4Config/0) [devices/nm-device.c:5203] nm_device_set_ip6_config(): (wlp0s4f1u1): clear IP6Config instance (/org/freedesktop/NetworkManager/IP6Config/0) [supplicant-manager/nm-supplicant-manager.c:90] nm_supplicant_manager_iface_get(): (wlp0s4f1u1): creating new supplicant interface [supplicant-manager/nm-supplicant-interface.c:881] interface_add(): (wlp0s4f1u1): adding interface to supplicant [devices/nm-device.c:6342] nm_device_add_pending_action(): (wlp0s4f1u1): add_pending_action (1): 'waiting for supplicant' [nm-manager.c:718] check_if_startup_complete(): check_if_startup_complete returns FALSE because of wlp0s4f1u1 [nm-device-wifi.c:1192] is_available(): (wlp0s4f1u1): not available because supplicant interface not ready [devices/nm-device.c:6705] _set_state_full(): (wlp0s4f1u1): device not yet available for transition to DISCONNECTED [nm-manager.c:718] check_if_startup_complete(): check_if_startup_complete returns FALSE because of wlp0s4f1u1 [devices/nm-device.c:6342] nm_device_add_pending_action(): (wlp0s4f1u1): add_pending_action (2): 'autoactivate' [devices/nm-device.c:6376] nm_device_remove_pending_action(): (wlp0s4f1u1): remove_pending_action (1): 'autoactivate' [nm-manager.c:718] check_if_startup_complete(): check_if_startup_complete returns FALSE because of wlp0s4f1u1 [supplicant-manager/nm-supplicant-interface.c:856] interface_add_cb(): (wlp0s4f1u1): error adding interface: wpa_supplicant couldn't grab this interface. (wlp0s4f1u1): supplicant interface state: starting - down [devices/nm-device.c:6376] nm_device_remove_pending_action(): (wlp0s4f1u1): remove_pending_action (0): 'waiting for supplicant' [supplicant-manager/nm-supplicant-manager.c:90] nm_supplicant_manager_iface_get(): (wlp0s4f1u1): creating new supplicant interface [supplicant-manager/nm-supplicant-interface.c:881] interface_add(): (wlp0s4f1u1): adding interface to supplicant [devices/nm-device.c:6342] nm_device_add_pending_action(): (wlp0s4f1u1): add_pending_action (1): 'waiting for supplicant' [supplicant-manager/nm-supplicant-manager.c:182] get_capabilities_cb(): AP mode is supported [supplicant-manager/nm-supplicant-manager.c:194] get_capabilities_cb(): EAP-FAST is supported [supplicant-manager/nm-supplicant-interface.c:856] interface_add_cb(): (wlp0s4f1u1): error adding interface: wpa_supplicant couldn't grab this interface. etc. etc.. etc... - nmcli device DEVICE TYPE STATECONNECTION wlp0s4f1u1 wifi unavailable -- poma -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/4] libnm-glib: make Last Seen property available to libnm-glib and from DBus.
On Fri, 2014-09-26 at 10:32 +0100, Mathieu Trudel-Lapierre wrote: On Mon, Sep 22, 2014 at 5:21 PM, Thomas Haller thal...@redhat.com wrote: [...] the value priv-last_seen (together with nm_access_point_get_last_seen() and nm_ap_set_last_seen()) are time stamps as returned by nm_utils_get_monotonic_timestamp_s(). Exposing these absolute values (without a reference point) to another process is meaningless. I disagree, maybe it's not meaningful to compare directly to boot time; but it's sufficient to compare values between themselves to figure out which networks are the newest. That's currently what we're mostly interested in. I'm not sure if there would be other use cases; but the idea is especially to provide a way for applications to sort accesspoints by age and avoid using those that have been in scan results before, but not necessarily old enough or disappeared to be culled from the scan list just yet. Options: 1) expose the timestamps to absolute times in seconds since 1970 (posix time). Note that gint (with 32bit) is to short to represent that property. Downside: timestamps are all wrong in case of resetting the clock. As a note, I actually ported this patch to NM master, but it really has been tested on 0.9.8.8. I think we're at the point here where what happens is that the timestamps on 0.9.8.8 are actually still retrieved via time(NULL) initially, so this is basically what was achieved. 2) expose time stamps to clock_gettime(CLOCK_BOOTTIME) or clock_gettime(CLOCK_MONOTONIC). Downside: timestamps are only meaningful on the very same host. Its quite uncommon to expose DBUS over the network, but I think we don't want to restrict that. CLOCK_MONOTONIC is more commonly known then CLOCK_BOOTTIME, but has the additional downside of being wrong after hibernate. FWIW, I vote for this solution (CLOCK_BOOTTIME specifically); it seems an acceptable compromise that the values are only meaningful on the host, since the list of accesspoints is also going to be only meaningful on that host -- another might not see some, etc. [...] Also note that priv-last_seen==0 means never seen. Both for 1) and 2) above, 0 can represent a valid value. Arguably for 1), We could define that 0 (1970-01-01T00:00:00) means never seen. But maybe it would be better to map never seen to -1 -- thinking of booting up a machine with drained CMOS battery that forgot the time stamp and starts ticking at posix-time 0. With CLOCK_BOOTTIME, wouldn't 0 also be a value unlikely enough that we can consider it never seen? Seems to me like even if NetworkManager started at 0; it's quite unlikely that by the time the system has gotten to start scanning it would still be at 0. I'll update the patch shortly to fix at least Nathanael's comment re: the wrong string; while we get to agree on exactly how the values should display. Yes, at some point it may be useful to see the scan list over a network, like with Cockpit. So we can't preclude that use-case. Even since the Epoch doesn't work, because the host and remote system clocks might not be synchronized. So we should really keep this to arbitrary seconds-based units of some kind. In the end, I think CLOCK_BOOTTIME is probably the best, and we can also provide some kind of WiFi.GetLastSeenNow() method that literally returns the value of CLOCK_GETTIME, which then remote clients could match up with a system clock and cache that difference to determine the actual age of the AP. Thoughts? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/4] libnm-glib: make Last Seen property available to libnm-glib and from DBus.
On Thu, 2014-09-04 at 22:04 -0400, Mathieu Trudel-Lapierre wrote:
Signed-off-by: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
---
introspection/nm-access-point.xml | 3 +++
libnm-glib/libnm-glib.ver | 1 +
libnm-glib/nm-access-point.c | 35 +++
libnm-glib/nm-access-point.h | 2 ++
src/devices/wifi/nm-wifi-ap.c | 23 ++-
src/devices/wifi/nm-wifi-ap.h | 1 +
6 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/introspection/nm-access-point.xml
b/introspection/nm-access-point.xml
index 21f238f..a2ab2f4 100644
--- a/introspection/nm-access-point.xml
+++ b/introspection/nm-access-point.xml
@@ -30,6 +30,9 @@
property name=Strength type=y access=read
tp:docstringThe current signal quality of the access point, in
percent./tp:docstring
/property
+property name=LastSeen type=i access=read
+ tp:docstringThe current signal quality of the access point, in
percent./tp:docstring
+/property
Any particular reason to make it int instead of unsigned? Would
LastSeen ever be negative?
Dan
signal name=PropertiesChanged
arg name=properties type=a{sv} tp:type=String_Variant_Map
diff --git a/libnm-glib/libnm-glib.ver b/libnm-glib/libnm-glib.ver
index c0f1bba..20722e8 100644
--- a/libnm-glib/libnm-glib.ver
+++ b/libnm-glib/libnm-glib.ver
@@ -11,6 +11,7 @@ global:
nm_access_point_get_flags;
nm_access_point_get_frequency;
nm_access_point_get_hw_address;
+ nm_access_point_get_last_seen;
nm_access_point_get_max_bitrate;
nm_access_point_get_mode;
nm_access_point_get_rsn_flags;
diff --git a/libnm-glib/nm-access-point.c b/libnm-glib/nm-access-point.c
index b462a6b..b971190 100644
--- a/libnm-glib/nm-access-point.c
+++ b/libnm-glib/nm-access-point.c
@@ -52,6 +52,7 @@ typedef struct {
NM80211Mode mode;
guint32 max_bitrate;
guint8 strength;
+ gint32 last_seen;
} NMAccessPointPrivate;
enum {
@@ -66,6 +67,7 @@ enum {
PROP_MAX_BITRATE,
PROP_STRENGTH,
PROP_BSSID,
+ PROP_LAST_SEEN,
LAST_PROP
};
@@ -265,6 +267,23 @@ nm_access_point_get_strength (NMAccessPoint *ap)
}
/**
+ * nm_access_point_get_last_seen:
+ * @ap: a #NMAccessPoint
+ *
+ * Gets the last seen timestamp for the access point.
+ *
+ * Returns: the last seen time in seconds
+ **/
+gint32
+nm_access_point_get_last_seen (NMAccessPoint *ap)
+{
+ g_return_val_if_fail (NM_IS_ACCESS_POINT (ap), 0);
+
+ _nm_object_ensure_inited (NM_OBJECT (ap));
+ return NM_ACCESS_POINT_GET_PRIVATE (ap)-last_seen;
+}
+
+/**
* nm_access_point_connection_valid:
* @ap: an #NMAccessPoint to validate @connection against
* @connection: an #NMConnection to validate against @ap
@@ -481,6 +500,9 @@ get_property (GObject *object,
case PROP_STRENGTH:
g_value_set_uchar (value, nm_access_point_get_strength (ap));
break;
+ case PROP_LAST_SEEN:
+ g_value_set_int (value, nm_access_point_get_last_seen (ap));
+ break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
@@ -511,6 +533,7 @@ register_properties (NMAccessPoint *ap)
{ NM_ACCESS_POINT_MODE,priv-mode },
{ NM_ACCESS_POINT_MAX_BITRATE, priv-max_bitrate },
{ NM_ACCESS_POINT_STRENGTH,priv-strength },
+ { NM_ACCESS_POINT_LAST_SEEN, priv-last_seen },
{ NULL },
};
@@ -670,4 +693,16 @@ nm_access_point_class_init (NMAccessPointClass *ap_class)
0, G_MAXUINT8, 0,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS));
+
+ /**
+ * NMAccessPoint:last-seen:
+ *
+ * The last seen timestamp of the access point.
+ **/
+ g_object_class_install_property
+ (object_class, PROP_LAST_SEEN,
+ g_param_spec_int (NM_ACCESS_POINT_LAST_SEEN, , ,
+0, G_MAXINT32, 0,
+G_PARAM_READABLE |
+ G_PARAM_STATIC_STRINGS));
}
diff --git a/libnm-glib/nm-access-point.h b/libnm-glib/nm-access-point.h
index d3150f8..d8efad1 100644
--- a/libnm-glib/nm-access-point.h
+++ b/libnm-glib/nm-access-point.h
@@ -46,6 +46,7 @@ G_BEGIN_DECLS
#define NM_ACCESS_POINT_MODEmode
#define NM_ACCESS_POINT_MAX_BITRATE max-bitrate
#define NM_ACCESS_POINT_STRENGTHstrength
+#define NM_ACCESS_POINT_LAST_SEEN last-seen
/* DEPRECATED */
#define NM_ACCESS_POINT_HW_ADDRESS hw-address
@@ -80,6 +81,7 @@ guint32nm_access_point_get_frequency
(NMAccessPoint *ap);
NM80211Modenm_access_point_get_mode (NMAccessPoint *ap);
guint32
