Re: NM and IETF MIF working group

[Dan Williams]

On Mon, 2015-09-28 at 22:29 +0200, Stjepan Groš wrote:
> On 28.09.2015 11:48, David Woodhouse wrote:
> > On Mon, 2015-09-07 at 12:05 +0200, Stjepan Groš wrote:
> >> Two colleagues of mine and I started to work on MIF implementation on 
> >> Fedora. In case someone doesn't know, IETF MIF working group (
> >> https://datatracker.ietf.org/wg/mif/charter/) tries to solve the 
> >> problems of a single node having multiple parallel connections to 
> >> different destinations (Internet, VPN, some private networks, etc.).
> > Please ensure you take proxies into account.
> >
> > If my local DHCP server handed me a proxy PAC file, and if I connect to
> > a split-tunnel VPN which *also* provides a proxy PAC file, I expect
> > that requests I make to to the company VPN (within its domain names and
> > IP ranges) to use one proxy configuration, while requests to the
> > Internet at large should use my local proxy.
> >
> 
> If I understand it correctly, PAC information received from DHCP is send
> by NM via DBus, but otherwise not used in any way? So, it is necessary
> to use some tool like proxydriver
> (https://github.com/jimlawton/proxydriver) that will modify system
> settings based on this info?

Yes, NM gets the information from DHCP and exposes it on D-Bus but does
not make any further use of it.  That's up to whatever proxy
implementation you have that wants to process PAC files, at least at
this point.  I think that's the point of libproxy/pacrunner though,
where apps need to say "how must I access http://it.foobar.com"; and the
proxy library consults the list of methods to get there, and returns an
answer like "you must use this proxy" or "just go there directly".  Apps
do need to be smarter here.

Dan

> In any case, this is interesting info because we didn't though of it.
> Namely, if browser is configured to use system proxy settings and it is
> placed within new namespace, then it might happen that wrong proxy is
> used, or global proxy settings are mixed up.
> 
> SG
> ___
> 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: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Wed, 2015-09-30 at 15:28 -0400, Derek Atkins wrote:
> Dan,
> 
> On Wed, September 30, 2015 12:44 pm, Dan Williams wrote:
> > On Wed, 2015-09-30 at 12:25 -0400, Derek Atkins wrote:
> >> Dan,
> >>
> >> Dan Williams  writes:
> >>
> >> I.e., just to make sure I understand correctly, in order to get what I
> >> want I should just create /etc/sysconfig/network-scripts/ifcfg-eth0:0
> >> and let NM manage my alias that way?  Do I need to do anything special
> >> to get NM to notice it, or it will do so automagically on the next
> >> restart/reboot?
> >
> > There are some alias examples here, FWIW:
> >
> > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/tests/network-scripts
> >
> > And all that's really required is "nmcli con reload", you shouldn't ever
> > need to restart NetworkManager to get config changes taken into account.
> 
> I added this config file but it's not bringing up eth0:0.
> 
> # cat /etc/sysconfig/network-scripts/ifcfg-eth0:0
> DEVICE=eth0:0
> IPADDR=192.168.x.y   (yes, x.y are numbers)
> BOOTPROTO=none
> ONBOOT=yes
> IPV6INIT=no
> #
> 
> What am I missing?  Do I need the base ifcfg-eth0 file, too?  (That file
> was not created by anaconda).  Or do I need some additional fields because
> there is no ifcfg-eth0?  Or do I need to tell NM to bring it up?

Yes, you need a matching ifcfg file for the base interface.  So you need
both ifcfg-eth0 and ifcfg-eth0:0.  See the examples, eg ifcfg-aliasem0
and ifcfg-aliasem0:1.

The alias file should only have DEVICE and IPADDR fields; and DEVICE
must match that of the parent ifcfg file.  They are intimately tied
together in the old initscripts, and the ifcfg-rh plugin remains
compatible with those.

When NetworkManager sees the base file, it will also look for alias
files, and will add the IP address from the alias file to the main
connection's IP address list along with the label.  So even with two
ifcfg files, you will only have one connection and you should see *both*
IP addresses in that one connection.  When the connection is activated,
NM sends the label to the kernel, so /sbin/ip will show both addresses
on one interface, but /sbin/ifconfig will show two interfaces each with
one address, per its ignorance of the real situation.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: AP with Radius and VLAN?

[Dan Williams]

On Tue, 2015-09-29 at 21:37 -0700, Frank Rizzo wrote:
> Hey guys!
> 
> I'm using Ubuntu 14.04 LTS, and using the applet I am able to do basic  
> configuration of an AP.  I can then start it, connect to it, and use it.   
> But this base config is very simplistic.  I need something more.  I need  
> Radius server authentication, and VLANs.  (Things that are supported  
> through hostapd).
> 
> Does anyone have an example config that I can base mine upon?

NetworkManager only supports wpa_supplicant's lightweight AP mode and is
not intended as a full-fledged WiFi access point.  For that, you'd want
to configure & run hostapd itself, and make NM ignore the wifi interface
through the config file and the "unmanaged-devices" key.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Wed, 2015-09-30 at 12:25 -0400, Derek Atkins wrote:
> Dan,
> 
> Dan Williams  writes:
> 
> >> Could you explain more detail on how to add "label xxx" to the nmcli
> >> command (which you inconveniently cut out of your reply, so I've
> >> included it below)?  I cannot find any reference to "label" in the nmcli
> >> documentation.
> >> 
> >>   nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.x.y/24"
> >
> > If you really do need address labels (eg, interface aliases) then
> > NetworkManager has limited support for them.  If you don't truly need
> > address labels, then I wouldn't use them.  Anyway, NM supports address
> > labels, but only when they are set via ifcfg "alias" files.  They
> > currently cannot be added via nmcli or set via the 'keyfile' plugin,
> > though that's just a case of "didn't implement yet" rather than anything
> > else.
> 
> I.e., just to make sure I understand correctly, in order to get what I
> want I should just create /etc/sysconfig/network-scripts/ifcfg-eth0:0
> and let NM manage my alias that way?  Do I need to do anything special
> to get NM to notice it, or it will do so automagically on the next
> restart/reboot?

There are some alias examples here, FWIW:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/tests/network-scripts

And all that's really required is "nmcli con reload", you shouldn't ever
need to restart NetworkManager to get config changes taken into account.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: failure with bridge devices

[Dan Williams]

On Wed, 2015-09-30 at 09:59 +0200, Olaf Hering wrote:
> Am 29.09.2015 um 13:21 schrieb Jirka Klimes:
> > On Mon, 28 Sep 2015 09:05:02 +0200
> > Olaf Hering  wrote:
> >> So my questions:
> >> Are there known bugs in the cooperation between NM and GNOME?
> > I don't think there is a known serious issue.
> 
> At least GNOME 3.16 is unable to do anything with bridges, except that
> they can be configured.
> 
> >> Are bridge devices fully supported? If so, why did NM not bringup
> >> onboard before configuring bridge?
> > Yes, bridge configurations are supported. You might got confused by
> > the fact bringing up a bridge profile does not automatically bring up
> > its slaves. Basically, you need to connect all slaves (bridge master
> > will be connected as a dependency).
> > 
> > But, as you have found there is a new property to influence the
> > behaviour (connection.autoconnect-slaves). When you set it to '1' you
> > can activate bridge and its slaves will be activated too.
> 
> Why is it off by default? What is the point of that behaviour?

Backwards compatibility, an intention to replicate the behavior of
various legacy network initscripts that had the same behavior (where eg
'ifup br0' after boot didn't bring up slaves), and because it's not
always the case that you want every single slave configuration that
references 'br0' to be started when br0 starts.  In general, NM tries to
be less destructive by default, and allow you to opt into destruction :)

(which might be new to some people, but that's the goal for the last 4
years or so)

Dan

> >> Below is the output of what I configured with 'nm-connection-editor'.
> >> Why is that output even localized?!
> > What is the issue with localization/no-localization?
> 
> Its translated at the wrong layer. But after all, they also gave us
> ~/Schreibtisch, ~/ビデオ, ~/Público and other odd directory names. So it
> just makes sense to translate property names as well. I think in the
> future we will get /proc/версия too...
> 
> Olaf
> ___
> 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: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Wed, 2015-09-30 at 10:15 -0400, Derek Atkins wrote:
> Andrei,
> 
> Andrei Borzenkov  writes:
> 
> > 29.09.2015 20:54, Dan Williams пишет:
> >>
> >>> Basically I want to automate NM doing, effectively:
> >>>
> >>>ifconfig eth0:0 192.168.x.y
> >>
> >> Don't do this with interface aliases; the kernel is perfectly capable of
> >> using more than one address on the same interface.  Simply do:
> >>
> >> ip addr add 192.168.x.y/24 dev eth0
> >>
> >> and magically you'll have two.
> >>
> >
> >
> > This makes addresses invisible in ifconfig output and that may confuse
> > legacy software (I know about at least one such case). Adding "label
> > xxx" will emulate legacy aliases enough to make them appear as
> > "normal" interface.
> 
> Could you explain more detail on how to add "label xxx" to the nmcli
> command (which you inconveniently cut out of your reply, so I've
> included it below)?  I cannot find any reference to "label" in the nmcli
> documentation.
> 
>   nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.x.y/24"

If you really do need address labels (eg, interface aliases) then
NetworkManager has limited support for them.  If you don't truly need
address labels, then I wouldn't use them.  Anyway, NM supports address
labels, but only when they are set via ifcfg "alias" files.  They
currently cannot be added via nmcli or set via the 'keyfile' plugin,
though that's just a case of "didn't implement yet" rather than anything
else.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Wed, 2015-09-30 at 06:26 +0300, Andrei Borzenkov wrote:
> 29.09.2015 20:54, Dan Williams пишет:
> >
> >> Basically I want to automate NM doing, effectively:
> >>
> >>ifconfig eth0:0 192.168.x.y
> >
> > Don't do this with interface aliases; the kernel is perfectly capable of
> > using more than one address on the same interface.  Simply do:
> >
> > ip addr add 192.168.x.y/24 dev eth0
> >
> > and magically you'll have two.
> >
> 
> 
> This makes addresses invisible in ifconfig output and that may confuse 
> legacy software (I know about at least one such case). Adding "label 
> xxx" will emulate legacy aliases enough to make them appear as "normal" 
> interface.

Yes, that is a downside.  However, the kernel functionality underlying
this, address labels, is only for tricking ifconfig.  The alias
interfaces are not normal interfaces and changes made to them affect all
other alias interfaces.  No other tools present this view of the world,
and the upstream kernel is only keeping this functionality for backwards
compatibility.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Tue, 2015-09-29 at 12:16 -0400, Derek Atkins wrote:
> Hi,
> 
> I've got an esoteric NM question.  I've got two distinct networks that
> share an ethernet fabric (poor man's vlans).  I have a F22 server that I
> want to put on both networks.  It's currently configured to use DHCP for
> the primary network (and my DHCP server provides a static address).
> 
> AFAICT there's really no way to get DHCP to provide two addresses, so
> I'd like to set up a secondary IP statically using nmcli (I did say this
> was a server, right?)

Correct.  DHCPv4 cannot provide more than one IP address.  (DHCPv6 can,
however).

> Basically I want to automate NM doing, effectively:
> 
>   ifconfig eth0:0 192.168.x.y

Don't do this with interface aliases; the kernel is perfectly capable of
using more than one address on the same interface.  Simply do:

ip addr add 192.168.x.y/24 dev eth0

and magically you'll have two.

> I know I can add a second IP to eth0 via:
> 
>   nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.x.y/24"

This is exactly what you do.  Keep the ipv4.method = "auto" however,
that's how DHCP gets signaled.

> But I have no idea how this would interact with the primary address
> being obtained by DHCP.

What should happen is that DHCP will provide everything it currently
does, including the primary IP address, gateway, DNS, etc, and the only
change will be that a second IP address is added to the interface.  You
won't see this address with ifconfig though, because it's stupid.
Use /sbin/ip to see it.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: vpn password stored in plain text

[Dan Williams]

On Mon, 2015-09-28 at 17:57 +0200, Olaf Hering wrote:
> Am 28.09.2015 um 17:00 schrieb Dan Williams:
> > On Mon, 2015-09-28 at 09:32 +0200, Olaf Hering wrote:
> >> Why is the VPN password stored in plain text in
> >> /etc/NetworkManager/system-connections? Is there a way to let the GUI
> >> ask for it every time?
> > 
> > Note that the file is read-only by root.  If somebody has root on your
> > machine, they can do a lot more than read your password.
> 
> If the disk gets stolen the password is accessible. Thanks for your
> other suggestions, will work through them.

Yes, that is correct.  Although best practices suggest full-disk
encryption on anything that can walk away, plus two-factor "something
you know and something you have" for VPNs.  But yes, setting the flags
in the file and removing the password should ensure that the password is
not stored on-disk.  You can also set the flags to '1' (agent-owned) and
the common agents like GNOME and KDE will store the password in their
respective keyrings/wallets that is protected by another password.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: vpn password stored in plain text

[Dan Williams]

On Mon, 2015-09-28 at 09:32 +0200, Olaf Hering wrote:
> Why is the VPN password stored in plain text in
> /etc/NetworkManager/system-connections? Is there a way to let the GUI
> ask for it every time?

Note that the file is read-only by root.  If somebody has root on your
machine, they can do a lot more than read your password.  It's stored
there because no "password flags" have been set for the password that
tell NM where to get it from.

If you set the "agent-owned" flag and the "always ask" flags on the
password, either through the GUI or by editing the file in /etc, then NM
will ask an agent for the password every time.  Most desktop
environments have an agent (eg, GNOME and KDE have their own) and
there's also nm-applet.

For vpnc for example, the user password is "xauthpassword" and the
corresponding item to ask for it every time would be
"xauthpassword-flags=3".  For OpenVPN the user password is "password"
and the corresponding item to ask for it every time is
"password-flags=3".

See also 'man nm-settings' and look for the "Secret flag types" section
near the bottom.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Network Manager Fails to control Wi-Fi

[Dan Williams]

On Fri, 2015-09-25 at 11:28 +0530, Ramprasad Vempati wrote:
> Thanks Dan. But can you tell me how will Network-Manager find out PID
> of wpa_supplicant? Is it via:/run/sendsigs.omit.d/wpasupplicant.pid ,
> which is from below file? If yes, as long as I remove
> "/sbin/wpa_supplicant" also, Network-Manager shouldn't be able to
> control Wi-Fi, right?

NetworkManager doesn't care about the PID of the supplicant, because
it's using the D-Bus interface to talk to it.  When the supplicant
starts its D-Bus service enabled, it talks to dbus-daemon and says "hey,
I'm fi.w1.wpa_supplicant and I'm ready!".  dbus-daemon broadcasts that
to all other D-Bus clients like NetworkManager.  If the supplicant is
started already when NM starts, then NM asks dbus-daemon "hey, is
fi.w1.wpa_supplicant around?".  So there's no pid files involved.

Instead, to make sure the supplicant and NM cannot talk, make sure you
turn off the D-Bus interface, which you can do by either:

1) removing the "-u" option
from /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service

2) running a different supplicant that isn't built with the D-Bus
interface in the code, or is run without the "-u" option

Dan

> cat /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service
> [D-BUS Service]
> Name=fi.w1.wpa_supplicant1
> Exec=/sbin/wpa_supplicant -B -P /run/sendsigs.omit.d/wpasupplicant.pid
> -u -s -O /var/run/wpa_supplicant
> User=root
> 
> -ram
> 
> 
> On Thu, Sep 24, 2015 at 7:57 PM, Dan Williams  wrote:
> > Since NM couldn't talk to the
> > supplicant, it will essentially ignore the WiFi interfaces and keep them
> > in the "unavailable" state.


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Network Manager Fails to control Wi-Fi

[Dan Williams]

On Thu, 2015-09-24 at 14:59 +0530, Ramprasad Vempati wrote:
> Thanks Dan. First reason is the cause of the error.  I mean
> wpa_supplicant is not present @ /usr/sbin,After I keep wpa_supplicant
> with dbus interface enabled, I could see wpa_supplicant started
> automatically by Network Manager.
> 
> But wpa_supplicant was present in /usr/local/sbin, but it was not
> compiled with dbus interface. Thus network-manager was not able to
> talk? Or if wpa_supplicant is not present, there is no way
> network-manager controlling Wi-Fi Interface?

If you're trying to get NM to ignore wifi interfaces, it would probably
work to build a supplicant without the D-Bus interface, and use that
supplicant for your custom stuff.  Since NM couldn't talk to the
supplicant, it will essentially ignore the WiFi interfaces and keep them
in the "unavailable" state.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Understanding How Networking Manager Manages Wi-Fi

[Dan Williams]

On Wed, 2015-09-23 at 23:24 +0530, Ramprasad Vempati wrote:
> Thanks Dan. Looks like "unmanaged-devices" works for me. But can I
> give wildcard mac-address? I mean can I say something like :
> 00:11:22:XX:XX:XX?

It's been progressively expanded with newer versions of NM; look at 'man
NetworkManager.conf' for details on what your NM version supports.  I
don't think you can do partially wildcarded MAC addresses, but you can
do stuff like:

unmanaged-devices=interface-name:em4
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth2

with NM 1.0.2 and later you can also define udev rules that make devices
unmanaged, and that allows much greater flexibility.

Dan

> On Wed, Sep 23, 2015 at 12:29 AM, Dan Williams  wrote:
> > On Tue, 2015-09-22 at 23:41 +0530, Ramprasad Vempati wrote:
> >> Thanks Dan for quick reply. Could you also let me know is this
> >> interaction to wpa_supplicant is controlled by some config file or is
> >> it embedded with-in binary?
> >
> > NM generates the supplicant configuration from its own internal
> > configuration, which is stored in /etc in various places depending on
> > your distro.
> >
> >> And can I configure Network Manager not to manage any of Wi-Fi
> >> Networks but just Wired networks?  If yes, can you help me how can I
> >> do that?
> >
> > You can tell NM to ignore any interface through its configuration file,
> > by setting "unmanaged-devices" (see man NetworkManager.conf) or by
> > tagging all wifi devices with a udev rule to tell NM to ignore them.
> >
> > Dan
> >
> >> And in that case I'm assuming Network Manager won't even start 
> >> wpa_supplicant.
> >>
> >>
> >> On Tue, Sep 22, 2015 at 8:33 PM, Dan Williams  wrote:
> >> > On Tue, 2015-09-22 at 19:54 +0530, Ramprasad Vempati wrote:
> >> >> Hi,
> >> >>
> >> >> I'm interested to understand the flow, in terms of how Network-Manager
> >> >> controls Wi-Fi. As far as I know Network Manager talks to
> >> >> wpa_supplicant.
> >> >
> >> > Yes, through the D-Bus IPC protocol, which many services on Linux use.
> >> >
> >> >> But I'm interested in more details. Like how Network-manager starts
> >> >> wpa_supplicant?
> >> >
> >> > Through D-Bus service activation.  Even if the supplicant is not yet
> >> > started, NM asks the supplicant a question, and the D-Bus daemon will
> >> > hold the request, start the supplicant, and pass the request along when
> >> > it's ready.
> >> >
> >> >> And another case I would like to understand is, if I kill
> >> >> wpa_supplicant that's started by Network-Manager and also remove
> >> >> wpa_supplicant from /sbin, but run wpa_supplicant from another folder,
> >> >> does Network-manager finds him & tries to control?
> >> >
> >> > Yes, as long as you've built the supplicant with the D-Bus control
> >> > interface enabled (CONFIG_CTRL_IFACE_DBUS_NEW), and you've started the
> >> > supplicant with the "-u" option to enable it at runtime.
> >> >
> >> > Dan
> >> >
> >> >> I tried google to get this information. But I couldn't find any useful
> >> >> information.
> >> >>
> >> >> Can one of you help?
> >> >>
> >> >> Thanks,
> >> >> Ram
> >> >> ___
> >> >> 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: Understanding How Networking Manager Manages Wi-Fi

[Dan Williams]

On Wed, 2015-09-23 at 16:43 -0500, Dan Williams wrote:
> On Wed, 2015-09-23 at 23:24 +0530, Ramprasad Vempati wrote:
> > Thanks Dan. Looks like "unmanaged-devices" works for me. But can I
> > give wildcard mac-address? I mean can I say something like :
> > 00:11:22:XX:XX:XX?
> 
> It's been progressively expanded with newer versions of NM; look at 'man
> NetworkManager.conf' for details on what your NM version supports.  I
> don't think you can do partially wildcarded MAC addresses, but you can
> do stuff like:

This reply got cut off, see my other one for more info.

Dan

> > On Wed, Sep 23, 2015 at 12:29 AM, Dan Williams  wrote:
> > > On Tue, 2015-09-22 at 23:41 +0530, Ramprasad Vempati wrote:
> > >> Thanks Dan for quick reply. Could you also let me know is this
> > >> interaction to wpa_supplicant is controlled by some config file or is
> > >> it embedded with-in binary?
> > >
> > > NM generates the supplicant configuration from its own internal
> > > configuration, which is stored in /etc in various places depending on
> > > your distro.
> > >
> > >> And can I configure Network Manager not to manage any of Wi-Fi
> > >> Networks but just Wired networks?  If yes, can you help me how can I
> > >> do that?
> > >
> > > You can tell NM to ignore any interface through its configuration file,
> > > by setting "unmanaged-devices" (see man NetworkManager.conf) or by
> > > tagging all wifi devices with a udev rule to tell NM to ignore them.
> > >
> > > Dan
> > >
> > >> And in that case I'm assuming Network Manager won't even start 
> > >> wpa_supplicant.
> > >>
> > >>
> > >> On Tue, Sep 22, 2015 at 8:33 PM, Dan Williams  wrote:
> > >> > On Tue, 2015-09-22 at 19:54 +0530, Ramprasad Vempati wrote:
> > >> >> Hi,
> > >> >>
> > >> >> I'm interested to understand the flow, in terms of how Network-Manager
> > >> >> controls Wi-Fi. As far as I know Network Manager talks to
> > >> >> wpa_supplicant.
> > >> >
> > >> > Yes, through the D-Bus IPC protocol, which many services on Linux use.
> > >> >
> > >> >> But I'm interested in more details. Like how Network-manager starts
> > >> >> wpa_supplicant?
> > >> >
> > >> > Through D-Bus service activation.  Even if the supplicant is not yet
> > >> > started, NM asks the supplicant a question, and the D-Bus daemon will
> > >> > hold the request, start the supplicant, and pass the request along when
> > >> > it's ready.
> > >> >
> > >> >> And another case I would like to understand is, if I kill
> > >> >> wpa_supplicant that's started by Network-Manager and also remove
> > >> >> wpa_supplicant from /sbin, but run wpa_supplicant from another folder,
> > >> >> does Network-manager finds him & tries to control?
> > >> >
> > >> > Yes, as long as you've built the supplicant with the D-Bus control
> > >> > interface enabled (CONFIG_CTRL_IFACE_DBUS_NEW), and you've started the
> > >> > supplicant with the "-u" option to enable it at runtime.
> > >> >
> > >> > Dan
> > >> >
> > >> >> I tried google to get this information. But I couldn't find any useful
> > >> >> information.
> > >> >>
> > >> >> Can one of you help?
> > >> >>
> > >> >> Thanks,
> > >> >> Ram
> > >> >> ___
> > >> >> 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: Understanding How Networking Manager Manages Wi-Fi

[Dan Williams]

On Wed, 2015-09-23 at 23:24 +0530, Ramprasad Vempati wrote:
> Thanks Dan. Looks like "unmanaged-devices" works for me. But can I
> give wildcard mac-address? I mean can I say something like :
> 00:11:22:XX:XX:XX?

It's been progressively expanded with newer versions of NM; look at 'man
NetworkManager.conf' for details on what your NM version supports.  I
don't think you can do partially wildcarded MAC addresses, but you can
do stuff like:


> On Wed, Sep 23, 2015 at 12:29 AM, Dan Williams  wrote:
> > On Tue, 2015-09-22 at 23:41 +0530, Ramprasad Vempati wrote:
> >> Thanks Dan for quick reply. Could you also let me know is this
> >> interaction to wpa_supplicant is controlled by some config file or is
> >> it embedded with-in binary?
> >
> > NM generates the supplicant configuration from its own internal
> > configuration, which is stored in /etc in various places depending on
> > your distro.
> >
> >> And can I configure Network Manager not to manage any of Wi-Fi
> >> Networks but just Wired networks?  If yes, can you help me how can I
> >> do that?
> >
> > You can tell NM to ignore any interface through its configuration file,
> > by setting "unmanaged-devices" (see man NetworkManager.conf) or by
> > tagging all wifi devices with a udev rule to tell NM to ignore them.
> >
> > Dan
> >
> >> And in that case I'm assuming Network Manager won't even start 
> >> wpa_supplicant.
> >>
> >>
> >> On Tue, Sep 22, 2015 at 8:33 PM, Dan Williams  wrote:
> >> > On Tue, 2015-09-22 at 19:54 +0530, Ramprasad Vempati wrote:
> >> >> Hi,
> >> >>
> >> >> I'm interested to understand the flow, in terms of how Network-Manager
> >> >> controls Wi-Fi. As far as I know Network Manager talks to
> >> >> wpa_supplicant.
> >> >
> >> > Yes, through the D-Bus IPC protocol, which many services on Linux use.
> >> >
> >> >> But I'm interested in more details. Like how Network-manager starts
> >> >> wpa_supplicant?
> >> >
> >> > Through D-Bus service activation.  Even if the supplicant is not yet
> >> > started, NM asks the supplicant a question, and the D-Bus daemon will
> >> > hold the request, start the supplicant, and pass the request along when
> >> > it's ready.
> >> >
> >> >> And another case I would like to understand is, if I kill
> >> >> wpa_supplicant that's started by Network-Manager and also remove
> >> >> wpa_supplicant from /sbin, but run wpa_supplicant from another folder,
> >> >> does Network-manager finds him & tries to control?
> >> >
> >> > Yes, as long as you've built the supplicant with the D-Bus control
> >> > interface enabled (CONFIG_CTRL_IFACE_DBUS_NEW), and you've started the
> >> > supplicant with the "-u" option to enable it at runtime.
> >> >
> >> > Dan
> >> >
> >> >> I tried google to get this information. But I couldn't find any useful
> >> >> information.
> >> >>
> >> >> Can one of you help?
> >> >>
> >> >> Thanks,
> >> >> Ram
> >> >> ___
> >> >> 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: Network Manager Fails to control Wi-Fi

[Dan Williams]

On Wed, 2015-09-23 at 16:25 +0530, Ramprasad Vempati wrote:
> Hi,
> 
> I'm seeing below messages when I connect external USB Wi-Fi Adapter.
> It is Proxim Adapter.

It looks like it's working to me?  You do get some errors, but I believe
those are harmless and have been suppressed upstream already for a few
years.  You're probably using NM 0.9.8 from Debian?

Anyway, the device enters the "unavailable" state, which means that NM
will manage it, if some conditions are satisfied.  Those include:

a) wpa_supplicant is running
b) the device is not rfkilled

What do you get for the output of:

nmcli dev
nmcli radio
sudo rfkill list

Dan

> Below is the snippet of logs from /var/log/syslog. Any idea what could
> have gone wrong?
> 
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:
> SCPlugin-Ifupdown: devices added (path:
> /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/net/wlan2,
> iface: wlan2)
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:
> SCPlugin-Ifupdown: device added (path:
> /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/net/wlan2,
> iface: wlan2): no ifupdown configuration found.
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]: 
> [1443005487.669494] [wifi-utils-nl80211.c:654]
> nl80211_wiphy_info_handler(): Don't know the meaning of
> NL80211_ATTR_CIPHER_SUITES 0x000fac0a.
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]: 
> [1443005487.669519] [wifi-utils-nl80211.c:654]
> nl80211_wiphy_info_handler(): Don't know the meaning of
> NL80211_ATTR_CIPHER_SUITES 0x000fac08.
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]: 
> [1443005487.669533] [wifi-utils-nl80211.c:654]
> nl80211_wiphy_info_handler(): Don't know the meaning of
> NL80211_ATTR_CIPHER_SUITES 0x000fac09.
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]: 
> [1443005487.669545] [wifi-utils-nl80211.c:654]
> nl80211_wiphy_info_handler(): Don't know the meaning of
> NL80211_ATTR_CIPHER_SUITES 0x000fac06.
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]: 
> [1443005487.669558] [wifi-utils-nl80211.c:654]
> nl80211_wiphy_info_handler(): Don't know the meaning of
> NL80211_ATTR_CIPHER_SUITES 0x000fac0d.
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]: 
> [1443005487.669570] [wifi-utils-nl80211.c:654]
> nl80211_wiphy_info_handler(): Don't know the meaning of
> NL80211_ATTR_CIPHER_SUITES 0x000fac0b.
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]: 
> [1443005487.669582] [wifi-utils-nl80211.c:654]
> nl80211_wiphy_info_handler(): Don't know the meaning of
> NL80211_ATTR_CIPHER_SUITES 0x000fac0c.
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:  (wlan2):
> using nl80211 for WiFi device control
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:  (wlan2):
> driver supports Access Point (AP) mode
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:  (wlan2): new
> 802.11 WiFi device (driver: 'carl9170' ifindex: 4)
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:  (wlan2):
> exported as /org/freedesktop/NetworkManager/Devices/2
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:  (wlan2): now managed
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:  (wlan2):
> device state change: unmanaged -> unavailable (reason 'managed') [10
> 20 2]
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:  (wlan2):
> bringing up device.
> Sep 23 16:21:27 ramprasad-12 NetworkManager[2516]:  (wlan2):
> deactivating device (reason 'managed') [2]
> Sep 23 16:22:27 ramprasad-12 kernel: [  247.303635] cfg80211:
> Verifying active interfaces after reg change
> 
> 
> And NetworkManager.conf output is:
> 
> root@ramprasad-12:~# cat /etc/NetworkManager/NetworkManager.conf
> 
> [main]
> plugins=ifupdown,keyfile
> dns=dnsmasq
> 
> no-auto-default=2C:41:38:0E:DF:81,
> 
> [ifupdown]
> managed=true
> 
> And output of /etc/network/interfaces is as below
> 
> root@ramprasad-12:~# cat /etc/network/interfaces
> auto lo
> iface lo inet loopback
> #auto eth0
> #iface eth0 inet4 auto
> #auto eth1
> #iface eth1 inet4 auto
> #auto eth2
> #iface eth2 inet4 auto
> #auto eth3
> #iface eth3 inet4 auto
> #auto eth4
> #iface eth4 inet4 auto
> #auto eth5
> #iface eth5 inet4 auto
> root@ramprasad-12:~#
> 
> 
> ___
> 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: Understanding How Networking Manager Manages Wi-Fi

[Dan Williams]

On Tue, 2015-09-22 at 23:41 +0530, Ramprasad Vempati wrote:
> Thanks Dan for quick reply. Could you also let me know is this
> interaction to wpa_supplicant is controlled by some config file or is
> it embedded with-in binary?

NM generates the supplicant configuration from its own internal
configuration, which is stored in /etc in various places depending on
your distro.

> And can I configure Network Manager not to manage any of Wi-Fi
> Networks but just Wired networks?  If yes, can you help me how can I
> do that?

You can tell NM to ignore any interface through its configuration file,
by setting "unmanaged-devices" (see man NetworkManager.conf) or by
tagging all wifi devices with a udev rule to tell NM to ignore them.

Dan

> And in that case I'm assuming Network Manager won't even start wpa_supplicant.
> 
> 
> On Tue, Sep 22, 2015 at 8:33 PM, Dan Williams  wrote:
> > On Tue, 2015-09-22 at 19:54 +0530, Ramprasad Vempati wrote:
> >> Hi,
> >>
> >> I'm interested to understand the flow, in terms of how Network-Manager
> >> controls Wi-Fi. As far as I know Network Manager talks to
> >> wpa_supplicant.
> >
> > Yes, through the D-Bus IPC protocol, which many services on Linux use.
> >
> >> But I'm interested in more details. Like how Network-manager starts
> >> wpa_supplicant?
> >
> > Through D-Bus service activation.  Even if the supplicant is not yet
> > started, NM asks the supplicant a question, and the D-Bus daemon will
> > hold the request, start the supplicant, and pass the request along when
> > it's ready.
> >
> >> And another case I would like to understand is, if I kill
> >> wpa_supplicant that's started by Network-Manager and also remove
> >> wpa_supplicant from /sbin, but run wpa_supplicant from another folder,
> >> does Network-manager finds him & tries to control?
> >
> > Yes, as long as you've built the supplicant with the D-Bus control
> > interface enabled (CONFIG_CTRL_IFACE_DBUS_NEW), and you've started the
> > supplicant with the "-u" option to enable it at runtime.
> >
> > Dan
> >
> >> I tried google to get this information. But I couldn't find any useful
> >> information.
> >>
> >> Can one of you help?
> >>
> >> Thanks,
> >> Ram
> >> ___
> >> 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: Understanding How Networking Manager Manages Wi-Fi

[Dan Williams]

On Tue, 2015-09-22 at 19:54 +0530, Ramprasad Vempati wrote:
> Hi,
> 
> I'm interested to understand the flow, in terms of how Network-Manager
> controls Wi-Fi. As far as I know Network Manager talks to
> wpa_supplicant.

Yes, through the D-Bus IPC protocol, which many services on Linux use.

> But I'm interested in more details. Like how Network-manager starts
> wpa_supplicant?

Through D-Bus service activation.  Even if the supplicant is not yet
started, NM asks the supplicant a question, and the D-Bus daemon will
hold the request, start the supplicant, and pass the request along when
it's ready.

> And another case I would like to understand is, if I kill
> wpa_supplicant that's started by Network-Manager and also remove
> wpa_supplicant from /sbin, but run wpa_supplicant from another folder,
> does Network-manager finds him & tries to control?

Yes, as long as you've built the supplicant with the D-Bus control
interface enabled (CONFIG_CTRL_IFACE_DBUS_NEW), and you've started the
supplicant with the "-u" option to enable it at runtime.

Dan

> I tried google to get this information. But I couldn't find any useful
> information.
> 
> Can one of you help?
> 
> Thanks,
> Ram
> ___
> 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: Networkmanager doesn't connect to WiFi

[Dan Williams]

On Tue, 2015-09-22 at 10:57 +0200, Pieter Cardoen wrote:
> Dear
> I am experimenting with dynamic behaviour of NM with multiple networks and 
> how handover occurs between WiFi/mobile network. I am moving away from the 
> WiFi access point as far that the NM is unable to connect to the WiFi. NM is 
> restarted and gets a connection to the mobile connection (lowest autoconnect 
> priority). Afterwards, I am moving very close to the WiFi AP but NM doesn't 
> connect to it.

For a specific interface, NM sticks with the existing connection on a
device type as long as it's viable, and only when that connection is
broken will it cut over to the next best connection.  So if NM is
connected to a 20% WiFi access point of SSID A but there is an available
90% access point with SSID B, NM will not switch over until the
connection to the 20% one is broken.  This is not the same as roaming
between access points of the same SSID, where wpa_supplicant (under
direction of NM) *will* roam between same-SSID access points to achieve
the best signal strength.

Between interfaces, NM will keep *both* WWAN and WiFi connections
active, and switch the default route between the two (and thus the
traffic) depending on the connection's "device route metric".  So if
your policy should be "use WiFi when available", you can set the WiFi
device route metric on each WiFi connection to be lower (eg, higher
priority) than the WWAN connection, and allow NM to autoconnect WWAN and
WiFi.

WiFi scanning is also at play here.  By default, NM scans periodically
starting at 20 seconds and increasing the interval to 2 minutes.  This
behavior is controversial because scanning can interrupt interactive
traffic like SSH or streaming video or gaming.  But scanning more
frequently obviously updates the list of available access points more
frequently too.  Given these two goals (better interactivity vs. better
information), NM gives you the user the choice by letting you call D-Bus
methods on NM to scan more frequently while NM is connected.

In the case of restarting NM giving larger signal strength, WiFi signal
strength is quite variable even at the same exact location.  It depends
on interference from other radios/appliances, what TX/RX antenna the
WiFi access point is using, what TX/RX antenna *your* device is using,
and what driver your wifi interface uses.  I wouldn't be surprised at a
10% difference or more, but to get the raw values to look further, run
"iw dev  link" and look at the dBm values.  How much do they
change?

Dan

> If I execute "nmcli dev wifi list" after moving a little bit from the APs 
> away, I get:*  SSID   MODECHAN  RATE   SIGNAL  BARS  
> SECURITY   demo7  Infra   7 54 Mbit/s  22  ▂___  --   
> STATIONInfra   1 54 Mbit/s  14  ▂___  WPA2 802.1X   
> CONTROLInfra   1154 Mbit/s  17  ▂___  --   
> forge_wlan_inf4Infra   6454 Mbit/s  25  ▂___  --   STATION
> Infra   6 54 Mbit/s  19  ▂___  WPA2 802.1X   forge_wlan_inf5
> Infra   100   54 Mbit/s  27  ▂___  --   forge_wlan_inf3Infra   56
> 54 Mbit/s  27  ▂___  --   forge_wlan_adhoc3  Ad-Hoc  5654 Mbit/s  27  
> ▂___  --   forge_wlan_adhoc5  Ad-Hoc  100   54 Mbit/s  24  ▂___  --   
> forge_wlan_adhoc5  Ad-Hoc  100   54 Mbit/s  25  ▂___  --   
> forge_wlan_adhoc5  Ad-Hoc  100   54 Mbit/s  24  ▂___  --
> This shows me that both station APs (SSID=STATION) have signal of 14% and 
> 19%. If I am executing "Service network-manager restart" and again ask the 
> WiFi signal level with "nmcli dev wifi list", I get:
> *  SSID   MODECHAN  RATE   SIGNAL  BARS  SECURITY   
> forge_wlan_inf4Infra   6454 Mbit/s  29  ▂___  --   
> forge_wlan_inf5Infra   100   54 Mbit/s  29  ▂___  --   demo7  
> Infra   7 54 Mbit/s  34  ▂▄__  --   forge_wlan_adhoc5  Ad-Hoc  
> 100   54 Mbit/s  25  ▂___  --   forge_wlan_adhoc3  Ad-Hoc  5654 
> Mbit/s  22  ▂___  --   CONTROLInfra   1154 Mbit/s  27 
>  ▂___  --   forge_wlan_inf3Infra   5654 Mbit/s  20  ▂___  --   
> STATIONInfra   1 54 Mbit/s  22  ▂___  WPA2 802.1X*  
> STATIONInfra   6 54 Mbit/s  35  ▂▄__  WPA2 802.1X
> My robot is not moved but signal level after NM restart is noticeably higher 
> than before. It seems that the signal level sticks to the percentages which 
> have been measured at the beginning of my experiment.
> Can someone help me with this issue?
> Best regardsPieter Cardoen
> 
> ___ 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-l

Re: How to make NM call dnsmsaq with --bind-dynamic ?

[Dan Williams]

On Mon, 2015-09-14 at 23:25 +0200, Jean-Christian de Rivaz wrote:
> Hello,
> 
> I use NetworkManager on a embedded Debian Jessie system that have 
> multiples interfaces, some of them going up dynamically. The system is 
> acting as a router between the interfaces and have the relevant iptables 
> rules to do NAT masquerading and MSSTCP handling. The only remaining 
> point is to have a DNS server on the system accessibly from any 
> interface at any time. To do that I have added the 
> /etc/NetworkManager/dnsmasq.d/interface file with this content:
> 
> interface=*
> 
> It do the expected work, but only until the interface list change: At 
> this point dnsmasq will not bind new interfaces. According to the 
> dnsmasq manual there is a --bind-dynamic to handle this.
> Unfortunately NM call dnsmasq with the --bind-interfaces option that is 
> incompatible with the --bind-dynamic option. And NM don't restart 
> dnsmasq when the interfaces list change.

I'll assume you're talking about the local caching nameserver stuff
here, not about the internet connection sharing.  Both use dnsmasq, but
in different ways.

It sounds like you're trying to use NM's dnsmasq functionality in a way
that isn't really intended; it's not supposed to be a DNS server for all
other machines on any interface, it's simply supposed to be a local
caching nameserver for the *local*  machine.  If you want a generic
forwarder for all machines, you would typically configure a separate
dnsmasq service that would read its DNS servers from /etc/resolv.conf
and watch that file for changes.  NM itself wouldn't be set up with
local caching nameserver functionality though.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: WiFi interface disappeared

[Dan Williams]

On Mon, 2015-09-14 at 17:32 -0400, Jim wrote:
> Dan
> 
> Thanks for replying.  As I mentioned the WiFi on the same box runs fine 
> from Ubuntu or from Windows.
> 
> Here are the lspci and lsusb
> 
> Jim$lspci
...
> 08:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 
> 802.11b/g/n WiFi Adapter (rev 01)

So you have a Realtek 8188CE device.

> In addition, here is lsmod
> Jim$lsmod
> Module  Size  Used by
> i915  958755  3
> i2c_algo_bit   13250  1 i915
> drm_kms_helper 93604  1 i915
> crct10dif_pclmul   14307  0
> crc32_pclmul   13133  0
> crc32c_intel   22094  0
> drm   300858  5 i915,drm_kms_helper
> ghash_clmulni_intel13230  0
> r8169  71639  0
> mii13527  1 r8169
> video  19825  1 i915
> sunrpc279333  1

This shows there is no kernel driver loaded for your device.  Yes, r8169
is a realtek driver, but it's for ethernet devices not wifi.  I'd expect
to see an rtl81xx (maybe rtl8192) or similar module.  Next step is:

dmesg | grep rtl

and lets see what we get.

Dan



> 
> On 09/14/2015 03:17 PM, Dan Williams wrote:
> > On Mon, 2015-09-14 at 14:10 -0400, JimR wrote:
> >> Fedora Core 21, KDE spin, all patches up to date.
> >>
> >> Have run for many months using WiFi almost exclusively. Started using 
> >> OpenVPN a couple of months ago with a commercial VPN provider. (Not sure 
> >> if that matters). That has worked fine.
> >>
> >> Got notification from Apper that some packages needed updating, including 
> >> kernel. Performed the update from the Apper UI.  I don't know if 
> >> Networkmanager was in the list.
> >>
> >> After reboot, WiFi no longer works, in fact, the whole WiFi interface has 
> >> disappeared from ifconfig and from the NetworkServices UI. I plugged in an 
> >> ethernet cable, and it works fine. Machine is triple-boot, FC21, Win7 and 
> >> Ubuntu LTS 14.04. WiFi works fine in Win and Ubu.
> >>
> >> I tried re-adding the interface, wlp8s0 using the Connection Editor. 
> >> Seemed happy, but it still won't start nor  list in ifconfig
> > If the device isn't listed in ifconfig the the kernel cannot see it, and
> > thus NetworkManager can't see it.  It seems like there is either a
> > hardware problem with your wifi device, or the kernel has been updated
> > and no longer recognizes the wifi device.  What is the output of 'lsusb'
> > and 'lspci' when those commands are run in a terminal on your machine?
> >
> > Dan
> >
> >> I found this in the messages log around the time of the failure, but 
> >> googling this does not produce any meaningful help:
> >>
> >> Sep 12 23:16:04 KD1YV1 NetworkManager[733]:  (wlp8s0): device state 
> >> change: activated -> deactivating (reason 'removed') [100 110 36]
> >> Sep 12 23:16:04 KD1YV1 NetworkManager[733]:  NetworkManager state is 
> >> now CONNECTED_LOCAL
> >> Sep 12 23:16:04 KD1YV1 NetworkManager[733]:  (wlp8s0): device state 
> >> change: deactivating -> unmanaged (reason 'removed') [110 10 36]
> >> Sep 12 23:16:04 KD1YV1 NetworkManager[733]:  (wlp8s0): deactivating 
> >> device (reason 'removed') [36]
> >>
> >> Help!
> >> JimR
> >> ___ 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: WiFi interface disappeared

[Dan Williams]

On Mon, 2015-09-14 at 14:10 -0400, JimR wrote:
> Fedora Core 21, KDE spin, all patches up to date.
> 
> Have run for many months using WiFi almost exclusively. Started using OpenVPN 
> a couple of months ago with a commercial VPN provider. (Not sure if that 
> matters). That has worked fine.
> 
> Got notification from Apper that some packages needed updating, including 
> kernel. Performed the update from the Apper UI.  I don't know if 
> Networkmanager was in the list.
> 
> After reboot, WiFi no longer works, in fact, the whole WiFi interface has 
> disappeared from ifconfig and from the NetworkServices UI. I plugged in an 
> ethernet cable, and it works fine. Machine is triple-boot, FC21, Win7 and 
> Ubuntu LTS 14.04. WiFi works fine in Win and Ubu.
> 
> I tried re-adding the interface, wlp8s0 using the Connection Editor. Seemed 
> happy, but it still won't start nor  list in ifconfig 

If the device isn't listed in ifconfig the the kernel cannot see it, and
thus NetworkManager can't see it.  It seems like there is either a
hardware problem with your wifi device, or the kernel has been updated
and no longer recognizes the wifi device.  What is the output of 'lsusb'
and 'lspci' when those commands are run in a terminal on your machine?

Dan

> I found this in the messages log around the time of the failure, but googling 
> this does not produce any meaningful help:
> 
> Sep 12 23:16:04 KD1YV1 NetworkManager[733]:  (wlp8s0): device state 
> change: activated -> deactivating (reason 'removed') [100 110 36]
> Sep 12 23:16:04 KD1YV1 NetworkManager[733]:  NetworkManager state is 
> now CONNECTED_LOCAL
> Sep 12 23:16:04 KD1YV1 NetworkManager[733]:  (wlp8s0): device state 
> change: deactivating -> unmanaged (reason 'removed') [110 10 36]
> Sep 12 23:16:04 KD1YV1 NetworkManager[733]:  (wlp8s0): deactivating 
> device (reason 'removed') [36]
> 
> Help!
> JimR
> ___ 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 and stuff

[Dan Williams]

On Sat, 2015-09-12 at 19:56 +0200, Xen wrote:
> Seriously I would suggest to get rid of the CamelCase name. It breaks 
> compatibility or congruency with a lot of other things and as a user you 
> are constantly wondering what the name is going to be. NetworkManager? 
> networkmanager? network-manager? It changes from situation to situation. 
> There is no reason for NetworkManager to be capitalized (least of all 
> the binary) because this is no user-friendly system where NM sits inside 
> some sort of pretty application catalogue. Linux packages are always 
> lowercased. Most Linux directories are lowercased (and they should be). 
> You have to follow convention. This only creates problems. This is not 
> Microsoft Windows where each program sits in C:\Programs or C:\Program 
> Files and where filenames are CASE INSENSITIVE. Even the KDE convention 
> to name the "Documents" and "Pictures" folders with upper cases creates 
> issue because of the case sensitivity, which means that "cd documents" 
> won't work. If you want this in Linux, you have to ensure that the 
> actual names are lower case, but that you create a representation in the 
> GUI (!!!) that is capitalized. I know other packages do this as well, 
> notably PackageKit and UPower, but it is bad habit and bad choice and 
> makes it harder for everyone, because most of what you do in Linux is 
> still done using the COMMAND LINE.

I happen to disagree, but everyone is entitled to their opinion.  As it
stands, the official name is "NetworkManager", but distributions apply
their own packaging guidelines and some distributions disallow CamelCase
names, but certainly not all Linux distributions.  So distributions that
choose to allow only lower-case names will then obviously create
confusion between the package name and the project name.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: WPA/WPA2 Enterprise details

[Dan Williams]

On Mon, 2015-09-14 at 15:02 +0200, Jirka Klimes wrote:
> On Mon, 14 Sep 2015 13:23:14 +0200
> Jan Grulich  wrote:
> 
> > On Monday 14 of September 2015 12:51:01 Jirka Klimes wrote:
> > > On Mon, 14 Sep 2015 10:36:59 +0200
> > > 
> > > Jan Grulich  wrote:
> > > > Hi,
> > > > 
> > > > I'm trying to improve our WPA/WPA2 Enterprise support in KDE and I
> > > > have few questions regarding 802-11x security setting.
> > > > 
> > > > 1) When phase2-foo properties should be used instead of just foo
> > > > properties (e.g phase2-private-key/private-key) ? In
> > > > implementation of gnome-applet I see they are used when phase2
> > > > property is set to true, but it's always set to false as I can
> > > > see.
> > > 
> > > phase2-foo properties are used for EAP methods that have 2 phases.
> > > In the first phase a tunnel is established, and then, in phase 2,
> > > the authentication is done inside the tunnel using the inner method
> > > that uses the phase2 properties.
> > > NM uses that for PEAP, TTLS and FAST EAP methods for which you can
> > > specify inner methods.
> > > 
> > > I am not aware of gnome-shell applet implementation. You can look at
> > > nm-applet/nm-connection-editor code here:
> > > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-securi
> > > ty/eap-method.c
> > > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-secur
> > > ity/eap-method-peap.c
> > 
> > I actually meant nm-applet and not gnome-applet.
> > 
> > I see only phase2_auth property used in PEAP, FAST PEAP and TTLS, but
> > in TLS there are other phase2-foo properties used only when
> > parent->phase2 is true. I just don't understand why this property is
> > always set to false in
> > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/wireless-security.c[1]
> > by passing false as third parameter to eap_method_tls_new (line 428).
> > 
> > Is there any place where this property gets changed?
> > 
> As I said, phase 2 is only used for some of the methods, that have
> an inner authentication. Those are PEAP, TTLS and FAST.
> TLS if used by itself does not have phase 2, so the phase2 properties
> are not used.
> I think that the phase2 parameter in the eap_method_tls_new() is there
> just for the case EAP-TLS is used as an inner authentication method.
> However, nm-connection-editor does not support this configuration. And
> I am not sure if it is a common setup.

Yeah, I don't think we had an actual case of TTLS+TLS before.  There is
a valid reason for doing this (in plain one-phase EAP-TLS the identity
is transmitted in the clear, using TTLS+TLS fixes that) but most
locations seem to use PEAP or TTLS+(something else) since certificates
are fairly difficult to administer at scale.  Could be added though.

Dan

> http://www.opus1.com/www/whitepapers/8021xinnerauthmethods.pdf
> 
> Jirka
> 
> > > > 2) Are subjectMatch/altSubjectMatch properties still valid and
> > > > used? I don't see this implemented in gnome-applet, but we had
> > > > this implemented in the old KDE networkmanagement applet. I'm
> > > > asking because we got a bug report about missing implementation
> > > > of these properties for the new applet and I would like to be
> > > > sure how this should be implemented.
> > > 
> > > https://developer.gnome.org/NetworkManager/1.0/ref-settings.html
> > > 
> > > Yes, the properties are valid and used for matching the
> > > certificates. They are passed to wpa_supplicant that performs the
> > > certificates matching.
> > > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/supplican
> > > t-manager/nm-supplicant-config.c#n971
> > > 
> > > It seems that nm-connection-editor/nn-applet did not handle the
> > > properties. But they can be set via nmcli.
> > > 
> > > Jirka
> > > 
> > 
> > Regards,
> > Jan
> > 
> > 
> > 
> > [1]
> > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/wireless-security.c
> ___
> 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: DNS-server priority

[Dan Williams]

On Thu, 2015-08-20 at 09:14 +0200, Pieter Cardoen wrote:
> 
> > Subject: Re: DNS-server priority
> > From: d...@redhat.com
> > To: pieter.card...@hotmail.com
> > CC: networkmanager-list@gnome.org
> > Date: Wed, 19 Aug 2015 15:22:46 -0500
> > 
> > On Wed, 2015-08-19 at 15:45 +0200, Pieter Cardoen wrote:
> > > Dear all
> > > How can you assign a dns-server priority order? My device has a maximum 
> > > of five active connections at the same time and gets multiple dns-server 
> > > addresses but should prefer one assigned by the dhcp client on eth0.
> > 
> > Typically you'd set connections that you don't want to be "primary" as
> > 'never-default'.  That means they won't be candidates for the default
> > route, and that also means their DNS servers will always be secondary to
> > whatever connection has the default route.  So only connection 'eth0'
> > should be set never-default for your setup.  You could also explicitly
> > ignore automatic DNS information on those other connections to achieve
> > the same result.
> Hmm Not exactly what I want. The fixed eth0 doesn't need a default gateway 
> which is good. This is my control interface in the testbed environment. 
> However the DNS of this interface is very important due to the fact that some 
> servers in the testbed need to be accessible... I am now trying to use 
> resolvconf

Ok, so DNS is delivered to eth0, but eth0 isn't supposed to be the
default route.  Some other interface is supposed to have the default
route, but you want to ignore the DNS from those other interfaces, or at
least prefer the DNS from eth0 over that of the other interfaces?

> I've noticed that NM modifies /etc/hosts which causes some troubles in the 
> testbed (nodes are not recognized anymore). What is the cause of this change?

Hmm, NM stopped touching /etc/hosts in late 2010 for NM 0.9.0 and later.
The only thing it will do is remove any lines tagged "# Added by
NetworkManager" to clean up a hosts file written by NM 0.8.x and
earlier.  So I would think you're running a pretty old version of NM if
it's still touching /etc/hosts?

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Getting WPS secrets saved

[Dan Williams]

On Sun, 2015-08-16 at 18:39 -0500, Eric Schultz wrote:
> All,
> 
> I've gotten back to my side-project to add WPS support to NetworkManager.

Great!

> I'm stumbling understanding how I could save the wifi password returned
> from WPS.
> 
> To simplify the process, I was going to implement a command in nmcli to add
> a new connection. As part of adding the connection, I would contact the
> supplicant to start a wps request and, if we received it, take the password
> and save it to the connection and disk. Where I'm confused right now is
> that I don't see where or how wifi passwords are saved anywhere. What code
> is actually saving the Wifi passwords? And is there a single or primary
> place where a wifi password is requested that we can wait for WPS response
> if they choose not to enter a password?

Passwords can be passed to NM as part of the initial connection that you
pass to the AddConnection().

But I think it would be great to have this more embedded in
NetworkManager instead, which would work with all clients not just
nmcli.

Here's an idea; possibly not the best one.  In wifi_secrets_cb() we can
figure out if this is the first time the connection has been used with
nm_settings_connection_get_timestamp().  If timestamp is 0, and there
are no secrets, then we could check whether the AP has WPS IEs that we
can use.

If so, we could call nm_act_request_get_secrets(wifi_wps_secrets_cb) and
pass a hint (like "x-nm-wps-methods=,pbc,pin" that clients could
use to display an alert that says "Please push the WPS button on the
access point or enter the PIN code for the network ".  If PBC then
I don't think we need to return any secrets, if PIN then we could just
stuff the PIN into the PSK secret.

Once the user has done that and hit "OK" the request would come back to
NetworkManager into a wifi_wps_secrets_cb().  If the request wasn't
canceled, assume that the AP is now available for WPS, and continue with
the connection but instead of sending the full config to the supplicant
NM would initiate WPS instead.  Once the the supplicant has figured out
the actual PSK, we'd grab that from the network block and save that in
the NM config.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: DNS-server priority

[Dan Williams]

On Wed, 2015-08-19 at 15:45 +0200, Pieter Cardoen wrote:
> Dear all
> How can you assign a dns-server priority order? My device has a maximum of 
> five active connections at the same time and gets multiple dns-server 
> addresses but should prefer one assigned by the dhcp client on eth0.

Typically you'd set connections that you don't want to be "primary" as
'never-default'.  That means they won't be candidates for the default
route, and that also means their DNS servers will always be secondary to
whatever connection has the default route.  So only connection 'eth0'
should be set never-default for your setup.  You could also explicitly
ignore automatic DNS information on those other connections to achieve
the same result.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: API for dispatcher scripts

[Dan Williams]

On Wed, 2015-08-19 at 21:24 +0200, Olaf Hering wrote:
> After upgrading from openSUSE 11.4 with NM 0.9.something to openSUSE
> Tumbleweed with NM 1.0.2 I was under the impression that the
> interface/API for the scripts in /etc/NetworkManager/dispatcher.d is
> much more reliable, and much more informative.
> 
> But just now I got a different interface for the up and the down event
> of a gsm connection. Thankfully the DEVICE_IFACE is the same for the up
> and down event, so I will adjust my scripts to use that.
> 
> On another host I get different environment for initial vpn-up and a vpn
> restart. The latter lacks the route info because that is not provided
> during restart after the vpn gateway timed out. Right now I dont have
> the exact env data at hand, but I have added logging now to compare both
> variants. Perhaps there are already ways to catch both.
> 
> 
> I wonder if there is any promise for the called scripts, or if its just
> more or less random data that is provided as cmdline arguments and
> environment.

The dispatcher scripts get called (since at least May 2011) with the 'IP
interface' of the device, because that's what is almost always useful
for IP and routing operations:

/* Backwards compat: 'iface' is set in this order:
 * 1) VPN interface name
 * 2) Device IP interface name
 * 3) Device interface anme
 */
if (vpn_ip_iface)
*out_iface = g_strdup (vpn_ip_iface);
else if (ip_iface)
*out_iface = g_strdup (ip_iface);
else
*out_iface = g_strdup (iface);

in your case, the modem's control interface (and thus the NM Device
name) is cdc-wdm0 but the actual interface that IP will run on is
wwp0s29f7u2i4.  Does that make sense?

If you're able to get logs from NM 0.9.x showing this isn't the case
there, I'd love to see them to figure out why they're doing that.

Dan

> Olaf
> 
> 
> Wed Aug 19 19:01:07 UTC 2015
> 124.10 115.21
> /etc/NetworkManager/dispatcher.d/01-dnsmasq-conf.sh wwp0s29f7u2i4 up
> CONNECTION_FILENAME=/etc/NetworkManager/system-connections/Vodafone 
> WebSessions
> CONNECTION_ID=Vodafone WebSessions
> CONNECTION_UUID=9d9f7b94-b534-4a68-b78c-ba4e1899d4b3
> DEVICE_IFACE=cdc-wdm0
> DEVICE_IP_IFACE=wwp0s29f7u2i4
> DHCP4_BROADCAST_ADDRESS=10.230.151.223
> DHCP4_DHCP_LEASE_TIME=7200
> DHCP4_DHCP_MESSAGE_TYPE=5
> DHCP4_DHCP_SERVER_IDENTIFIER=10.230.151.221
> DHCP4_DOMAIN_NAME_SERVERS=139.7.30.125 139.7.30.126
> DHCP4_EXPIRY=1440018067
> DHCP4_HOST_NAME=esprimo
> DHCP4_IP_ADDRESS=10.230.151.220
> DHCP4_NETWORK_NUMBER=10.230.151.220
> DHCP4_REQUESTED_BROADCAST_ADDRESS=1
> DHCP4_REQUESTED_DOMAIN_NAME=1
> DHCP4_REQUESTED_DOMAIN_NAME_SERVERS=1
> DHCP4_REQUESTED_DOMAIN_SEARCH=1
> DHCP4_REQUESTED_HOST_NAME=1
> DHCP4_REQUESTED_INTERFACE_MTU=1
> DHCP4_REQUESTED_MS_CLASSLESS_STATIC_ROUTES=1
> DHCP4_REQUESTED_NDS_CONTEXT=1
> DHCP4_REQUESTED_NDS_SERVERS=1
> DHCP4_REQUESTED_NDS_TREE_NAME=1
> DHCP4_REQUESTED_NETBIOS_DD_SERVER=1
> DHCP4_REQUESTED_NETBIOS_NAME_SERVERS=1
> DHCP4_REQUESTED_NETBIOS_NODE_TYPE=1
> DHCP4_REQUESTED_NETBIOS_SCOPE=1
> DHCP4_REQUESTED_NIS_DOMAIN=1
> DHCP4_REQUESTED_NIS_SERVERS=1
> DHCP4_REQUESTED_NTP_SERVERS=1
> DHCP4_REQUESTED_RFC3442_CLASSLESS_STATIC_ROUTES=1
> DHCP4_REQUESTED_ROUTERS=1
> DHCP4_REQUESTED_STATIC_ROUTES=1
> DHCP4_REQUESTED_SUBNET_MASK=1
> DHCP4_REQUESTED_WPAD=1
> DHCP4_ROUTERS=10.230.151.221
> DHCP4_SUBNET_MASK=255.255.255.252
> IP4_ADDRESS_0=10.230.151.220/30 10.230.151.221
> IP4_GATEWAY=10.230.151.221
> IP4_NAMESERVERS=139.7.30.125 139.7.30.126
> IP4_NUM_ADDRESSES=1
> IP4_NUM_ROUTES=0
> IP6_GATEWAY=::
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> PWD=/
> SHLVL=1
> _=/usr/bin/env
> 
> Wed Aug 19 19:11:52 UTC 2015
> 768.50 1344.47
> /etc/NetworkManager/dispatcher.d/01-dnsmasq-conf.sh cdc-wdm0 down
> CONNECTION_FILENAME=/etc/NetworkManager/system-connections/Vodafone 
> WebSessions
> CONNECTION_ID=Vodafone WebSessions
> CONNECTION_UUID=9d9f7b94-b534-4a68-b78c-ba4e1899d4b3
> DEVICE_IFACE=cdc-wdm0
> DEVICE_IP_IFACE=cdc-wdm0
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> PWD=/
> SHLVL=1
> _=/usr/bin/env
> 
> ___
> 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: slowly or no configured connection usage

[Dan Williams]

On Wed, 2015-08-05 at 03:41 +0200, Ingo Flaschberger wrote:
> 
> Am 04.08.2015 um 23:52 schrieb Dan Williams:
> > On Mon, 2015-08-03 at 03:00 +0200, Ingo Flaschberger wrote:
> >> Hi,
> >>
> >> I use nm 0.9.10 with debian jessie at a raspberry pi.
> >>
> >> Problem 1:
> >> If I configure a single connection with auth ipv4, auto ipv6, auto
> >> connect and delete all other connections it takes severall minutes after
> >> reboot till the connection is used.
> >> Also a new "eth0" connection is always generated.
> >> Connection name is "internet", config is attached.
> > I think this one is probably due to the kernel-assigned IPv6LL address
> > that the device gets when something in the boot process brings the
> > interface IFF_UP.
> >
> >> Problem 2:
> >> If I configure a single connection with static ipv4, link-local ipv6,
> >> auto connect and delete all other connections after reboot the
> >> connections is never used.
> >> Only a new generated "eth0" connection is used.
> >> Connection name is "emergency", config is attached.
> > This is due to the same reason.
> >
> >> Digging into code - I wonder why a new connection is generated and why
> >> nm_utils_match_connection / check_possible_match / check_ip6_method  and
> >> check_ip4_method behave such strange?
> > When NM starts up, it will read the existing interface configuration and
> > attempt to match it to a stored connection.  If it doesn't match, NM
> > tries very hard not to touch the interface, because something else
> > configured it and NM won't blow that away.
> >
> > In case #2, I'll bet that the generated connection "eth0" was
> > ipv4.method=disabled, ipv6.method=link-local.  The connection you
> > created was ipv4.method=manual.  On bootup, the interface has only an
> > IPv6 link-local address, but not the static address from your
> > connection.  Therefore, the runtime config of the interface (ipv6ll
> > only) doesn't match any stored connection, and the existing
> > configuration wins.
> yes, thats the case (dumped the settings yesterday), but interface also 
> has a real ipv6 address assigned.

The real address likely comes from the kernel allowing IPv6 RA by
default when the interface is set IFF_UP early in boot.  You appear to
have an IPv6 router on your LAN :)  So in this case, I would expect NM
to set ipv4.method=disabled, ipv6.method=auto.

Of course, that still doesn't match your manual configuration, and in
this case the fixes I talked about for NM won't have any effect, because
the interface already has some configuration and NM will try very hard
not to blow that away.

So in addition to the fix I talk about, you could modify your accept_ra
default sysctl (at boot time) to be accept_ra=0, which will prevent the
interface from receiving an IPv6 address from the router when the
interface is initially brought up in early boot, and then allow NM to
handle IPv6 instead.

Dan

> > We realize that treating an interface with only an IPv6LL address isn't
> > very useful though, especially since the kernel will assign an LL
> > address whenever the interface is brought IFF_UP, which often happens
> > during boot for various reasons.  Therefore, NM 1.0.4 and later have
> > switched to ignoring interface configurations that have only an IPv6LL
> > address, and will use another configured connection instead.  We could
> > potentially backport that to 0.9.10, or at least make the patch
> > available to distros.
> >
> 
> can you show me the affected code-lines?  then I could wrapup the patch 
> very quick.
> 
> currently I use a cron-job to keep the interfaces up.
> 
> Kind regards,
> Ingo Flaschberger
> 
> 
> ___
> 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: dnsmasq does not work with Network Manager?

[Dan Williams]

On Sat, 2015-08-01 at 04:11 -0300, LUMINARIAS FOTON wrote:
> hello people :)
> I'm trying to use this great application in ubuntu 14.04lts
> I like it accelerates notably Internet navigation.
> but not because they managed to make it run.
> 
> anyone know how to configure the network manager to assign ip to dnsmasq
> in  the file:
> run/NetworkManager/dnsmasq.conf
> 
> as I read should add the localhost address in this file, but left blank :(

I believe Ubuntu has patches that push the DNS configuration to dnsmasq
over the dnsmasq daemon's D-Bus interface, instead of writing it to a
file.  So they won't end up in the NM-written dnsmasq.conf.  So
everything should work correctly: the upstream DNS servers get written
to dnsmasq, and 127.0.0.1 gets written to /etc/resolv.conf, and dnsmasq
acts as a caching local nameserver.

What is the specific problem that you're running into?  Does DNS
resolution not work perhaps?

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to find a tun device for an active VPN connection

[Dan Williams]

On Tue, 2015-07-28 at 11:24 +0200, Jan Grulich wrote:
> Hi,
> 
> I'm looking for a way how to find out which tun device is used for a certain 
> active VPN 
> connection. Right now when you check device property of an active VPN 
> connection it 
> shows the device used by the regular connection which is used as a base for 
> that VPN 
> connection (eg. wifi device or ethernet). I was talking with Jiří Klímeš 
> about this long 
> time ago and he started working on this [1], but it was never finished 
> because there 
> was someone else working on a better approach. So is it finally possible to 
> match VPN 
> connections with tun devices or the work is still in progress? We would like 
> to have this 
> information for traffic monitoring in our KDE NM applet. 
> 
> [1] - https://bugzilla.gnome.org/show_bug.cgi?id=743309[1] 

Hey Jan,

Not much progress on this yet, as you probably realize through that bug
report.  Though the larger new stuff that's talked about in that report
is still targeted for 1.2.

(random note: not all VPNs have interfaces, eg routing-based ones like
openswan/libreswan simply add routes to the parent interface)

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: slowly or no configured connection usage

[Dan Williams]

On Mon, 2015-08-03 at 03:00 +0200, Ingo Flaschberger wrote:
> Hi,
> 
> I use nm 0.9.10 with debian jessie at a raspberry pi.
> 
> Problem 1:
> If I configure a single connection with auth ipv4, auto ipv6, auto 
> connect and delete all other connections it takes severall minutes after 
> reboot till the connection is used.
> Also a new "eth0" connection is always generated.
> Connection name is "internet", config is attached.

I think this one is probably due to the kernel-assigned IPv6LL address
that the device gets when something in the boot process brings the
interface IFF_UP.

> Problem 2:
> If I configure a single connection with static ipv4, link-local ipv6, 
> auto connect and delete all other connections after reboot the 
> connections is never used.
> Only a new generated "eth0" connection is used.
> Connection name is "emergency", config is attached.

This is due to the same reason.

> Digging into code - I wonder why a new connection is generated and why 
> nm_utils_match_connection / check_possible_match / check_ip6_method  and 
> check_ip4_method behave such strange?

When NM starts up, it will read the existing interface configuration and
attempt to match it to a stored connection.  If it doesn't match, NM
tries very hard not to touch the interface, because something else
configured it and NM won't blow that away.

In case #2, I'll bet that the generated connection "eth0" was
ipv4.method=disabled, ipv6.method=link-local.  The connection you
created was ipv4.method=manual.  On bootup, the interface has only an
IPv6 link-local address, but not the static address from your
connection.  Therefore, the runtime config of the interface (ipv6ll
only) doesn't match any stored connection, and the existing
configuration wins.

We realize that treating an interface with only an IPv6LL address isn't
very useful though, especially since the kernel will assign an LL
address whenever the interface is brought IFF_UP, which often happens
during boot for various reasons.  Therefore, NM 1.0.4 and later have
switched to ignoring interface configurations that have only an IPv6LL
address, and will use another configured connection instead.  We could
potentially backport that to 0.9.10, or at least make the patch
available to distros.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Ethernet device still disconnected after a 'link connected' log.

[Dan Williams]

On Mon, 2015-07-27 at 22:22 +0200, Jean-Christian de Rivaz wrote:
> Le 27. 07. 15 19:32, Dan Williams a écrit :
> > On Mon, 2015-07-27 at 19:24 +0200, Jean-Christian de Rivaz wrote:
> >> Le 27. 07. 15 16:36, Dan Williams a écrit :
> >>> On Mon, 2015-07-27 at 13:30 +0200, Jean-Christian de Rivaz wrote:
> >>>> In this observation NetworkManager still think that eth0 is disconnected
> >>>> while he correctly logged the message 'link connected':
> >>> Just to make sure, the ethernet connection being used is
> >>> autoconnect=true, right?
> >>>
> >>> nmcli con show "" | grep autoconnect
> >>>
> >>> will tell you.
> >> nmcli con show "Wired connection 1" | grep autoconnect 
> 
> Wow, seriously what's the point to create a such complicated name when 
> everything from the kernel to probably virtually all applications use 
> 'eth0' ?

Because a 'connection' is not the same thing as a network device.  It's
a collection of configuration that can be applied to the device.  It's
fine to have more than one, for example a static config and a DHCP
config for the same interface.  They cannot both be named the same thing
as they must be individually configurable and applicable to the
interface.

> # nmcli con show "Wired connection 1" | grep autoconnect
> connection.autoconnect: yes
> 
> I hope that 'true' and 'yes' are equal in this context, so I think this 
> is not the cause of the observed problem.

Correct, it's not the cause.  But something we need to rule out.  So
now, getting a debug log from NetworkManager is the next thing.  You can
use "nmcli g log level debug" and then attempt to reproduce the problem,
and then lets see what the log say.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Ethernet device still disconnected after a 'link connected' log.

[Dan Williams]

On Mon, 2015-07-27 at 19:24 +0200, Jean-Christian de Rivaz wrote:
> Le 27. 07. 15 16:36, Dan Williams a écrit :
> > On Mon, 2015-07-27 at 13:30 +0200, Jean-Christian de Rivaz wrote:
> >> In this observation NetworkManager still think that eth0 is disconnected
> >> while he correctly logged the message 'link connected':
> > Just to make sure, the ethernet connection being used is
> > autoconnect=true, right?
> >
> > nmcli con show "" | grep autoconnect
> >
> > will tell you.
> 
> Hi Dan,
> 
> # nmcli con show eth0
> Error: eth0 - no such connection profile.

Right, you're asking for a connection named "eth0", and there probably
isn't one.  Connections can (but aren't always) named the same as a
device to which they could apply.

> Not sure of what you are talking about.  I am pretty certain that eth0 
> is the real device interface.
> 
> # nmcli d
> DEVICE   TYPE  STATE  CONNECTION
> eth0 ethernet  connected  Wired connection 1

So the connection that eth0 is actually using is called "Wired
connection 1".  So you'd:

nmcli con show "Wired connection 1" | grep autoconnect

Dan

> ttyACM0  gsm   connected  gsm1
> ppp0 unknown   connected  ppp0
> lo   loopback  unmanaged  --
> sit0 sit   unmanaged  --
> wlan0wifi  unmanaged  --
> 
> The configuration is mostly the default one, just unmanage the WiFi and 
> configure the GSM APN.
> 
> # cat /etc/NetworkManager/NetworkManager.conf
> [main]
> plugins=ifupdown,keyfile
> 
> [ifupdown]
> managed=true
> 
> [keyfile]
> unmanaged-devices=mac:00:0b:6c:41:eb:24
> 
> # cat /etc/NetworkManager/system-connections/gsm1
> [connection]
> id=gsm1
> uuid=f5e7b733-beea-4fcb-b213-b2dfcbd61073
> type=gsm
> timestamp=1432623762
> 
> [gsm]
> number=*99#
> apn=public4.m2minternet.com
> 
> [ipv6]
> method=auto
> 
> [ipv4]
> method=auto
> 
> 
> Jean-Christian
> 


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Ethernet device still disconnected after a 'link connected' log.

[Dan Williams]

On Mon, 2015-07-27 at 13:30 +0200, Jean-Christian de Rivaz wrote:
> In this observation NetworkManager still think that eth0 is disconnected 
> while he correctly logged the message 'link connected':

Just to make sure, the ethernet connection being used is
autoconnect=true, right?

nmcli con show "" | grep autoconnect

will tell you.

Dan

> Jul 27 07:46:24 x NetworkManager[2184]:  Activation (ppp0) 
> successful, device activated.
> Jul 27 08:20:09 x NetworkManager[2184]:  (eth0): link disconnected 
> (deferring action for 4 seconds)
> Jul 27 08:20:13 x NetworkManager[2184]:  (eth0): link disconnected 
> (calling deferred action)
> Jul 27 08:20:13 x NetworkManager[2184]:  (eth0): device state 
> change: activated -> unavailable (reason 'carrier-changed') [100 20 40]
> Jul 27 08:20:13 x NetworkManager[2184]:  (eth0): deactivating 
> device (reason 'carrier-changed') [40]
> Jul 27 08:20:13 x NetworkManager[2184]:  (eth0): canceled DHCP 
> transaction, DHCP client pid 2270
> Jul 27 08:20:13 x NetworkManager[2184]:  Policy set 'gsm1' (ppp0) 
> as default for IPv4 routing and DNS.
> Jul 27 12:59:30 x NetworkManager[2184]:  (eth0): link connected
> Jul 27 12:59:30 x NetworkManager[2184]:  (eth0): device state 
> change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
> 
> root@x:/home/x# nmcli d
> DEVICE   TYPE  STATE CONNECTION
> ttyACM0  gsm   connected gsm1
> ppp0 unknown   connected ppp0
> eth0 ethernet  disconnected  --
> lo   loopback  unmanaged --
> sit0 sit   unmanaged --
> wlan0wifi  unmanaged --
> 
> root@x:/home/x# ethtool eth0
> Settings for eth0:
>  Supported ports: [ TP MII ]
>  Supported link modes:   10baseT/Half 10baseT/Full
>  100baseT/Half 100baseT/Full
>  Supported pause frame use: No
>  Supports auto-negotiation: Yes
>  Advertised link modes:  10baseT/Half 10baseT/Full
>  100baseT/Half 100baseT/Full
>  Advertised pause frame use: No
>  Advertised auto-negotiation: Yes
>  Link partner advertised link modes:  10baseT/Half 10baseT/Full
>   100baseT/Half 100baseT/Full
>  Link partner advertised pause frame use: Symmetric
>  Link partner advertised auto-negotiation: Yes
>  Speed: 100Mb/s
>  Duplex: Full
>  Port: MII
>  PHYAD: 1
>  Transceiver: external
>  Auto-negotiation: on
>  Link detected: yes
> 
> root@x:/home/x# nmcli  -v
> nmcli tool, version 0.9.10.0
> 
> The state transition from 'unavailable' to 'disconnected' look rater 
> strange or did I miss something ?
> 
> Jean-Christian
> 
> 
> ___
> 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] device: prefer wifi over wwan by default

[Dan Williams]

On Wed, 2015-07-22 at 10:53 +0200, Lubomir Rintel wrote:
> On Tue, 2015-07-21 at 11:37 +0200, Tore Anderson wrote:
> > This makes wifi preferred to wwan (the modem and bluetooth device 
> > types
> > to be specific) by default, so that users that care about being
> > connected at all times can keep both enabled with auto-connect. As 
> > wifi
> > is usually unmetered and often faster than wwan, it makes sense to
> > prefer it. This is also how pretty much every smart-phone in the 
> > world
> > behaves, so it aligns better with user expectations too.
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=744754
> > ---
> >  src/devices/nm-device.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c
> > index eba15a3..332182a 100644
> > --- a/src/devices/nm-device.c
> > +++ b/src/devices/nm-device.c
> > @@ -721,14 +721,14 @@ nm_device_get_priority (NMDevice *self)
> > return 400;
> > case NM_DEVICE_TYPE_BRIDGE:
> > return 425;
> > -   case NM_DEVICE_TYPE_MODEM:
> > -   return 450;
> > -   case NM_DEVICE_TYPE_BT:
> > -   return 550;
> > case NM_DEVICE_TYPE_WIFI:
> > return 600;
> > case NM_DEVICE_TYPE_OLPC_MESH:
> > return 650;
> > +   case NM_DEVICE_TYPE_MODEM:
> > +   return 700;
> > +   case NM_DEVICE_TYPE_BT:
> > +   return 750;
> > case NM_DEVICE_TYPE_GENERIC:
> > return 950;
> > case NM_DEVICE_TYPE_UNKNOWN:
> 
> 
> Thank you. Applied to master & 1.0 stable branch.

I'm OK with this too, though the original idea was that more
"intentional" connections would be preferred.  eg, WWAN is a lot less
automatic than WiFi, and often costs you more money, thus if you
activate a WWAN device you probably want to use it...

The only thing that concerns me is backwards compat; for 1.0 this will
change existing behavior.  If people think that's OK (and now that we
have user-selectable priorities for this) then we should certainly
release-note it in big letters.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nmcli can not join hidden networks?

[Dan Williams]

On Thu, 2015-07-09 at 08:30 -0600, Preston Price wrote:
> Would it be possible to write a small script/app that would interface
> directly with the dbus and send the correct information/settings to
> network-manager?

Yes, it certainly would.  There are a bunch of examples here:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples

so after picking your favorite language, something to do what you want
should be fairly straightforward.  Happy to help point you in the right
direction once you've done that; there isn't a single script here
that'll do what you want, but pieces of a couple will work.

Dan

> On Thu, Jul 9, 2015 at 8:15 AM, Dan Williams  wrote:
> 
> > On Wed, 2015-07-08 at 16:17 -0600, Preston Price wrote:
> > > System details:
> > > Ubuntu 14.04
> > > nmcli v. 0.9.8.8
> > >
> > > I've spent the afternoon Googling and I'm out of ideas.
> > > It appears that there is no way to connect to a hidden SSID from nmcli.
> > >
> > > If I, for example try:
> > > *$ sudo nmcli dev wifi con '' password '' name 'hidden
> > AP'*
> > >
> > > I get an error response:
> > > *$ Error: No network with SSID '' found.*
> > >
> > > I can use the network manager applet to create/connect to this hidden AP,
> > > but I need a non-GUI/command-line-only solution. I don't see any other
> > > appropriate options/flags to set in the nmcli command.
> > >
> > > Is there some secret sauce I'm missing?
> >
> > I don't think you're missing anything; this just seems like a deficiency
> > in nmcli.  One thing you could try instead (while the bug gets fixed) is
> > to create the connection once, set the "wireless.hidden" property to
> > true, and then 'nmcli con up ".
> >
> > Also note that 'nmcli dev wifi connect' will create a new connection
> > each time (I think), so after the first time you connect successfully,
> > you can just use "nmcli con up " instead.
> >
> > I filed https://bugzilla.gnome.org/show_bug.cgi?id=752173 for this
> > issue.
> >
> > Thanks!
> > Dan
> >
> >


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: X220 after new Install no more WWAN

[Dan Williams]

On Thu, 2015-07-09 at 16:11 +0200, Michael wrote:
> Am 09.07.2015 um 16:07 schrieb Dan Williams:
> > 
> > Yeah, this would be a problem...  Is the ModemManager process running?
> no!
> 
> > If not, what do you get for:
> > 
> > sudo journalctl -b -u ModemManager
> 
> 
> [root@laptop michael]# journalctl -b -u ModemManager
> -- Logs begin at Fr 2015-05-29 14:52:41 CEST, end at Do 2015-07-09
> 16:09:21 CEST
> lines 1-1/1 (END)
> 
> mhm...
> hint: you have read my investigations on bugzilla?

Could you send the bug link too, just to make sure I know which one
you're talking about?

Thanks!
Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nmcli can not join hidden networks?

[Dan Williams]

On Wed, 2015-07-08 at 16:17 -0600, Preston Price wrote:
> System details:
> Ubuntu 14.04
> nmcli v. 0.9.8.8
> 
> I've spent the afternoon Googling and I'm out of ideas.
> It appears that there is no way to connect to a hidden SSID from nmcli.
> 
> If I, for example try:
> *$ sudo nmcli dev wifi con '' password '' name 'hidden AP'*
> 
> I get an error response:
> *$ Error: No network with SSID '' found.*
> 
> I can use the network manager applet to create/connect to this hidden AP,
> but I need a non-GUI/command-line-only solution. I don't see any other
> appropriate options/flags to set in the nmcli command.
> 
> Is there some secret sauce I'm missing?

I don't think you're missing anything; this just seems like a deficiency
in nmcli.  One thing you could try instead (while the bug gets fixed) is
to create the connection once, set the "wireless.hidden" property to
true, and then 'nmcli con up ".

Also note that 'nmcli dev wifi connect' will create a new connection
each time (I think), so after the first time you connect successfully,
you can just use "nmcli con up " instead.

I filed https://bugzilla.gnome.org/show_bug.cgi?id=752173 for this
issue.

Thanks!
Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: X220 after new Install no more WWAN

[Dan Williams]

On Thu, 2015-07-09 at 13:23 +0200, michael wrote:
> mhm...
> 
> Am 08.07.2015 um 16:16 schrieb Dan Williams:
> > Also, could you grab the output of:
> > 
> > mmcli -L
> msg: "error: couldn't find the ModemManager in the bus"

Yeah, this would be a problem...  Is the ModemManager process running?
If not, what do you get for:

sudo journalctl -b -u ModemManager

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Issue: Active connection

[Dan Williams]

On Wed, 2015-07-01 at 16:45 +0200, Pieter Cardoen wrote:
> I'am trying to get WiFi logging via dbus but had the following issue:
> I want to monitor the active connection; I use the dbus-interface with object 
> path "/org/freedesktop/NetworkManager/ActiveConnection/x" (x is 1 in my 
> case). This should allow me to read info of the active connection. If I 
> request the SpecificObject property, I get a proper return value: 
> "/org/freedesktop/NetworkManager/AccessPoint/291" but this access point is 
> not in the list of Access Points. If I verify the access point to which the 
> wlan card is associated, it is another one! It seems that this variable 
> doesn't contain the correct info.
> Has anyone experienced this issue?
> NM version: 0.9.10.0

I believe the SpecificObject actually just tracks the AP object that the
connection was started with, and doesn't follow when that changes (since
it could change to nothing when the connection periodically drops, for
example).

But instead of monitoring that, you'd want to watch the WiFi device
object itself, and look at the
org.freedesktop.NetworkManager.Device.Wireless interface's
"ActiveAccessPoint" property.

I just added an example to NM git to retrieve the active AP and some of
it's details, perhaps it'll help?

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/dbus/wifi-active-ap.py

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: X220 after new Install no more WWAN

[Dan Williams]

On Wed, 2015-07-08 at 11:20 +0200, michael wrote:
> Hello list readers
> Hello Dan,
> 
> Am 06.07.2015 um 18:14 schrieb Dan Williams:
> > What is the output of:
> > 
> > lsusb
> > rfkill list
> > nmcli radio
> > nmcli dev
> > journalctl -b -u ModemManager
> 
> I put it here:
> http://pastebin.com/qSy1NSzC

We actually do want 'lsusb' here though, not lspci, since almost all
laptop WWAN cards are actually connected via USB these days.  Any chance
you could get that and post it?

Also, could you grab the output of:

mmcli -L

(yes, "mmcli" not "nmcli")

Thanks!
Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager / signal level (digital)

[Dan Williams]

On Sun, 2015-06-28 at 04:02 +0100, dzimagehost wrote:
> Hello,
> Originally this NetworkManager window
> http://s26.postimg.org/uga92ia2x/Capture_d_cran_27122014_18_13_00.png
> 
> 
> it is possible to customized means to display the signal level (digital) next
> to the Wi-Fi icon as a WiFi Booster
> 
> 
> a Cydia  tweak for iphone.
> 
> http://3.t.imgbox.com/atTfVt63.jpg
> 
> http://www.manjaro.fr/forum/viewtopic.php?f=23&t=5147

It would be possible to show a number next to the level, but since the
applet is targeted at a wider audience it shouldn't be done by default.
IMHO the difference between 50% and 55% actually doesn't mean anything
in WiFi since signal conditions change so often and driver reporting
granularity isn't near as fine as 0 - 100%.

But anyway, an option to toggle that via GSettings would be OK in my
opinion, if anyone wanted to do that patch.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: X220 after new Install no more WWAN

[Dan Williams]

On Mon, 2015-07-06 at 12:24 +0200, michael wrote:
> Hello
> 
> i use NM under Fedora22 (and XFCE)
> 
> 
> My "Modem" =>
> 
> lspci -vmmnn
> Slot: 00:16.0
> Class:Communication controller [0780]
> Vendor:   Intel Corporation [8086]
> Device:   6 Series/C200 Series Chipset Family MEI Controller #1 [1c3a]
> SVendor:  Lenovo [17aa]
> SDevice:  Device [21da]
> Rev:  04
> 
> lspci -nnk
> 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200
> Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
>   Subsystem: Lenovo Device [17aa:21da]
>   Kernel driver in use: mei_me
>   Kernel modules: mei_me
> <=
> 
> My "NM-Files"=>
> 
> networkmanager 1.0.2-1.fc22
> networkmanager wwan 1.0.2-1.fc22
> 
> iwl and ipw (some packets) are installed
> <=
> 
> But, i can't setup my WWAN in Network-Manager NM, and NM-editor found no
> Device. What should I do with Network-Manager thereby my "modem" finds?

What is the output of:

lsusb
rfkill list
nmcli radio
nmcli dev
journalctl -b -u ModemManager

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH 2/2] applet: default to ipv6.method=auto for WWAN connections

[Dan Williams]

NM has fallback logic to ensure that even if IPv6 gets tried and fails,
that IPv4 gets used instead.  So it should be safe to default to
automatic IPv6 support for new WWAN connections now, and bugs should
get fixed instead of papered over.
---
 src/mobile-helpers.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/mobile-helpers.c b/src/mobile-helpers.c
index fc725b9..6166e81 100644
--- a/src/mobile-helpers.c
+++ b/src/mobile-helpers.c
@@ -193,6 +193,15 @@ mobile_wizard_done (NMAMobileWizard *wizard,
} else
g_assert_not_reached ();
 
+   /* Default to IPv4 & IPv6 'automatic' addressing */
+   setting = nm_setting_ip4_config_new ();
+   g_object_set (setting, NM_SETTING_IP_CONFIG_METHOD, 
NM_SETTING_IP4_CONFIG_METHOD_AUTO, NULL);
+   nm_connection_add_setting (connection, setting);
+
+   setting = nm_setting_ip6_config_new ();
+   g_object_set (setting, NM_SETTING_IP_CONFIG_METHOD, 
NM_SETTING_IP6_CONFIG_METHOD_AUTO, NULL);
+   nm_connection_add_setting (connection, setting);
+
nm_connection_add_setting (connection, nm_setting_ppp_new ());
 
setting = nm_setting_connection_new ();
-- 
2.1.0


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH 1/2] applet/editor: no longer add 'serial' setting

[Dan Williams]

It's not used by NM/MM at all right now (and only relevant to things
that actually use plain old serial ports, like RS232 and some embedded
modems) so don't bother adding it.
---
 src/connection-editor/page-mobile.c | 17 -
 src/mobile-helpers.c| 10 --
 2 files changed, 27 deletions(-)

diff --git a/src/connection-editor/page-mobile.c 
b/src/connection-editor/page-mobile.c
index b15cc1d..56bfd21 100644
--- a/src/connection-editor/page-mobile.c
+++ b/src/connection-editor/page-mobile.c
@@ -427,22 +427,6 @@ ce_page_mobile_class_init (CEPageMobileClass *mobile_class)
object_class->dispose = dispose;
 }
 
-static void
-add_default_serial_setting (NMConnection *connection)
-{
-   NMSettingSerial *s_serial;
-
-   s_serial = NM_SETTING_SERIAL (nm_setting_serial_new ());
-   g_object_set (s_serial,
- NM_SETTING_SERIAL_BAUD, 115200,
- NM_SETTING_SERIAL_BITS, 8,
- NM_SETTING_SERIAL_PARITY, 'n',
- NM_SETTING_SERIAL_STOPBITS, 1,
- NULL);
-
-   nm_connection_add_setting (connection, NM_SETTING (s_serial));
-}
-
 typedef struct {
 NMClient *client;
 PageNewConnectionResultFunc result_func;
@@ -498,7 +482,6 @@ new_connection_mobile_wizard_done (NMAMobileWizard *wizard,
g_free (detail);
 
nm_connection_add_setting (connection, type_setting);
-   add_default_serial_setting (connection);
nm_connection_add_setting (connection, nm_setting_ppp_new ());
}
 
diff --git a/src/mobile-helpers.c b/src/mobile-helpers.c
index d867b35..fc725b9 100644
--- a/src/mobile-helpers.c
+++ b/src/mobile-helpers.c
@@ -193,16 +193,6 @@ mobile_wizard_done (NMAMobileWizard *wizard,
} else
g_assert_not_reached ();
 
-   /* Serial setting */
-   setting = nm_setting_serial_new ();
-   g_object_set (setting,
- NM_SETTING_SERIAL_BAUD, 115200,
- NM_SETTING_SERIAL_BITS, 8,
- NM_SETTING_SERIAL_PARITY, 'n',
- NM_SETTING_SERIAL_STOPBITS, 1,
- NULL);
-   nm_connection_add_setting (connection, setting);
-
nm_connection_add_setting (connection, nm_setting_ppp_new ());
 
setting = nm_setting_connection_new ();
-- 
2.1.0


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH v2 2/2] autogen.sh: print errors to stderr, printf instead echo -n

[Dan Williams]

On Fri, 2015-06-19 at 01:25 +0200, Petr Vorel wrote:
> Signed-off-by: Petr Vorel 
> ---
>  autogen.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/autogen.sh b/autogen.sh
> index a7e1c17..b4394bf 100755
> --- a/autogen.sh
> +++ b/autogen.sh
> @@ -15,8 +15,8 @@ PKG_NAME=NetworkManager
>  
>  (test -f $srcdir/configure.ac \
>&& test -f $srcdir/src/main.c) || {
> -echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
> -echo " top-level $PKG_NAME directory"
> +printf "**Error**: Directory "\`$srcdir\'" does not look like the" >&2
> +echo " top-level $PKG_NAME directory" >&2
>  exit 1
>  }
>  

This patch at least seems OK to me...

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: 1.0.4 release next week?

[Dan Williams]

On Tue, 2015-06-30 at 18:12 +0200, Tore Anderson wrote:
> * Dan Williams
> 
> > Oh hmm, yeah, this change would be 1.1+ only so couldn't be backported
> > directly.  The backport would basically be changing both instances of
> > NM_SETTING_IP_CONFIG_METHOD to NM_SETTING_IP4_CONFIG_METHOD and
> > NM_SETTING_IP6_CONFIG_METHOD, respectively.
> 
> With that adaptation it works like a charm. This is what it ended up
> with:
> 
> $ tail -7 /etc/NetworkManager/system-connections/Telenor-tilkobling 
> [ipv4]
> dns-search=

Ugh, this shouldn't be there...

> method=auto
> 
> [ipv6]
> dns-search=
> method=auto
> 
> ...and connectivity to an APN that only supports IPv6 works like a
> charm. Thanks!

Ok, thanks for testing.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: 1.0.4 release next week?

[Dan Williams]

On Tue, 2015-06-30 at 17:07 +0200, Tore Anderson wrote:
> * Dan Williams
> 
> > My fault; how about now?
> 
> Much worse, actually. :-)
> 
> The build fails (nma-1.0.2.src.rpm + 8a4ed5a + 1c7c091):
> 
> mobile-helpers.c: In function 'mobile_wizard_done':
> mobile-helpers.c:199:26: error: 'NM_SETTING_IP_CONFIG_METHOD' undeclared 
> (first use in this function)
>g_object_set (setting, NM_SETTING_IP_CONFIG_METHOD, 
> NM_SETTING_IP4_CONFIG_METHOD_AUTO, NULL);
>   ^
> mobile-helpers.c:199:26: note: each undeclared identifier is reported only 
> once for each function it appears in
> Makefile:927: recipe for target 'nm_applet-mobile-helpers.o' failed
> make[4]: *** [nm_applet-mobile-helpers.o] Error 1

Oh hmm, yeah, this change would be 1.1+ only so couldn't be backported
directly.  The backport would basically be changing both instances of
NM_SETTING_IP_CONFIG_METHOD to NM_SETTING_IP4_CONFIG_METHOD and
NM_SETTING_IP6_CONFIG_METHOD, respectively.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: 1.0.4 release next week?

[Dan Williams]

On Mon, 2015-06-29 at 19:24 +0200, Tore Anderson wrote:
> * Dan Williams
> 
> > On Fri, 2015-06-26 at 18:05 +0200, Tore Anderson wrote:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1221391
> > 
> > I posted some quick patches for that, can you check that they work for
> > you?
> 
> I applied them on top of nma-1.0.2 (the .src.rpm from F22) and it
> didn't quite work. After completing the wizard, an GUI error message
> box popped up saying something like this (translated from Norwegian).
> 
> Error with connection
> Could not add/activate connection
> (32) ipv6.method: property is missing
> Close (button)

My fault; how about now?

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: 1.0.4 release next week?

[Dan Williams]

On Fri, 2015-06-26 at 18:05 +0200, Tore Anderson wrote:
> * Lubomir Rintel
> 
> > It sounds like it's a good idea to conduct some manual smoke testing
> > and do a release during the next week. Would anyone mind?
> > 
> > [...]
> > 
> > Comments, ideas, opinions?
> 
> Hi,
> 
> Is there any hope that the bug below could be fixed in the 1.0 branch
> before the release, so that IPv6 can consistently work on mobile
> broadband out of the box? I'm guessing it's not a terribly complicated
> bug to fix.
> 
> "IPv6 disabled by default when nm-applet creates a new WWAN connection"
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1221391

I posted some quick patches for that, can you check that they work for
you?

Thanks!
Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: WiFi roaming & Modem handover

[Dan Williams]

On Mon, 2015-06-29 at 16:59 +0200, Pieter Cardoen wrote:
> 
> > Subject: Re: WiFi roaming & Modem handover
> > From: thal...@redhat.com
> > To: pieter.card...@hotmail.com; networkmanager-list@gnome.org
> > Date: Mon, 29 Jun 2015 15:42:55 +0200
> > 
> > On Mon, 2015-06-29 at 12:56 +0200, Pieter Cardoen wrote:
> > > I would like to have some information on how NetworkManager takes 
> > > care of handover between Access Points and between Networks:
> > > How does NetworkManager handle WiFi handover between different APs of 
> > > one network?
> > 
> > Do you mean roaming? That is entirely done by wpa_supplicant.Yes I do but I 
> > also want to know how the roaming is managed by the wpa_supplicant. What 
> > metric do they use to decide to change to another Access Point?> 
> > > How does NetworkManager handle handover between different networks: 
> > > i.e. a mobile network and a WiFi network.
> > 
> > What do you mean with "handover" here? You can have different networks
> > ("connections" in NetworkManager speak) active at the same time.
> > In that case, priorities are determined based on routing and route
> > metrics. The same is true for the default-route.This is indeed what I want 
> > to know but I wonder when it is decided that a connection is down? It could 
> > be that the wifi can just be detected but almost no data goes over the 
> > network while a good 3G connection is available. Which metric is used to 
> > detrmine that the connection is down?
> > 
> > Not sure if that answers your questions :)
> > 
> > Thomas

Attempting to reply to Pieter's HTML-only message...

> Yes I do but I also want to know how the roaming is managed by the
wpa_supplicant. What metric do they use to decide to change to another
Access Point?

wpa_supplicant roams to another AP of the same SSID+security when the
current AP's signal strength drops below a threshold, and the other AP's
signal strength is better.  The supplicant attempts to balance stability
with throughput, to ensure that it doesn't jump between APs too often
(since doing so causes latency and increases the chance for
disconnections) but still uses the best possible AP for max throughput.

> This is indeed what I want to know but I wonder when it is decided
that a connection is down? It could be that the wifi can just be
detected but almost no data goes over the network while a good 3G
connection is available. Which metric is used to detrmine that the
connection is down?

NetworkManager decides that the WiFi connection is down when either the
driver or the AP disconnect the connection.  Throughput or bitrate is
not currently taken into accound.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Bug or expected behaviour in 1.0.2 networkmanager / -applet combo

[Dan Williams]

On Thu, 2015-06-18 at 18:30 +0200, Andreas Müller wrote:
> Hi,
> 
> hope this wasn't asked before - found no hints so far:
> 
> I have updated from 0.9.8.10 -> 1.0.2. A common use case for me is to
> change wired connection from DHCP to Manual/Fixed ip. When doing so
> 0.9.8 did unconnect and reconnect automatically after saving
> connection changes - with 1.0.2 I have to unconnect and reconnect
> manually.
> 
> Is this behaviour expected or is it a bug?

I think that's actually a bug in 0.9.8; changes to the connection are
only supposed to be saved to the config files and are not applied until
the connection is restarted.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ZTE MF823 USB Ethernet Dongle on RPi-2/Arch/LXDE

[Dan Williams]

On Thu, 2015-06-18 at 10:01 +0100, John Whitmore wrote:
> Been on a few times between this list and the ModemManager. I was hoping to
> setup a system where I could build some intelligence behind two USB 4G Dongles
> and jump between connections depending on signal strength.
> 
> My second Dongle has stopped that, as it don't report as a Modem device and
> instead uses Ethernet over USB. This all works out of the box on my OpenSUSE
> Laptop but the RPi-2 doesn't work.
> 
> On the laptop "usb-devices" is giving me:

What's the 'lsusb -v -d 19d2:1403' output?

Dan

> T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=19d2 ProdID=1403 Rev=50.09
> S:  Manufacturer=ZTE,Incorporated
> S:  Product=ZTE Technologies MSM
> S:  
> SerialNumber=MF8230ZTED01CP261718SKYDWQ5II0PESHF3BW707_8C64&0
> C:  #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA
> I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=ff Driver=rndis_host
> I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
> I:  If#= 2 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> 
> 
> So it's using the "rndis_host" driver. If I grep for that driver in lsmod I
> get:
> 
> john@bamboo:> lsmod | grep "host"
> rndis_host 14513  1 rndis_wlan
> cdc_ether  14361  1 rndis_host
> usbnet 43864  3 rndis_host,rndis_wlan,cdc_ether
> 
> 
> The laptop also gives me an extra network device:
> 
> ens3u1Link encap:Ethernet  HWaddr 36:4B:50:B7:EF:9E  
>   inet addr:192.168.0.194  Bcast:192.168.0.255  Mask:255.255.255.0
>   inet6 addr: fe80::344b:50ff:feb7:ef9e/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:47 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:83 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:3502 (3.4 Kb)  TX bytes:21953 (21.4 Kb)
> 
> Now the RPi-2 On the other hand when I do "usb-devices"  shows that where the
> OpenSUSE uses "rndis_host" the RPi-2 uses "cdc_ether". In addition there's no
> mention of the additional modules mentioned by lsmod in OpenSUSE (rndis_host,
> rndis_wlan, usbnet)
> 
> So should I be black listing cdc_ether? I can't see that I can do that as that
> driver is used by the working OpenSUSE but it's just one of a number of
> drivers used in the device. Any ideas would be gratefully received.
> 
> John
> ___
> 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/2] autogen.sh: warn if gtkdocize is missing, exit on error

[Dan Williams]

On Thu, 2015-06-18 at 01:45 +0200, Petr Vorel wrote:
> Signed-off-by: Petr Vorel 
> ---
>  autogen.sh | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/autogen.sh b/autogen.sh
> index 5ec9a5a..86f89cc 100755
> --- a/autogen.sh
> +++ b/autogen.sh
> @@ -22,7 +22,14 @@ PKG_NAME=NetworkManager
>  
>  cd $srcdir
>  
> -gtkdocize
> +GTKDOCIZE=`which gtkdocize` || true
> +if test -z $GTKDOCIZE; then
> +echo "**Error**: No GTK-Doc found, please install it" >&2

Actually, gtkdoc isn't required for the build unless you want to do
'make dist' or distcheck.  So in theory, perhaps we should just warn
about that and continue, instead of erroring out?

Dan

> +exit 1
> +else
> +gtkdocize || exit $?
> +fi
> +
>  autopoint --force
>  AUTOPOINT='intltoolize --automake --copy' autoreconf --force --install 
> --verbose
>  


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ModemManager and Thuraya XT

[Dan Williams]

On Wed, 2015-06-17 at 02:47 +0200, Thomas Sailer wrote:
> I had another go at getting the Thuraya XT Satphone to work with 
> Modem/NetworkManager.
> 
> Firstly, I had to add another CREG regex (see the attached diff against 
> 1.4.6) due to the modem's response:
> +CREG: 2, "0426", "F0,0F"

Oh yeah, I've still got that patch around including the testcases.  I'll
clean that up at some point here and post to the ModemManager list.

> Secondly, the XT doesn't particularly like AT+COPS=0. If one sends that, 
> it drops the already acquired satellite signal and then tries to 
> reacquire the signal, which doesn't seem to finish within the timeout 
> period.

That would seem to indicate that we need a ModemManager plugin for the
XT to selectively ignore COPS.  Given that the modem probably only has
one operator and probably always searches automatically for it (unlike
some modems which the COPS=0 is designed to handle) it should probably
be ignored.

> Now I seem to be able to connect using:
> mmcli -m 0 --simple-connect apn="get"
> 
> I cannot however get an IP interface set up. Can anyone give me a hint 
> about what's wrong here?

Without seeing the ModemManager debug logs I can't say for sure, but it
looks like the modem isn't returning the standard response to AT
+CGDCONT=?.  What does it return for that?  I'll bet it doesn't list
anything, or it may not list any result for "IPV4" contexts.  That would
be something I guess we should handle in the MM core, but we'd need to
see the MM debug output for the AT+CGDCONT=? query first.

Dan

> Thanks,
> Thomas
> 
> 
> Jun 17 01:38:52 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): modem state changed, 'searching' --> 'connecting' (reason: 
> user-requested)
> Jun 17 01:38:52 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): modem state changed, 'connecting' --> 'connected' (reason: 
> user-requested)
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): Activation: starting connection 'Thuraya2'
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): Activation: Stage 1 of 5 (Device Prepare) scheduled...
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): Activation: Stage 1 of 5 (Device Prepare) started...
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): device state change: disconnected -> prepare (reason 'none') 
> [30 40 0]
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): Failed to connect 'Thuraya2': Connection requested IPv4 but 
> IPv4 is unsuported by the modem.
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): device state change: prepare -> failed (reason 
> 'modem-init-failed') [40 120 28]
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): Activation: failed for connection 'Thuraya2'
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): Activation: Stage 1 of 5 (Device Prepare) complete.
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): device state change: failed -> disconnected (reason 'none') 
> [120 30 0]
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): deactivating device (reason 'none') [0]
> Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): modem state changed, 'connected' --> 'disconnecting' (reason: 
> user-requested)
> Jun 17 01:40:02 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): modem state changed, 'disconnecting' --> 'searching' (reason: 
> user-requested)
> Jun 17 01:40:38 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): device state change: disconnected -> unmanaged (reason 
> 'removed') [30 10 36]
> Jun 17 01:40:38 localhost.localdomain NetworkManager[8923]:   
> (ttyACM0): deactivating device (reason 'removed') [36]
> 
> ___
> 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: Switch off wifi-handling?

[Dan Williams]

On Tue, 2015-06-16 at 20:44 +0200, W. Martin Borgert wrote:
> Dan, thanks for the quick response!
> 
> Quoting Dan Williams :
> > NM 0.9.10 and later added the ability to ignore an interface by
> > interface name.  NM 0.9.10 and later also split WiFi out to a plugin,
> > which could be removed and then the wifi interface just looks like an
> > unmanaged generic device.
> 
> I hope, that I can upgrade to > 1 some day!
> 
> > But since you're using a very old version, none of those work for you :(
> > Could you try removing wpa_supplicant?  Then NM will leave the device in
> > 'unavailable' state and shouldn't touch it after initial NM startup.
> 
> I removed wpasupplicant and get wlan0 as "unmanaged", not "unavailable":
> 
> $ nmcli dev
> DEVICE TYPE  STATE
> eth0   802-3-ethernetconnected
> usb0   802-3-ethernetunavailable
> wlan0  802-11-wireless   unmanaged
> 
> Is this the expected result?

Even better.  "unmanaged" should produce the correct result for you.
Let us know how it goes...

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Switch off wifi-handling?

[Dan Williams]

On Tue, 2015-06-16 at 17:21 +0200, W. Martin Borgert wrote:
> Hi,
> 
> on an embedded device, I'm using wifi with hostapd exclusively
> and do not want any NM interference.
> 
> How can I tell NM to ignore any wifi stuff?
> 
> Note:
> 
>   - the MAC is unknown, because different wifi pens are used
>   - this is still NM 0.8.6 :~(

NM 0.9.10 and later added the ability to ignore an interface by
interface name.  NM 0.9.10 and later also split WiFi out to a plugin,
which could be removed and then the wifi interface just looks like an
unmanaged generic device.

But since you're using a very old version, none of those work for you :(
Could you try removing wpa_supplicant?  Then NM will leave the device in
'unavailable' state and shouldn't touch it after initial NM startup.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM/ofono FlightMode problem

[Dan Williams]

On Wed, 2015-06-03 at 20:40 -0400, Tony Espy wrote:
> Dan --
> 
> I'd like to hear your opinion about the following problem I'm trying to 
> solve, and your take on an idea I have of how to fix it.
> 
> This occurs with the current version of NetworkManager we're using for 
> Ubuntu on phones, 0.9.10.0-4ubuntu15.1.1 ( see [1] for bzr packaging 
> branch ).
> 
> One  of the patches ( ignore_rfkill_if_urfkill_is_present.patch ) we're 
> carrying allows NM to integrate with urfkill, a daemon that we use for 
> implementing FlightMode, and managing the desired state across reboots 
> of FlightMode and any other system radio killswitches.  There's a long 
> story about why this daemon needed to be used, but I'll keep that out of 
> the discussion for now.
> 
> Please note, I'm pretty sure the following description is correct, 
> however it's possible that I missed something...
> 
> When the urfkill Killswitch DBus signal is received that indicates that 
> a radio killswitch for WWAN has been is disabled ( ie. setting the modem 
> online ), a callback in NM_MANAGER gets invoked. This callback then 
> invokes nm_manager_update_radio_enabled, which in turn iterates over all 
> the MANAGER's devices looking for a matching rf_type, and when found 
> calls nm_device_set_enabled for the device.
> 
> This eventually bubbles down to our NM_MODEM_OFONO subclass, which 
> actually doesn't do anything other than log the set_enabled call ( note, 
> urfkill is responsible for onlining/offlining the modem via ofono ).
> 
> As part of this chain of calls, NM_MODEM sets the modem_state to 
> ENABLING, which in turn triggers NM_DEVICE_MODEM to set the device_state 
> to DISCONNECTED, as the device has now become *available* ( thanks to 
> NM_DEVICE_MODEM->set_enabled setting the rf_enabled flag to TRUE ).
> 
> The problem is, this last device state change, triggers NM_DEVICE to 
> refresh the available connections, however doing so calls back into the 
> NM_MODEM_OFONO sub-class to check that connections are compatible.  When 
> this happens, there's a chance that the ofono hasn't finished initizing 
> the modem after being set online by urfkill.  If this happens, our modem 
> connection is effectively stalled, as nothing other than another 
> FlightMode toggle, or a reboot will re-kick the device to refresh it's 
> available connections again.

Per our IRC conversation, you're using the "SimManager" interface
appearing, then grabbing the SubscriberIdentity as the indicator of
initialization.

So let's assume your NMOfonoModem subclass of NMModem starts in the
INITIALIZING state when the modem object is detected from Ofono.  Your
NMModem subclass would never advance beyond the INITIALIZING state until
all of these conditions are met:

1) NM has called your set_mm_enabled() hook with true (you'd have to
cache that value internally)

2) The SimManager interface has appeared

3) SimManager.SubscriberIdentity has a valid value

at all 3 points where these things may change you can have a helper
function called maybe "check_modem_initialized()" that basically does
this:

if (rf_enabled && sim_manager && subscriber_identity) {
NMModemState new_state = NM_MODEM_STATE_ENABLED;

if (SimManager.PinRequired)
new_state = NM_MODEM_STATE_LOCKED;

nm_modem_set_state (NM_MODEM (self), new_state, );
} else if (nm_modem_get_state (NM_MODEM (self)) > INITIALIZING) {
nm_modem_set_state (NM_MODEM (self), INITIALIZING, );
}

so basically whenever ofono wasn't ready yet (modem in flight mode or
still initializing) the NMModem would sit in INITIALIZING state.
Whenever flight mode was activated the modem would jump back to
INITIALIZING.  This should prevent the modem from becoming 'available'
before it can actually be used, and might also fix the issue of
autoconnect retries becoming exhausted when flight mode is turned on
(that we discussed on IRC).

Hopefully this seems like it'll work to you, let me know if some things
look dubious though and we can continue to iterate.

Dan

> I think the correct way to go about fixing this is to introduce the 
> usage of the modem states DISABLED and ENABLED, as currently NM_MODEM 
> only seems to use DISABLING and ENABLING.
> 
> Doing this would allow NM_MODEM_OFONO and NM_MODEM_BROADBAND to only 
> signal the transition to DISABLED/ENABLED based on state and/or return 
> values from ofono and modem-manager respectively.
> 
> Thoughts?
> 
> Regards,
> /tony
> 
> [1] 
> https://code.launchpad.net/~phablet-team/network-manager/vivid-phone-overlay
> ___
> 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: NetworkManager: network selection

[Dan Williams]

On Wed, 2015-06-03 at 22:16 +0200, Pieter Cardoen wrote:
> This makes sense! Adapting the routing metric value shall allow me to use 
> WiFi over the mobile connection. I've seen that WiFi connection has a higher 
> metric value than the mobile connection so adapting it may make it work as I 
> want it to. I'll try it tomorrow!

Just checking back in, did this work out for you?

Dan

> Thanks for the help!
> Pieter
> 
> > Subject: Re: NetworkManager: network selection
> > From: d...@redhat.com
> > To: pieter.card...@hotmail.com
> > CC: thal...@redhat.com; networkmanager-list@gnome.org
> > Date: Wed, 3 Jun 2015 10:05:58 -0500
> > 
> > On Wed, 2015-06-03 at 08:25 +0200, Pieter Cardoen wrote:
> > > Thomas
> > > Thanks for the reply. It made some things clear. It is for my application 
> > > not acceptable that the NetworkManager just prefers the most recently 
> > > used network but due to the priority feature, it is possible to prefer 
> > > the WiFi network over a mobile network. However, debian stable doesn't 
> > > come with NetworkManager 1.0. I will try to install this version on 
> > > Debian Jessie.
> > 
> > There are really two kinds of "priority" in NM and they are mostly
> > independent of each other:
> > 
> > 1) connection autoconnect when the device is disconnected, which as
> > Thomas said can be modified by the 'connection.autoconnect-priority'
> > property.  This is specific to the device, and all autoconnect decisions
> > are made independently for that device.
> > 
> > 2) which device gets the default route and DNS, which can be modified by
> > the ip4.route-metric and ip6.route-metric properties.  This allows you
> > to prefer a specific device for outgoing traffic; so if you want the
> > WiFi to be preferred when WiFi is connected, then you could set each
> > WiFi connection's ip4.route-metric property lower (which means "more
> > preferred") than the WWAN connection's ip4.route-metric property.
> > 
> > Does that make sense?
> > 
> > Dan
> > 
> > > ThanksPieter
> > > 
> > > > Subject: Re: NetworkManager: network selection
> > > > From: thal...@redhat.com
> > > > To: pieter.card...@hotmail.com
> > > > CC: networkmanager-list@gnome.org
> > > > Date: Tue, 2 Jun 2015 21:36:41 +0200
> > > > 
> > > > On Di, 2015-06-02 at 20:56 +0200, Pieter Cardoen wrote:
> > > > > 
> > > > > I have some questions about how networkmanager selects a network.
> > > > > 
> > > > > How does the NetworkManager deamon decide which network to use if 
> > > > > multiple network connections are available?
> > > > 
> > > > Hi
> > > > 
> > > > when a device is currently not connected, at various instances
> > > > autoconnect hits. For example when you plug-in your cable and carrier
> > > > -detect indicates a link. Or when Wi-Fi scanning indicates new visible
> > > > networks.
> > > > 
> > > > So, in that case, NM will search through the non-connected connections
> > > > and choose a candidate to autoconnect.
> > > > 
> > > > If there are multiple candidates, the one that was used most recently
> > > > will be used.
> > > > 
> > > > > Is it possible to configure preferred networks?
> > > > 
> > > > Yes. Such a candidate must have the "connection.autoconnect" property
> > > > set to "yes". This is the default. In nm-applet this is called
> > > > "Automatically connect to this network when it is available".
> > > > 
> > > > > Is it possible to configure the NetworkManager to only connect to one 
> > > > > WiFi network and ignore all other free networks?
> > > > 
> > > > Yes, set all connection.autoconnect properties of the other connections
> > > > to "no".
> > > > 
> > > > 
> > > > Since 1.0, there is also a new property "connection.autoconnect
> > > > -priority". You can assign there a number, see
> > > >   nmcli connection show CON-NAME
> > > >   nmcli connection modify CON-NAME connection.autoconnect-priority 1
> > > >   man nm-settings
> > > > If there are multiple autoconnect candidates, those with higher numbers
> > > > will be preferred.
> > > > So, you could set the priority of the connection you prefer to "1",
> > > > leaving all others to their default at 0.
> > > > 
> > > > 
> > > > 
> > > > Thomas
> > > 
> > > ___ 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: DHCP renewal changes routing table

[Dan Williams]

On Thu, 2015-06-04 at 13:45 +0200, Thomas Haller wrote:
> On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote:
> > Hi,
> > 
> > When I run the Juniper Network Connect client (ncsvc) it terminates 
> > every time the DHCP license is renewed. The log files of ncsvc are 
> > unfortunately rather cryptic, but it appears as if the DHCP renewal 
> > leads to a change in the routing table which triggers a "rmon.error" 
> > in ncsvc which then tears down the VPN tunnel. Using timestamps the 
> > following two events correlate:
> > 
> > 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to 
> > destination 192.168.1.1 is missing mask 255.255.255.255 with gw 
> > 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628)
> > 
> > which coincides with the following journal entries:
> > 
> > Jun 03 13:34:55.454967 host NetworkManager[1805]: address 
> > 192.168.1.16
> > Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24
> > Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 
> > seconds
> > Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway 192.168.1.1
> > Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver 
> > '192.168.1.1'
> > Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): DHCPv4 
> > state changed bound -> bound
> > Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via 
> > systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus
> > -org.freedesktop.nm-dispatcher.service'
> > Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully 
> > activated service 'org.freedesktop.nm_dispatcher'
> > Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching action 
> > 'dhcp4-change' for wlp6s0
> > Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost 
> > carrier
> > 
> > Besides the ncsvc error listed above I sometimes also see this one:
> > 
> > 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized new 
> > route to 192.168.1.0/0.0.0.0 has been added(conflicts with 
> > our route to 0.0.0.0), disconnecting (routemon.cpp:598)
> > 
> > Both seem to indicate that the routing table is changed on DHCP 
> > renewal. Is there a way to prevent networkmanager from doing this? Or 
> > is this problem caused by something else possibly?
> 
> as you suspect, this is caused by NetworkManager. At various times
> (e.g. when activating a connection, or on new DHCP lease), NM will
> reinstall routes.
> 
> 
> recently there was a related email thread:
> https://mail.gnome.org/archives/networkmanager-list/2015
> -May/msg00016.html
> 
> but no solution either.
> 
> 
> We could change NM not only do any system-modification when it will
> actually have any effect.
> Like, re-installing a route, only if it is not yet currently there.

In NM 1.0.x we still have nm_platform_ip4_route_sync() which already
checks array_contains_ip4_route(), so shouldn't that prevent
re-installation of device-specific routes that are already there?  Or
this is only about the default route and subnet routes from the
NMDefaultRouteManager?

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager & WPA supplicant

[Dan Williams]

On Tue, 2015-06-02 at 21:04 +0200, Pieter Cardoen wrote:
> Dear
> 
> I want to use the option scan_ssid=0 for the wpa_supplicant configuration. 
> However when I add this line to the Wifi configuration keyfile of 
> NetworkManager, it is ignored by the NM daemon. How could I configure the 
> scan_ssid option using NetworkManager?

NM doesn't offer scan_ssid as a configuration option on a per-connection
basis.  scan_ssid=0 doesn't offer any security benefits because by the
time NM sends scan_ssid=1, NM has either (a) already found the network
in the scan list and is already connecting to it, and thus any listener
will soon hear your association/authentication anyway, or (b) the
network is hiding its SSID, and sending scan_ssid=1 enables quicker
connection to the network, and any listener will soon hear your
association too.

NM will *never* probe-request specific SSIDs during general scans unless
you have set the wifi.hidden=true property in the connection details.
NM only probe-requests (eg, scan_ssid=1) a network immediately before
connecting to it, or when wifi.hidden=true.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager autoconnect

[Dan Williams]

On Wed, 2015-06-03 at 16:11 +0200, Pieter Cardoen wrote:
> Dear
> While network testing, I've noticed that NetworkManager automatically 
> connects to a network if its available. However when it isn't available, I've 
> noticed that NetworkManager stops trying to connect. What's the reason of 
> this and how could I make NetworkManager unconditionally try to connect to 
> the network until the end of time?

NM will attempt to reconnect when specific events occur, like new scan
results or a carrier change.  So the answer to your question depends on
what kind of interface you're talking about.

For WiFi, it may be that the scan interval is too long to find your new
network quickly, which you can mitigate by asking NM to scan more
frequently.

Ethernet depends on the kernel's carrier indications unless you have set
'ignore-carrier' for that interface in the NM configuration file.

However, WWAN autoconnect happens continuously because WWAN doesn't have
quick/easy event notifications (scans take minutes and interrupt
connectivity, plus some modems only start registration when you ask them
to connect).  This means that whenever there is a WWAN autoconnect
connection, NM will attempt the connection if the modem is not in
Airplane mode.  If the attempt fails, NM will retry after a couple
seconds, and after 5 failed attempts will pause for a couple minutes,
then retry 5 attempts again.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager: network selection

[Dan Williams]

On Wed, 2015-06-03 at 08:25 +0200, Pieter Cardoen wrote:
> Thomas
> Thanks for the reply. It made some things clear. It is for my application not 
> acceptable that the NetworkManager just prefers the most recently used 
> network but due to the priority feature, it is possible to prefer the WiFi 
> network over a mobile network. However, debian stable doesn't come with 
> NetworkManager 1.0. I will try to install this version on Debian Jessie.

There are really two kinds of "priority" in NM and they are mostly
independent of each other:

1) connection autoconnect when the device is disconnected, which as
Thomas said can be modified by the 'connection.autoconnect-priority'
property.  This is specific to the device, and all autoconnect decisions
are made independently for that device.

2) which device gets the default route and DNS, which can be modified by
the ip4.route-metric and ip6.route-metric properties.  This allows you
to prefer a specific device for outgoing traffic; so if you want the
WiFi to be preferred when WiFi is connected, then you could set each
WiFi connection's ip4.route-metric property lower (which means "more
preferred") than the WWAN connection's ip4.route-metric property.

Does that make sense?

Dan

> ThanksPieter
> 
> > Subject: Re: NetworkManager: network selection
> > From: thal...@redhat.com
> > To: pieter.card...@hotmail.com
> > CC: networkmanager-list@gnome.org
> > Date: Tue, 2 Jun 2015 21:36:41 +0200
> > 
> > On Di, 2015-06-02 at 20:56 +0200, Pieter Cardoen wrote:
> > > 
> > > I have some questions about how networkmanager selects a network.
> > > 
> > > How does the NetworkManager deamon decide which network to use if 
> > > multiple network connections are available?
> > 
> > Hi
> > 
> > when a device is currently not connected, at various instances
> > autoconnect hits. For example when you plug-in your cable and carrier
> > -detect indicates a link. Or when Wi-Fi scanning indicates new visible
> > networks.
> > 
> > So, in that case, NM will search through the non-connected connections
> > and choose a candidate to autoconnect.
> > 
> > If there are multiple candidates, the one that was used most recently
> > will be used.
> > 
> > > Is it possible to configure preferred networks?
> > 
> > Yes. Such a candidate must have the "connection.autoconnect" property
> > set to "yes". This is the default. In nm-applet this is called
> > "Automatically connect to this network when it is available".
> > 
> > > Is it possible to configure the NetworkManager to only connect to one 
> > > WiFi network and ignore all other free networks?
> > 
> > Yes, set all connection.autoconnect properties of the other connections
> > to "no".
> > 
> > 
> > Since 1.0, there is also a new property "connection.autoconnect
> > -priority". You can assign there a number, see
> >   nmcli connection show CON-NAME
> >   nmcli connection modify CON-NAME connection.autoconnect-priority 1
> >   man nm-settings
> > If there are multiple autoconnect candidates, those with higher numbers
> > will be preferred.
> > So, you could set the priority of the connection you prefer to "1",
> > leaving all others to their default at 0.
> > 
> > 
> > 
> > Thomas
> 
> ___ 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: Configure a connection for a gsm with dynamic ttyACMx

[Dan Williams]

On Thu, 2015-05-28 at 22:28 +0200, Jean-Christian de Rivaz wrote:
> Le 28. 05. 15 21:55, Dan Williams a écrit :
> > On Thu, 2015-05-28 at 19:39 +0200, Jean-Christian de Rivaz wrote:
> >> Le 26. 05. 15 19:24, Dan Williams a écrit :
> >>> On Tue, 2015-05-26 at 19:04 +0200, Jean-Christian de Rivaz wrote:
> >>>> Le 26. 05. 15 18:21, Dan Williams a écrit :
> >>>> This is an alternative of the ENV(ID_MM_DEVICE_TAG_NAME) trick to get
> >>>> the tag name. The fact that the name on D-Bus should be allowed to be
> >>>> different from the dynamic tty is the main part that you also agree
> >>>> on if I understand you correctly.
> >>> Yes, I would prefer to do this without more tags, but using the normal
> >>> symlink scheme that udev already supports well.  This also makes it
> >>> non-ModemManager-specific since symlinks are often used for other
> >>> programs as well.
> >>>
> >> Same question as in the ModemManager malling list:
> >>
> >> Just for curiosity, how did you plan to find the symbolic link that point 
> >> to
> >> the real ttyACMx ?
> > g_udev_device_get_device_file_symlinks ()
> >
> >
> 
> Good catch, but in the ModemManager I explain why this will not solve 
> the problem for modem that expose multiple serial devices.

Well, it would solve the problem, but it would mean writing udev rules
that tag a particular modem port, and tagging control ports in MM like
is done for other modems.

Dan


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Interaction with ModemManager

[Dan Williams]

On Thu, 2015-05-28 at 15:30 +0100, John Whitmore wrote:
> I could probably send this message to the ModemManager list as well but I'll
> start here. 
> 
> I was on last week about connecting 2 4G LTE USB Dongles to a RaspberryPi. I
> got one working but had a few issues with the second (vodafone) one. Every
> time I edited the connection, the "vodafone" password had disappeared from the
> connection. I'm away from the unit at the moment, taking a break 'till
> tomorrow, then back at it. I ended up moving from Raspbian to Ubuntu Mate on
> the RPi as Raspian has such old versions of NM and MM. Actually had serious
> problems with Ubuntu Mate and Serial ports both the GPIO serial on the RPi and
> USB - Serial cables. SO think I might be moving on the Arch Linux. There's a
> first time for everything.
> 
> Anyhow that's not my question. When I'd added a dongle that was correctly
> modeswitched and recognised by ModemManager I was able to create a new network
> connection in the NetworkManager. My question is with regards to entering the
> ISP details into the NetworkManager. If I'd an operator SIM, say "three" in
> the dongle and create the network connection but then pull the dongle and
> change the SIM to "vodafone" then the NetworkManager will attempt to connect 
> to
> the "vodafone" network with the "three" APN details.

Correct.  The APN is stored in the network connection details itself, so
the connection is really tied to a specific provider.  We intend to add
a way to lock a connection to a specific device/SIM in the future, but
that won't even really solve the SIM swapping thing.

> Now I've not tested that and what happens so forgive my possibly premature
> question. It seems more logical to me that the APN details would be entered
> into the ModemManger and NetworkManager don't need to know it, but just
> requests a connection from the ModemManager. Ideally the ModemManager could
> look at the current SIM and say what that means in terms of APN details.

In recent versions of NetworkManager you can leave the APN blank (just
don't specify it when creating the connection) and then NM+MM will
request the "default subscribe APN" it the network supports it.  But, of
course, you're at the mercy of whether the network supports it, and what
is configured at the provider's end which may not always be correct.

> New to the party so I'm sure there's a good reason why it is the way it is,
> but just wondered. I'm sure that the data required for a Data connection must
> be on the SIM becasue if I have an open unlocked phone and insert any SIM I've
> never been asked for APN details. Phone just knows what to do. Well that's
> been my expierence.

The data is stored on the device, actually, not the SIM.  Devices/modems
have a cached list of "PDP contexts" (GSM/UMTS) or "EPS contexts" (LTE)
that includes the APN.  When you swap the SIM that list doesn't change
unless something actively changes it, like software on the computer.

What happens on the phone is that there is software to inspect the SIM's
IMSI, extract the MCC/MNC of the provider, and reconfigure the default
APNs stored on the device to something in a hardcoded list.  Or, after
registering with the network, the provider can send an SMS that includes
the correct APNs and the phone will automatically provision.

NetworkManager doesn't do that kind of thing, it's currently up to the
callers of NetworkManager to update the configuration/connections as NM
is just a mechanism and doesn't actually enforce policy like this.  The
various UIs that talk to NM do look at the "mobile broadband provider
database" that is maintained on gnome.org, that does include a list of
MCC/MNC and APNs that a client could use to match up the IMSI with a
suggested APN though.

Does that help?  In short, the SIM swapping problem is always solved at
a level higher than ModemManager, and probably higher than
NetworkManager too.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Configure a connection for a gsm with dynamic ttyACMx

[Dan Williams]

On Thu, 2015-05-28 at 19:39 +0200, Jean-Christian de Rivaz wrote:
> Le 26. 05. 15 19:24, Dan Williams a écrit :
> > On Tue, 2015-05-26 at 19:04 +0200, Jean-Christian de Rivaz wrote:
> >> Le 26. 05. 15 18:21, Dan Williams a écrit :
> >> This is an alternative of the ENV(ID_MM_DEVICE_TAG_NAME) trick to get 
> >> the tag name. The fact that the name on D-Bus should be allowed to be 
> >> different from the dynamic tty is the main part that you also agree 
> >> on if I understand you correctly. 
> > Yes, I would prefer to do this without more tags, but using the normal
> > symlink scheme that udev already supports well.  This also makes it
> > non-ModemManager-specific since symlinks are often used for other
> > programs as well.
> >
> 
> Same question as in the ModemManager malling list:
> 
> Just for curiosity, how did you plan to find the symbolic link that point to
> the real ttyACMx ?

g_udev_device_get_device_file_symlinks ()

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: dhcpcd support broken

[Dan Williams]

On Tue, 2015-05-26 at 17:49 +, Joakim Tjernlund wrote:
> On Tue, 2015-05-26 at 12:22 -0500, Dan Williams wrote:
> > On Mon, 2015-05-25 at 20:47 +, Joakim Tjernlund wrote:
> > > This commit seems have broken dhcpcd support:
> > > http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/configure.ac?h=nm-1
> > > -0&id=7daf63461de4195b1626ca15f835fc7cbc56e847
> > > 
> > > 
> > >  $ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu 
> > > --host=x86_64-pc-linux-gnu -
> > > -mandir=/usr/share/man -
> > > -infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc 
> > > --localstatedir=/var/lib --disable
> > > -dependency
> > > -tracking --disable-silent-rules --libdir=/usr/lib64 
> > > --docdir=/usr/share/doc/networkmanager-1.0.2 -
> > > -disable
> > > -maintainer-mode --disable-gtk-doc --disable-more-warnings 
> > > --disable-static --localstatedir=/var --disable
> > > -lto
> > > --disable-config-plugin-ibft --disable-ifnet --without-netconfig 
> > > --with-dbus-sys-dir=/etc/dbus-1/system.d 
> > > -
> > > -with-udev-dir=/lib/udev --with-config-plugins-default=keyfile 
> > > --with-iptables=/sbin/iptables --with
> > > -libsoup=yes --enable-concheck --with-crypto=gnutls 
> > > --with-session-tracking=consolekit --with-suspend
> > > -resume=upower --enable-bluez5-dun --enable-introspection --enable-ppp 
> > > --disable-wimax --without-dhclient 
> > > -
> > > -with-dhcpcd --without-modem-manager-1 --with-nmtui --with-resolvconf 
> > > --without-selinux --disable-teamdctl 
> > > -
> > > -disable-tests --enable-vala --without-valgrind --with-wext 
> > > --with-pppd-plugin-dir=/usr/lib64/pppd/2.4.7
> > > 
> > > 
> > > 
> > > configure:23483: checking for dhcpcd
> > > configure:23502: found /sbin/dhcpcd
> > > configure:23514: result: /sbin/dhcpcd
> > > configure:23528: WARNING: Cannot use dhcpcd, version 4.x or higher is 
> > > required
> > > configure:23540: WARNING: Could not find a suitable DHCP client, falling 
> > > back to dhclient
> > 
> > It looks like that commit was wrong, because with the [[ and ]] the []
> > won't get carried through to configure itself.  Could you edit configure
> > and make the dhcpcd grep section look like:
> > 
> >   if test "$with_dhcpcd" != "no"; then
> >   if ! $with_dhcpcd --version 2>&1 | grep -q "^dhcpcd 
> > [456789]\."; then
> >   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: 
> > Cannot use dhcpcd,
> > version 4.x or higher is required" >&5
> > $as_echo "$as_me: WARNING: Cannot use dhcpcd, version 4.x or higher is
> > required" >&2;}
> >   with_dhcpcd=no
> >   elif $with_dhcpcd --version 2>&1 | grep -q "^dhcpcd [789]\."; 
> > then
> > 
> > $as_echo "#define DHCPCD_SUPPORTS_IPV6 1" >>confdefs.h
> > 
> >   fi
> >   fi
> > 
> > and then rerun configure and see if that fixes things?
> 
> It does fix things, although removing the 6 disables IPv6 support, keeping 
> ^dhcpcd [6789]\."
> enables IPv6.

Yeah, that was my fault, it was a local modification for testing.

I've pushed the fix to nm-0-9-10, nm-1-0, and git master.

> I still want to point out that runtime test breaks cross compile(minor) and
> testing version for ipv6 is not enough(major) as dhcpcd can be built without 
> ipv6 support

I suppose instead NM could exec "dhcpcd -V" and then look for the string
"DHCPv6 options:" in the output the first time dhcpcd is run.

Beniamino, could you look into that?

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Configure a connection for a gsm with dynamic ttyACMx

[Dan Williams]

On Tue, 2015-05-26 at 19:04 +0200, Jean-Christian de Rivaz wrote:
> Le 26. 05. 15 18:21, Dan Williams a écrit :
> > On Tue, 2015-05-26 at 16:09 +0200, Jean-Christian de Rivaz wrote:
> >>
> >> Hi Dan,
> >>
> >> My application is a network of embedded systems where each system can
> >> have an internal or an external SIM card. For this kind of use the
> >> device ID or IMSI will not help as there will be different on each
> >> system and I want a unique configuration file that work on all systems.
> > Understood.  In this case your are correct that DeviceID and SimID won't
> > help.  However, be aware that kernel bus enumeration means that specific
> > devices are not guaranteed to be found in the same order, and thus a
> > modem that has ttyACM0 one time may get ttyACM3 the next time.  Also if
> > the modem crashes and disconnects, sometimes if an application holds the
> > serial port open and doesn't close it on disconnect, that tty cannot be
> > re-used when the modem reappears, and a new one will be chosen.
> >
> > So my point is that the only way to get guaranteed matching between a
> > modem and a connection is via the device ID or SIM ID, because kernel
> > enumeration is not guaranteed to be stable and your tty numbers
> > therefore may not be stable.
> 
> The fact that the kernel dynamically assign the ttyACMx number can't be 
> changed I agree, but udev rules precisely allow to match a specific 
> device and to set a variable if the rule match. This is exactly how 
> ModemManager already work with the ID_MM_DEVICE_IGNORE for example. This 
> is a reliable way to identify the port of the modem.
> 
> The proposed idea is to have a udev rule that contain something like 
> this ENV(ID_MM_DEVICE_TAG_NAME)="gsm" if the rule match,  then 
> ModemManager can use the tag 'gsm' as a fixed reference instead of the 
> dynamic ttyACMx. Of course ModemManager will continue to use the dynamic 
> ttyACMx internally to communicate with the modem but will use the 'gsm' 
> tag on the D-Bus so that NetworkManager get a fixed name too.
> 
> Now if you prefer to use the device ID or the SIM ID, ModemManager could 
> be configured by a udev rule like ENV(ID_MM_DEVICE_TAG_TYPE)="device-id" 
> or "sim-id" for example.
> 
> >> An other proposition could be to let's tag the devices from the udev
> >> rules and allow both ModemManager and NetworkManager use the tag to
> >> refer to the device. One advantage of this proposition is that it allow
> > The best way to do this would be to use the udev rules to add symlinks
> > as you've found.  However, since the symlinking is N symlinks to 1
> > kernel device (ttyACMx) ModemManager cannot really use symlinks as the
> > actual control/data port names.
> >
> >> to use this tag differently, for example ModemManager could be
> >> configured to override the tag with the device ID and/or IMSI to fit
> >> your proposed use case.
> >>
> >> While doing my experiment, I used udev rules that created specific
> >> symbolic links for the modem regardless of this actual ttyACMx. If
> >> ModemManager could have a way to be configured to use the specific
> >> symbolic links, then NetworkManager would have see a fixed device name.
> >> This is also an acceptable way for me to solve the problem.
> > I think instead, ModemManager should still use the normal kernel port
> > names.  But it could also read symlink names for the ports and make that
> > available in the D-Bus interface so that NetworkManager or other
> > programs could use them for matching.  What do you think Aleksander?
> 
> This is an alternative of the ENV(ID_MM_DEVICE_TAG_NAME) trick to get 
> the tag name. The fact that the name on D-Bus should be allowed to be 
> different from the dynamic tty is the main part that you also agree on 
> if I understand you correctly.

Yes, I would prefer to do this without more tags, but using the normal
symlink scheme that udev already supports well.  This also makes it
non-ModemManager-specific since symlinks are often used for other
programs as well.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: dhcpcd support broken

[Dan Williams]

On Mon, 2015-05-25 at 20:47 +, Joakim Tjernlund wrote:
> This commit seems have broken dhcpcd support:
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/configure.ac?h=nm-1
> -0&id=7daf63461de4195b1626ca15f835fc7cbc56e847
> 
> 
>  $ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu 
> --host=x86_64-pc-linux-gnu --mandir=/usr/share/man -
> -infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc 
> --localstatedir=/var/lib --disable-dependency
> -tracking --disable-silent-rules --libdir=/usr/lib64 
> --docdir=/usr/share/doc/networkmanager-1.0.2 --disable
> -maintainer-mode --disable-gtk-doc --disable-more-warnings --disable-static 
> --localstatedir=/var --disable-lto
> --disable-config-plugin-ibft --disable-ifnet --without-netconfig 
> --with-dbus-sys-dir=/etc/dbus-1/system.d -
> -with-udev-dir=/lib/udev --with-config-plugins-default=keyfile 
> --with-iptables=/sbin/iptables --with
> -libsoup=yes --enable-concheck --with-crypto=gnutls 
> --with-session-tracking=consolekit --with-suspend
> -resume=upower --enable-bluez5-dun --enable-introspection --enable-ppp 
> --disable-wimax --without-dhclient -
> -with-dhcpcd --without-modem-manager-1 --with-nmtui --with-resolvconf 
> --without-selinux --disable-teamdctl -
> -disable-tests --enable-vala --without-valgrind --with-wext 
> --with-pppd-plugin-dir=/usr/lib64/pppd/2.4.7
> 
> 
> 
> configure:23483: checking for dhcpcd
> configure:23502: found /sbin/dhcpcd
> configure:23514: result: /sbin/dhcpcd
> configure:23528: WARNING: Cannot use dhcpcd, version 4.x or higher is required
> configure:23540: WARNING: Could not find a suitable DHCP client, falling back 
> to dhclient

It looks like that commit was wrong, because with the [[ and ]] the []
won't get carried through to configure itself.  Could you edit configure
and make the dhcpcd grep section look like:

if test "$with_dhcpcd" != "no"; then
if ! $with_dhcpcd --version 2>&1 | grep -q "^dhcpcd 
[456789]\."; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: 
Cannot use dhcpcd,
version 4.x or higher is required" >&5
$as_echo "$as_me: WARNING: Cannot use dhcpcd, version 4.x or higher is
required" >&2;}
with_dhcpcd=no
elif $with_dhcpcd --version 2>&1 | grep -q "^dhcpcd [789]\."; 
then

$as_echo "#define DHCPCD_SUPPORTS_IPV6 1" >>confdefs.h

fi
fi

and then rerun configure and see if that fixes things?

dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Ignore virtual interfaces of WiFi devices

[Dan Williams]

On Mon, 2015-05-25 at 19:39 +, Patrick Brauer wrote:
> Hello,
> 
> I tried to get NetworkManager to ignore a virtual interface i want
> to use for a mesh network. I want to have NetworkManager
> working on some devices in parallel to the mesh networking setup.
> So i tried to list the device name and/or MAC address in
> /etc/NetworkManager/NetworkManager.conf like this:
> 
> [main]
> plugins=keyfile
> [keyfile]
> unmanaged-devices=mac:XX:XX:XX:XX:XX:XX;interface-name:mesh0
> 
> However, this did not work. When i used the MAC address of the mesh0
> interface NetworkManager did not care about this setting. When i used
> the MAC address of the original device controlled by NetworkManager
> before, it ignores both interfaces. Is it somehow possible to ignore
> the virtual interface alone? I could guess NetworkManager does this
> because it would not know the state of the physical interface at any
> time, but i would like to have to deal with that problems by myself.

Which version of NetworkManager is this with?  Also, are you restarting
NM after modifying the config file?

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Configure a connection for a gsm with dynamic ttyACMx

[Dan Williams]

On Tue, 2015-05-26 at 16:09 +0200, Jean-Christian de Rivaz wrote:
> Le 26. 05. 15 15:28, Dan Williams a écrit :
> > On Tue, 2015-05-26 at 08:34 +0200, Thomas Haller wrote:
> >>
> >> Just leave "connection.interface-name" unspecified, for example via:
> >>
> >> $ nmcli connection modify NAME connection.interface-name ""
> > It's important to note that this is the ModemManager *control port*,
> > which can be a TTY, a cdc-wdm, etc.
> >
> > One thing we want to do, but haven't done yet, is to add a way to lock
> > the connection to the device ID and/or the SIM ID (IMSI), which should
> > often be more useful than the control port itself.
> >
> 
> Hi Dan,
> 
> My application is a network of embedded systems where each system can 
> have an internal or an external SIM card. For this kind of use the 
> device ID or IMSI will not help as there will be different on each 
> system and I want a unique configuration file that work on all systems. 

Understood.  In this case your are correct that DeviceID and SimID won't
help.  However, be aware that kernel bus enumeration means that specific
devices are not guaranteed to be found in the same order, and thus a
modem that has ttyACM0 one time may get ttyACM3 the next time.  Also if
the modem crashes and disconnects, sometimes if an application holds the
serial port open and doesn't close it on disconnect, that tty cannot be
re-used when the modem reappears, and a new one will be chosen.

So my point is that the only way to get guaranteed matching between a
modem and a connection is via the device ID or SIM ID, because kernel
enumeration is not guaranteed to be stable and your tty numbers
therefore may not be stable.

> An other proposition could be to let's tag the devices from the udev 
> rules and allow both ModemManager and NetworkManager use the tag to 
> refer to the device. One advantage of this proposition is that it allow 

The best way to do this would be to use the udev rules to add symlinks
as you've found.  However, since the symlinking is N symlinks to 1
kernel device (ttyACMx) ModemManager cannot really use symlinks as the
actual control/data port names.

> to use this tag differently, for example ModemManager could be 
> configured to override the tag with the device ID and/or IMSI to fit 
> your proposed use case.
> 
> While doing my experiment, I used udev rules that created specific 
> symbolic links for the modem regardless of this actual ttyACMx. If 
> ModemManager could have a way to be configured to use the specific 
> symbolic links, then NetworkManager would have see a fixed device name. 
> This is also an acceptable way for me to solve the problem.

I think instead, ModemManager should still use the normal kernel port
names.  But it could also read symlink names for the ports and make that
available in the D-Bus interface so that NetworkManager or other
programs could use them for matching.  What do you think Aleksander?

(note that we cannot change the kernel name (eg ttyUSB0 or ACM1) because
udev/kernel do not allow doing that; they only allow creating symlinks
to the kernel device.  Yes, you can 'mv ttyACM0 modem0' but that breaks
udev's 'by-id' symlinks so it's not a great option)

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Configure a connection for a gsm with dynamic ttyACMx

[Dan Williams]

On Tue, 2015-05-26 at 08:34 +0200, Thomas Haller wrote:
> On Tue, 2015-05-26 at 00:37 +0200, Jean-Christian de Rivaz wrote:
> > Hello,
> > 
> > I have a system where the modem have multiple /dev/ttyACMx ports where x 
> > is not constant because of the dynamic nature of others serial devices. 
> > ModemManager always detect the rights ttyACMx of the modem
> 
> 
> 
> > but 
> > NetworkManager only allow to configure a connection for a fixed device.
> 
> this is not correct.
> 
> Just leave "connection.interface-name" unspecified, for example via:
> 
>$ nmcli connection modify NAME connection.interface-name ""

It's important to note that this is the ModemManager *control port*,
which can be a TTY, a cdc-wdm, etc.

One thing we want to do, but haven't done yet, is to add a way to lock
the connection to the device ID and/or the SIM ID (IMSI), which should
often be more useful than the control port itself.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Compiling NetworkManager-openconnect version and flags?

[Dan Williams]

x27;
>   OPENCONNECT_X509 *peer_cert;
>   ^
> main.c: In function 'user_validate_cert':
> main.c:833:10: warning: assignment makes pointer from integer without a
> cast [enabled by default]
>   details = openconnect_get_cert_details(ui_data->vpninfo, data->peer_cert);
>   ^
> main.c: At top level:
> main.c:881:10: error: unknown type name 'OPENCONNECT_X509'
>   OPENCONNECT_X509 *peer_cert, const char *reason)
>   ^
> main.c: In function 'cookie_obtained':
> main.c:1285:3: error: unknown type name 'OPENCONNECT_X509'
>OPENCONNECT_X509 *cert;
>^
> main.c:1307:8: warning: assignment makes pointer from integer without a
> cast [enabled by default]
>cert = openconnect_get_peer_cert (ui_data->vpninfo);
> ^
> main.c: In function 'init_ui_data':
> main.c:1645:11: error: 'validate_peer_cert' undeclared (first use in this
> function)
>validate_peer_cert, write_new_config,
>    ^
> main.c:1645:11: note: each undeclared identifier is reported only once for
> each function it appears in
> main.c:1647:11: warning: passing argument 3 of 'openconnect_vpninfo_new'
> from incompatible pointer type [enabled by default]
>ui_data);
>^
> In file included from main.c:51:0:
> /usr/include/openconnect.h:537:26: note: expected
> 'openconnect_write_new_config_vfn' but argument is of type 'int (*)(void *,
> char *, int)'
>  struct openconnect_info *openconnect_vpninfo_new(const char *useragent,
>   ^
> Makefile:481: recipe for target 'nm_openconnect_auth_dialog-main.o' failed
> make[2]: *** [nm_openconnect_auth_dialog-main.o] Error 1
> make[2]: Leaving directory
> '/ts/ports/contrib/networkmanager-openconnect/network-manager-openconnect-0-9-6/auth-dialog'
> Makefile:519: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> '/ts/ports/contrib/networkmanager-openconnect/network-manager-openconnect-0-9-6'
> Makefile:408: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> [root@TS_chroot]/ts/ports/contrib/networkmanager-openconnect/network-manage
> r-openconnect-0-9-6#
> 
> 
> On Fri, May 22, 2015 at 11:13 AM, Dan Williams  wrote:
> 
> > On Fri, 2015-05-22 at 09:36 -0700, a.priori ibid wrote:
> > > While 'make'ing 0.9.6 from github, I got the following error. Any advice?
> >
> > Try passing --enable-more-warnings=no to configure.  Does that help?
> >
> > Dan
> >
> > > # make
> > > (CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
> > >
> > /ts/ports/contrib/networkmanager-openconnect/network-manager-openconnect-0-9-6/missing
> > > autoheader)
> > > rm -f stamp-h1
> > > touch config.h.in
> > > cd . && /bin/sh ./config.status config.h
> > > config.status: creating config.h
> > > config.status: config.h is unchanged
> > > make  all-recursive
> > > make[1]: Entering directory
> > >
> > '/ts/ports/contrib/networkmanager-openconnect/network-manager-openconnect-0-9-6'
> > > Making all in src
> > > make[2]: Entering directory
> > >
> > '/ts/ports/contrib/networkmanager-openconnect/network-manager-openconnect-0-9-6/src'
> > > depbase=`echo nm-openconnect-service.o | sed
> > 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> > > gcc -DHAVE_CONFIG_H -I. -I.. -I..  -I/usr/include/dbus-1.0
> > > -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
> > > -I/usr/lib/glib-2.0/include  -pthread -I/usr/include/glib-2.0
> > > -I/usr/lib/glib-2.0/include  -I/usr/include/NetworkManager
> > > -I/usr/include/libnm-glib -I/usr/include/NetworkManager
> > > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
> > -I/usr/include/glib-2.0
> > > -I/usr/lib/glib-2.0/include  -DG_DISABLE_DEPRECATED
> > > -DBINDIR=\"/usr/local/bin\" -DPREFIX=\""/usr/local"\"
> > > -DSYSCONFDIR=\""/usr/local/etc"\" -DVERSION="\"0.9.6.2\""
> > > -DLIBDIR=\""/usr/local/lib"\" -DLIBEXECDIR=\""/usr/local/libexec"\"
> > > -DLOCALSTATEDIR=\""/usr/local/var"\" -DDATADIR=\"/usr/local/share\"
> >  -Wall
> > > -std=gnu89 -g -O2 -Wshadow -Wmissing-declarations -Wmissing-prototypes
> > > -Wdeclaration-after-statement -Wstrict-prototypes -Wfloat-equal
> > > -Wno-unused-parameter -Wno-sig

Re: Compiling NetworkManager-openconnect version and flags?

[Dan Williams]

On Fri, 2015-05-22 at 06:29 -0700, a.priori ibid wrote:
> Thinstation uses NetworkManager 0.9.6.4. I dont see that version of source
> at  http://ftp.gnome.org/pub/GNOME/sources/NetworkManager-openconnect/0.9/
> 
> Which can I use?
> 0.9.5.95
> 0.9.6.0
> 0.9.6.2
> 0.9.8.0
> 
> When I did try to compile 1.0.2, I got this error

The NetworkManager VPN plugin versions are closely matched with
NetworkManager itself, so you want to use the plugin that's closest to
the NM version.  I would use 0.9.6.2.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [vpn-manager/nm-vpn-connection.c:1778] get_secrets_cb(): Failed to request VPN secrets

[Dan Williams]

On Tue, 2015-05-19 at 09:43 +, solsTiCe d'Hiver wrote:
> hi.
> 
> Sometimes, when I wake up my laptop from suspend, I am unable to 
> reconnect to my VPN.
> 
> I found this error in the log:
> [vpn-manager/nm-vpn-connection.c:1778] get_secrets_cb(): Failed to request 
> VPN secrets #2: (6) No agents were available for this request.
> 
> The secret for the VPN is stored in the keyring. so it should not failed.
> Even if I restart NetworkManager.service or nm-applet, I can't connect 
> manually to the VPN.
> 
> I don't see why the keyring would not be running or dbus would have failed 
> for some reason.
> 
> I don't know how to fix that every time and I am left with the only 
> option to reboot (sight).
> 
> Is the recent patch "vpn: don't fail if no system secrets exist" supposed 
> to address that issue ?

Yes, that certainly might fix the issue.  I've cherry-picked that to NM
1.0.x too.  If you apply that patch to your copy of NM does that make
things work better?  It should apply cleanly to NM 1.0.2.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager/nm-applet doesn't recognize my wired connection

[Dan Williams]

On Thu, 2015-05-14 at 18:34 +0200, Thomas Haller wrote:
> On Thu, 2015-05-14 at 12:06 -0400, Caesar Samsi wrote:
> > Hi Thomas, here they are:
> > 
> > >>  nmcli con list:
> > 
> > caesar@ubuntubase:~$ nmcli con list
> > NAME  UUID   TYPE   
> >TIMESTAMP-REAL   
> > 
> > >>  nmcli con status:
> > caesar@ubuntubase:~$ nmcli con status
> > NAME  UUID   DEVICES
> > DEFAULT  VPN   MASTER-PATH   
> > 
> 
> 
> try creating a connection. For example using nm-connection-editor.
> 
> For that, click with the right button on nm-applet and select "Edit
> Connections...".

Actually the device is unmanaged.  By default on Ubuntu/Debian, anything
listed in /etc/network/interfaces is unmanaged by NetworkManager.  So if
you have anything there, remove it, restart NM, and now NM should be
allowed to manage the ethernet interface.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nm-applet not running

[Dan Williams]

On Thu, 2015-05-14 at 10:20 +0200, jean-christophe manciot wrote:
> Hello guys,
> I have compiled and installed NetworkManager from the git sources on Ubuntu
> Server 15.04.
> I can see NetworkManager is running but not nm-applet.
> What should be done?

nm-applet is in a separate git repository than NetworkManager itself,
since the core daemon is desktop agnostic.  The applet's git repo is at
https://git.gnome.org/browse/network-manager-applet .

nm-applet is normally run automatically at login by your session
manager.  You can start it manually if you'd like (just run nm-applet)
but it needs a "notification area" to display itself in.

I'm not sure if there's still a notification area in ubuntu 15.04 since
they have moved to indicators.  Only nm-applet git master has support
for indicators, and to build that support you need a couple more
development libraries (libappindicator) and you also must pass
--with-appindicator when configuring/autogen-ing the applet.  Once
that's done, you can still run it manually (or via your session manager
at login) and it should pop into the normal indicator area in the
top-right.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nm_netlink_monitor_attach seg fault v0.9.4.0

[Dan Williams]

On Thu, 2015-05-14 at 13:19 +0100, Nick Carter wrote:
> Hi,
> 
> NetworkManager is seg faulting for me on Debian Wheezy network-manager
> v0.9.4.0.   Is this a known issue ?
> 
> (gdb) p *self->parent.g_type_instance.g_class
> Cannot access memory at address 0x23802f89006fea00
> 
> If i boot off a live cd, all is fine, so I dont think I have h/w issue.
> If i use /etc/network/interfaces then networking is fine.

Can you compare the version of the 'libnl' and 'libnl-3' packages on the
livecd and the normal install?  Also if possible, could you run
NetworkManager under valgrind in the normal install to see if it turns
up any memory errors?

0.9.4 is unfortunately over 3 years old at this point and not maintained
any more, but if it's an easy fix perhaps the Debian folks could add the
patch to Wheezy.

Dan

> Thanks
> Nick
> 
> ncarter@###:~/network-manager-0.9.4.0/src$ sudo gdb -args
> /usr/sbin/NetworkManager --no-daemon
> [sudo] password for ncarter:
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  >
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/sbin/NetworkManager...Reading symbols from
> /usr/lib/debug/usr/sbin/NetworkManager...done.
> done.
> (gdb) run
> Starting program: /usr/sbin/NetworkManager --no-daemon
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x77ffa000
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> NetworkManager[12169]:  NetworkManager (version 0.9.4.0) is
> starting...
> NetworkManager[12169]:  Read config file
> /etc/NetworkManager/NetworkManager.conf
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0046182e in nm_netlink_monitor_attach (self=0x6f5cc0)
> at nm-netlink-monitor.c:477
> 477 g_return_if_fail (NM_IS_NETLINK_MONITOR (self));
> 
> gdb) bt
> #0  0x0046182e in nm_netlink_monitor_attach (self=0x6f5cc0)
> at nm-netlink-monitor.c:477
> #1  0x00462514 in nm_netlink_monitor_get ()
> at nm-netlink-monitor.c:822
> #2  0x00425357 in main (argc=1, argv=0x7fffe6a8) at main.c:544
> (gdb) f 1
> #1  0x00462514 in nm_netlink_monitor_get ()
> at nm-netlink-monitor.c:822
> 822 nm_netlink_monitor_attach (singleton);
> 
> (gdb) p self
> $23 = (NMNetlinkMonitor *) 0x6f5cc0
> (gdb) p *self
> $24 = {parent = {g_type_instance = {g_class = 0x23802f89006fea00},
> ref_count = 1, qdata = 0x0}}
> (gdb) p self->parent
> $25 = {g_type_instance = {g_class = 0x23802f89006fea00}, ref_count = 1,
> qdata = 0x0}
> (gdb) p self->parent.g_type_instance
> $26 = {g_class = 0x23802f89006fea00}
> (gdb) p self->parent.g_type_instance.g_class
> $27 = (GTypeClass *) 0x23802f89006fea00
> (gdb) p *self->parent.g_type_instance.g_class
> Cannot access memory at address 0x23802f89006fea00
> 
> . so i assume this is the crash ?
> #  define _G_TYPE_CIT(ip, gt) (G_GNUC_EXTENSION ({ \
> #GTypeInstance *__inst = (GTypeInstance*) ip; GType __t = gt; gboolean
> __r; \
> #  if (!__inst) \
> #  __r = FALSE; \
> #else if (__inst->g_class && __inst->g_class->g_type == __t) \
> #
> ___
> 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: nm-applet source code

[Dan Williams]

On Wed, 2015-05-13 at 10:39 -0400, Robert Heller wrote:
> Where is the source code for nm-applet?  I can't seem to find it.

It lives in GNOME git here:

https://git.gnome.org/browse/network-manager-applet

Dan


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: wifi cannot connect to AP anymore fedora 21/22 beta

[Dan Williams]

On Sat, 2015-05-09 at 19:11 +0200, Henning Skoglund wrote:
> Hi! I have serious issues with wifi access at the moment. I cannot connect
> anymore with NetworkManager. I am experiencing "mai 09 15:26:09 satellite
> NetworkManager[14956]:   (wlp7s0): add_pending_action (2): 'waiting
> for supplicant' already pending
> mai 09 15:26:09 satellite NetworkManager[14956]: file devices/nm-device.c:
> line 6503 (nm_device_add_pending_action): should not be reached".

I believe the problem behind that line has been fixed recently, but in
any case it's actually something you can ignore.

The larger problem appears to be that wpa_supplicant has died (that's
the disconnect -3 issue), and then after resume from sleep the wifi
driver cannot connect to the AP.  This is likely a driver problem.  One
thing you can try is to 'rmmod' the driver, then 'modprobe' it again,
and see if that fixes the issue.  If it does, then the problem is likely
in the kernel driver.  If you've got any questions about that, reply
with your 'lsmod' output and we'll identify the kernel driver on your
system from it, which you'll use for the rmmod.

Also useful would be the 'dmesg' output of your system when it cannot
connect, which might provide more details about why the driver cannot
talk to the AP.

Dan

> Here an excerpt of the log:
> 
> mai 09 15:26:10 satellite NetworkManager[14956]:   wpa_supplicant
> started
> mai 09 15:26:10 satellite NetworkManager[14956]:   (wlp7s0) supports
> 5 scan SSIDs
> mai 09 15:26:10 satellite NetworkManager[14956]:   (wlp7s0):
> supplicant interface state: starting -> ready
> mai 09 15:26:10 satellite NetworkManager[14956]:   (wlp7s0): device
> state change: unavailable -> disconnected (reason 'supplicant-available') [2
> mai 09 15:26:10 satellite NetworkManager[14956]:   (wlp7s0):
> supplicant interface state: ready -> disconnected
> mai 09 15:26:10 satellite NetworkManager[14956]:   (wlp7s0) supports
> 5 scan SSIDs
> mai 09 15:26:13 satellite NetworkManager[14956]:   Auto-activating
> connection 'Skoglund'.
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) starting connection 'Skoglund'
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 1 of 5 (Device Prepare) scheduled...
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 1 of 5 (Device Prepare) started...
> mai 09 15:26:13 satellite NetworkManager[14956]:   (wlp7s0): device
> state change: disconnected -> prepare (reason 'none') [30 40 0]
> mai 09 15:26:13 satellite NetworkManager[14956]:   NetworkManager
> state is now CONNECTING
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 2 of 5 (Device Configure) scheduled...
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 1 of 5 (Device Prepare) complete.
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 2 of 5 (Device Configure) starting...
> mai 09 15:26:13 satellite NetworkManager[14956]:   (wlp7s0): device
> state change: prepare -> config (reason 'none') [40 50 0]
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0/wireless): access point 'Skoglund' has security, but secrets are
> required.
> mai 09 15:26:13 satellite NetworkManager[14956]:   (wlp7s0): device
> state change: config -> need-auth (reason 'none') [50 60 0]
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 2 of 5 (Device Configure) complete.
> mai 09 15:26:13 satellite NetworkManager[14956]:   (wlp7s0):
> supplicant interface state: disconnected -> inactive
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 1 of 5 (Device Prepare) scheduled...
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 1 of 5 (Device Prepare) started...
> mai 09 15:26:13 satellite NetworkManager[14956]:   (wlp7s0): device
> state change: need-auth -> prepare (reason 'none') [60 40 0]
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 2 of 5 (Device Configure) scheduled...
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 1 of 5 (Device Prepare) complete.
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0) Stage 2 of 5 (Device Configure) starting...
> mai 09 15:26:13 satellite NetworkManager[14956]:   (wlp7s0): device
> state change: prepare -> config (reason 'none') [40 50 0]
> mai 09 15:26:13 satellite NetworkManager[14956]:   Activation
> (wlp7s0/wireless): connection 'Skoglund' has security, and secrets exist.
> No new
> mai 09 15:26:13 satellite NetworkManager[14956]:   Config: added
> 'ssid' value 'Skoglund'
> mai 09 15:26:13 satellite NetworkManager[14956]:   Config: added
> 'scan_ssid' value '1'
> mai 09 15:26:13 satellite NetworkManager[14956]:   Config: added
> 'key_mgmt' value 'WPA-PSK'
> mai 09 15:26:13 satellite NetworkManager[14956]:   Config: added
> 'psk' value ''
> mai 09 15:26:13 satelli

Re: NetworkManager configure stops with error

[Dan Williams]

On Sun, 2015-05-10 at 23:57 -0400, Caesar Samsi wrote:
> Hello,
> 
>  
> 
> The error message shows:
> 
>  
> 
> configure: error: readline library with terminfo support is required (one of
> ncurses, curses, or termcap)
> 
>  
> 
> I thought this was related to libncurses so I installed libncurses5 and
> libncurses5-dev

It turns out the error comment is wrong; ncurses is not actually a
readline implementation, it's used instead for termcap support in
addition to another readline library.  So you'll want to install the
development package for libreadline, libedit, or libeditline I think.

I've corrected the message in git, thanks for the report!

Dan

> However, the error persists.
> 
>  
> 
> Which package does it need for this error?
> 
>  
> 
> Thank you, Caesar.
> 
> ___
> 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: ModemManager and Thuraya XT

[Dan Williams]

On Tue, 2015-05-05 at 12:21 +0200, Thomas Sailer wrote:
> I would like to use my Thuraya XT phone (firmware v5) with ModemManager.
> It seems to be detected but then MM seems to choke on its response to
> AT+CGREG?.
> 
> Below is the dialog between MM (1.4.4, stock fedora 21) with the phone
> after it has acquired the network.
> 
> Does anyone have an idea how to make it work?

It's going to need a regex update in ModemManager; here's a link to a
test package with that possible fix:

http://koji.fedoraproject.org/koji/taskinfo?taskID=9661653

Can you test that out and see if you get farther with the XT?

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] vpn: don't fail if no system secrets exist

[Dan Williams]

On Mon, 2015-05-04 at 13:56 +0200, Thomas Haller wrote:
> On Fri, 2015-05-01 at 15:15 -0500, Dan Williams wrote:
> > The VPN connection requests secrets a few times; first it retrieves
> > only system-owned secrets to see if they are sufficient (and thus
> > doesn't need to bother the user), then it retrieves existing agent
> > owned secrets (so the user doesn't get a popup), then finally if
> > those aren't sufficient it asks the user interactively.
> > 
> > But if there was some error retrieving system secrets, or if there
> > weren't any system secrets at all, don't fail the VPN connection.
> > Just go on and ask the user for the secrets.
> > ---
> >  src/vpn-manager/nm-vpn-connection.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> LGTM

Merged to master.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] vpn: don't fail if no system secrets exist

[Dan Williams]

The VPN connection requests secrets a few times; first it retrieves
only system-owned secrets to see if they are sufficient (and thus
doesn't need to bother the user), then it retrieves existing agent
owned secrets (so the user doesn't get a popup), then finally if
those aren't sufficient it asks the user interactively.

But if there was some error retrieving system secrets, or if there
weren't any system secrets at all, don't fail the VPN connection.
Just go on and ask the user for the secrets.
---
 src/vpn-manager/nm-vpn-connection.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/vpn-manager/nm-vpn-connection.c 
b/src/vpn-manager/nm-vpn-connection.c
index d240804..4329cb2 100644
--- a/src/vpn-manager/nm-vpn-connection.c
+++ b/src/vpn-manager/nm-vpn-connection.c
@@ -1937,7 +1937,7 @@ get_secrets_cb (NMSettingsConnection *connection,
 
priv->secrets_id = 0;
 
-   if (error) {
+   if (error && priv->secrets_idx >= SECRETS_REQ_NEW) {
nm_log_err (LOGD_VPN, "Failed to request VPN secrets #%d: (%d) 
%s",
priv->secrets_idx + 1, error->code, error->message);
_set_vpn_state (self, STATE_FAILED, 
NM_VPN_CONNECTION_STATE_REASON_NO_SECRETS, FALSE);
-- 
2.1.0


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/2] core: add nm_utils_monotonic_timestamp_as_boottime() function

[Dan Williams]

On Wed, 2015-04-29 at 08:02 +0200, Thomas Haller wrote:
> On Tue, 2015-04-28 at 17:37 -0500, Dan Williams wrote:
> > On Tue, 2015-04-28 at 00:41 +0200, Thomas Haller wrote:
> > > On Mon, 2015-04-27 at 16:31 -0500, Dan Williams wrote:
> > > > On Wed, 2015-04-22 at 12:50 +0200, Thomas Haller wrote:
> > > > > On Tue, 2015-04-21 at 12:47 -0500, Dan Williams wrote:
> > > > > > On Tue, 2015-04-21 at 19:19 +0200, Thomas Haller wrote:
> > > > > > > On Tue, 2015-04-21 at 19:04 +0200, Thomas Haller wrote:
> > > > > > > > On Tue, 2015-04-21 at 11:48 -0400, Mathieu Trudel-Lapierre 
> > > > > > > > wrote:
> > > > > > > > > From: Thomas Haller 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > I pushed both patches to upstream branch mtl/wifi-ap-last-seen 
> > > > > > > > for
> > > > > > > > easier review.
> > > > > > > > 
> > > > > > > > And I added two fixup commits with changes I that I suggest.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Thomas
> > > > > > > 
> > > > > > > 
> > > > > > > maybe it would be better to expose the timestamp as singed int in 
> > > > > > > libnm
> > > > > > > so that we can signal "unseen" by setting -1. G_MAXUINT32 is not 
> > > > > > > very
> > > > > > > intuitive.
> > > > > > 
> > > > > > I'd actually rather do '0' == unseen and keep it u32...
> > > > > 
> > > > > why do you prefer that?
> > > > > 
> > > > > '0' is a valid timestamp. IMO it should be overloaded with a
> > > > > 'never-seen' meaning. 
> > > > 
> > > > Well, technically yes, but you will never, ever get that value because
> > > > scan results will never happen that quickly :)  I was going to write a
> > > > paragraph about why I wanted it u32, but in this case it doesn't matter
> > > > since the max last-seen value will never be > 240 or so.  So sure, lets
> > > > just make everything s32 and use -1 as the "never seen" value.
> > > > 
> > > > I fixed this up and squashed the branch.  Look OK?
> > > 
> > > Pushed two fixups. With them it LGTM.
> > > 
> > > 
> > > Note that with gint32, we still have a range of 68 years (uptime of the
> > > system). No need to double that by using guint32.
> > 
> > Looks good.
> 
> 
> merged:
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=39aa27c32f9493111d9efa3b65d3ad9505afa960
> 
> (did a further minor change to the API of libnm to have all types as
> "gint", not "gint32". It was mixed before, and I decided for the former.
> 
> 
> 
> > What do you think about 1.0.2 for this branch?
> 
> Hm, yeah... but it's new public API.
> We didn't yet introduce any new API for 1.0.2 and it's kinda complicated
> (as discussed here:
> https://bugzilla.gnome.org/show_bug.cgi?id=742993#c21 )

I had local patches that added everything to the 1.0.2 section, but I
guess you merged the branch already.  I suppose if we backport to 1.0.4,
we could just move the symbols from 1.2 -> the 1.0.4 section before a
1.2 release?

Dan

> Thomas
> 
> 
> 
> > 
> > Dan
> > 
> > 
> > > Thomas
> > > 
> > > > 
> > > > Dan
> > > > 
> > > > > 
> > > > > Thomas
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > Dan
> > > > > > 
> > > > > > > A gint32 is still large enough, unless you run your machine 
> > > > > > > without
> > > > > > > reboot for 68+ years.
> > > > > > > 
> > > > > > > There isn't a Year 2038 problem, because the counter starts at 
> > > > > > > last
> > > > > > > boot, not in 1970.
> > > > > > > 
> > > > > > > 
> > > > > > > Thomas
> > > > > > > ___
> > > > > > > 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: NM coding style regarding private gobject data

[Dan Williams]

On Wed, 2015-04-29 at 16:33 +0200, Aleksander Morgado wrote:
> On Wed, Apr 29, 2015 at 2:49 PM, Thomas Haller  wrote:
> > It's my personal annoyance with the verboseness of:
> >
> >
> >   NM_TYPE_NAME_GET_PRIVATE (self)->my_field
> >   nm_type_name_get_instance_private (self)->my_field
> >
> >   vs.
> >
> >   self->priv->my_field
> >
> >
> >
> > Bonus point: it's easier in gdb/debugger.
> 
> I personally also prefer to waste a pointer per object and have
> self->priv, truth be told, even if the new get_instance_private ()
> macros are pointer arithmetic only.

I'm personally fine with self->priv, but ISTR the last time this came up
Pavel had some objections to it based around type-safety I think?
GET_PRIVATE() does type-checking, while of course direct pointer access
doesn't.  Or something like that.  But of course if GET_PRIVATE()
returns NULL and we dereference that to get the private data anyway,
it'll still crash just like self->priv on a bogus pointer.

In any case, I'm fine with moving in that direction, but we should dig
up what Pavel's objection was just for reference.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/2] core: add nm_utils_monotonic_timestamp_as_boottime() function

[Dan Williams]

On Tue, 2015-04-28 at 00:41 +0200, Thomas Haller wrote:
> On Mon, 2015-04-27 at 16:31 -0500, Dan Williams wrote:
> > On Wed, 2015-04-22 at 12:50 +0200, Thomas Haller wrote:
> > > On Tue, 2015-04-21 at 12:47 -0500, Dan Williams wrote:
> > > > On Tue, 2015-04-21 at 19:19 +0200, Thomas Haller wrote:
> > > > > On Tue, 2015-04-21 at 19:04 +0200, Thomas Haller wrote:
> > > > > > On Tue, 2015-04-21 at 11:48 -0400, Mathieu Trudel-Lapierre wrote:
> > > > > > > From: Thomas Haller 
> > > > > > 
> > > > > > 
> > > > > > I pushed both patches to upstream branch mtl/wifi-ap-last-seen for
> > > > > > easier review.
> > > > > > 
> > > > > > And I added two fixup commits with changes I that I suggest.
> > > > > > 
> > > > > > 
> > > > > > Thomas
> > > > > 
> > > > > 
> > > > > maybe it would be better to expose the timestamp as singed int in 
> > > > > libnm
> > > > > so that we can signal "unseen" by setting -1. G_MAXUINT32 is not very
> > > > > intuitive.
> > > > 
> > > > I'd actually rather do '0' == unseen and keep it u32...
> > > 
> > > why do you prefer that?
> > > 
> > > '0' is a valid timestamp. IMO it should be overloaded with a
> > > 'never-seen' meaning. 
> > 
> > Well, technically yes, but you will never, ever get that value because
> > scan results will never happen that quickly :)  I was going to write a
> > paragraph about why I wanted it u32, but in this case it doesn't matter
> > since the max last-seen value will never be > 240 or so.  So sure, lets
> > just make everything s32 and use -1 as the "never seen" value.
> > 
> > I fixed this up and squashed the branch.  Look OK?
> 
> Pushed two fixups. With them it LGTM.
> 
> 
> Note that with gint32, we still have a range of 68 years (uptime of the
> system). No need to double that by using guint32.

Looks good.

What do you think about 1.0.2 for this branch?

Dan


> Thomas
> 
> > 
> > Dan
> > 
> > > 
> > > Thomas
> > > 
> > > 
> > > 
> > > > 
> > > > Dan
> > > > 
> > > > > A gint32 is still large enough, unless you run your machine without
> > > > > reboot for 68+ years.
> > > > > 
> > > > > There isn't a Year 2038 problem, because the counter starts at last
> > > > > boot, not in 1970.
> > > > > 
> > > > > 
> > > > > Thomas
> > > > > ___
> > > > > 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/2] core: add nm_utils_monotonic_timestamp_as_boottime() function

[Dan Williams]

On Wed, 2015-04-22 at 12:50 +0200, Thomas Haller wrote:
> On Tue, 2015-04-21 at 12:47 -0500, Dan Williams wrote:
> > On Tue, 2015-04-21 at 19:19 +0200, Thomas Haller wrote:
> > > On Tue, 2015-04-21 at 19:04 +0200, Thomas Haller wrote:
> > > > On Tue, 2015-04-21 at 11:48 -0400, Mathieu Trudel-Lapierre wrote:
> > > > > From: Thomas Haller 
> > > > 
> > > > 
> > > > I pushed both patches to upstream branch mtl/wifi-ap-last-seen for
> > > > easier review.
> > > > 
> > > > And I added two fixup commits with changes I that I suggest.
> > > > 
> > > > 
> > > > Thomas
> > > 
> > > 
> > > maybe it would be better to expose the timestamp as singed int in libnm
> > > so that we can signal "unseen" by setting -1. G_MAXUINT32 is not very
> > > intuitive.
> > 
> > I'd actually rather do '0' == unseen and keep it u32...
> 
> why do you prefer that?
> 
> '0' is a valid timestamp. IMO it should be overloaded with a
> 'never-seen' meaning. 

Well, technically yes, but you will never, ever get that value because
scan results will never happen that quickly :)  I was going to write a
paragraph about why I wanted it u32, but in this case it doesn't matter
since the max last-seen value will never be > 240 or so.  So sure, lets
just make everything s32 and use -1 as the "never seen" value.

I fixed this up and squashed the branch.  Look OK?

Dan

> 
> Thomas
> 
> 
> 
> > 
> > Dan
> > 
> > > A gint32 is still large enough, unless you run your machine without
> > > reboot for 68+ years.
> > > 
> > > There isn't a Year 2038 problem, because the counter starts at last
> > > boot, not in 1970.
> > > 
> > > 
> > > Thomas
> > > ___
> > > 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/2] core: add nm_utils_monotonic_timestamp_as_boottime() function

[Dan Williams]

On Tue, 2015-04-21 at 19:19 +0200, Thomas Haller wrote:
> On Tue, 2015-04-21 at 19:04 +0200, Thomas Haller wrote:
> > On Tue, 2015-04-21 at 11:48 -0400, Mathieu Trudel-Lapierre wrote:
> > > From: Thomas Haller 
> > 
> > 
> > I pushed both patches to upstream branch mtl/wifi-ap-last-seen for
> > easier review.
> > 
> > And I added two fixup commits with changes I that I suggest.
> > 
> > 
> > Thomas
> 
> 
> maybe it would be better to expose the timestamp as singed int in libnm
> so that we can signal "unseen" by setting -1. G_MAXUINT32 is not very
> intuitive.

I'd actually rather do '0' == unseen and keep it u32...

Dan

> A gint32 is still large enough, unless you run your machine without
> reboot for 68+ years.
> 
> There isn't a Year 2038 problem, because the counter starts at last
> boot, not in 1970.
> 
> 
> Thomas
> ___
> 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: Fwd: Welcome to the "networkmanager-list" mailing list

[Dan Williams]

On Fri, 2015-04-17 at 12:23 -0500, Neil Steiner wrote:
> In a recent upgrade for Fedora 21 version 3.14.2, I got this error message:
> 
> FAILED TO UPDATE
> 
> The offline update failed in an unexpected way.
> Detailed errors from the package manager follow:
> 
> Failed to find NetworkManager-openvpn;1:1.0.0-2.fc21;x86_64;updates

That sounds more like an out-of-date updates mirror.  If you run "sudo
yum upgrade NetworkManager-openvpn" from a terminal, what exact error
message do you get?

Thanks!
Dan

> Do you have any workarounds for this?
> 
> Thank you.
> 
> Neil Steiner
> from my Gmail address
> 816.916.3034
> 
> -- Forwarded message --
> From: 
> Date: Fri, Apr 17, 2015 at 11:42 AM
> Subject: Welcome to the "networkmanager-list" mailing list
> To: neilb4a...@gmail.com
> 
> 
> Welcome to the networkmanager-list@gnome.org mailing list!
> 
> To post to this list, send your message to:
> 
>   networkmanager-list@gnome.org
> 
> General information about the mailing list is at:
> 
>   https://mail.gnome.org/mailman/listinfo/networkmanager-list
> 
> If you ever want to unsubscribe or change your options (eg, switch to
> or from digest mode, change your password, etc.), visit your
> subscription page at:
> 
> 
> https://mail.gnome.org/mailman/options/networkmanager-list/neilb4ator%40gmail.com
> 
> 
> You can also make such adjustments via email by sending a message to:
> 
>   networkmanager-list-requ...@gnome.org
> 
> with the word `help' in the subject or body (don't include the
> quotes), and you will get back a message with instructions.
> 
> You must know your password to change your options (including changing
> the password, itself) or to unsubscribe without confirmation.  It is:
> 
>   Bone2Head
> 
> Normally, Mailman will remind you of your gnome.org mailing list
> passwords once every month, although you can disable this if you
> prefer.  This reminder will also include instructions on how to
> unsubscribe or change your account options.  There is also a button on
> your options page that will email your current password to you.
> ___
> 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] systemd: make NetworkManager reloadable via SIGHUP

[Dan Williams]

On Fri, 2015-04-17 at 15:06 +0200, Thomas Haller wrote:
> Since f9e4af2, parts of the configuration can be reloaded
> by sending SIGHUP to NetworkManager. Add ExecReload option
> to service file to support reloading by sending a signal.
> 
> Note that 'man 5 systemd.service' advices to use a blocking
> command instead of a sending a signal. Later we should add a
> D-Bus method to allow reloading synchronously. For now, this
> is better then nothing.

Works for me.

Dan

> ---
>  data/NetworkManager.service.in | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/data/NetworkManager.service.in b/data/NetworkManager.service.in
> index b2e61ff..980573d 100644
> --- a/data/NetworkManager.service.in
> +++ b/data/NetworkManager.service.in
> @@ -6,6 +6,7 @@ Before=network.target @DISTRO_NETWORK_SERVICE@
>  [Service]
>  Type=dbus
>  BusName=org.freedesktop.NetworkManager
> +ExecReload=/bin/kill -HUP $MAINPID
>  ExecStart=@sbindir@/NetworkManager --no-daemon
>  Restart=on-failure
>  # NM doesn't want systemd to kill its children for it


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager kernel and udev/eudev dependency, gcc build dependency

[Dan Williams]

On Fri, 2015-04-17 at 15:03 +0200, Petr Vorel wrote:
> Thanks a lot for the info.
> 
> > AFAIK, there is no known minimal kernel-version (or minimal required
> > feature-set).
> It would to have one.

Like Thomas said, NM has implicit kernel dependencies for specific
features (userspace IPv6LL, bond/bridge mac address at creation, some
WiFi features, IPv6 temp addresses, prefix route creation, etc) but it
should gracefully degrade for most of these, with a slight loss of
functionality.

I think the oldest kernel I've run NM on recently was a 3.6 or 3.7
kernel, which at this point is almost 3 years old.

> > NM will try to accommodate to missing features and should mostly should
> > work -- of course, certain features might then not be available (such as
> > [2]).
> That's quite good news :-).
> 
> > Try it and send a bug-report :)
> Sure :-). I'm going to test it on 2.6.37 with gcc 4.6.3.

While 2.6.37 may work, patches/bug reports will obviously handled on a
case-by-case basis depending on how invasive or complex they are.  If
it's pretty simple, then sure, we'll take it :)

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/1] contrib/rpm: add comment to NetworkManager.conf file

[Dan Williams]

On Thu, 2015-04-16 at 14:51 +0200, Thomas Haller wrote:
> ---
>  contrib/fedora/rpm/NetworkManager.conf | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/contrib/fedora/rpm/NetworkManager.conf 
> b/contrib/fedora/rpm/NetworkManager.conf
> index 88b7cec..d0d0d3f 100644
> --- a/contrib/fedora/rpm/NetworkManager.conf
> +++ b/contrib/fedora/rpm/NetworkManager.conf
> @@ -1,2 +1,12 @@
> +# Configuration file for NetworkManager.
> +# See "man 5 NetworkManager.conf" for details
> +#
> +# The directory /etc/NetworkManager/conf.d/ can contain
> +# configuration snippets that are installed by some
> +# packages. Those snippets overwrite the configuration

I would say "override" instead of "overwrite".

> +# from this main file.
> +# To overwrite a configuration from conf.d/ add yet another

Here too, and possibly drop the 'yet' since that implies "too many", as
in "yet another blade of grass in this field" :)

> +# configuration snippet with a name sorted last (99-my-config).

Config snippets have to end with ".conf", according to
_get_config_dir_files().

Dan

> +
>  [main]
>  plugins=ifcfg-rh,ibft


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Timeout for VPN connections

[Dan Williams]

On Tue, 2015-04-07 at 17:40 +0200, Franck Routier (perso) wrote:
> Le 07/04/2015 16:41, Dan Williams a écrit :
> > On Tue, 2015-04-07 at 12:14 +0200, Franck Routier (perso) wrote:
> >> Hi list,
> >>
> >> I have a problem with a (open)VPN connection that times out with Network
> >> Manager, but will work fine with command line openvpn.
> >> It will take a long time (2-3 minutes), but it will finally work.
> > Any idea why it takes so long?  I'm not against bumping the timeout, I'm
> > just curious.  It seems like 40 seconds with OpenVPN would either be
> > extreme latency on the link, high packet loss, or a very loaded server?
> I don't really know, as I don't have access to the server, but the main 
> reason is that the TLS connection times out :
> 
> UDPv4 link local: [undef]
> UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
> TLS Error: TLS key negotiation failed to occur within 60 seconds (check 
> your network connectivity)
> TLS Error: TLS handshake failed
> SIGUSR1[soft,tls-error] received, process restarting
> 
> until it eventually works...
> 
> This makes for a long connection time.

How about 150 seconds?  That seems pretty reasonable to me...

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: The Bridge on the River Dream House Of Net

[Dan Williams]

On Tue, 2015-04-07 at 18:47 +0200, poma wrote:
> On 07.04.2015 18:26, poma wrote:
> > 
> > $ nmcli networking
> > enabled
> > 
> > $ nmcli networking connectivity 
> > full
> > 
> > $ brctl show
> > bridge name bridge id   STP enabled interfaces
> > bridge0 8000.001234567830   no  enp3s0
> > 
> > $ nmcli device 
> > DEVICE  TYPE  STATE CONNECTION 
> > bridge0 bridgeconnected bridge0
> > enp3s0  ethernet  connected base0  
> > ...
> > 
> > 
> > $ nmcli networking off
> > 
> > $ nmcli networking 
> > disabled
> > 
> > $ nmcli networking connectivity 
> > none
> > 
> > $ brctl show
> > bridge name bridge id   STP enabled interfaces
> > bridge0 8000.   no  
> > 
> > $ nmcli device 
> > DEVICE  TYPE  STATE  CONNECTION 
> > bridge0 bridgeconnected  bridge0
> > enp3s0  ethernet  unmanaged  -- 
> > ...

Yes, you have found some inconsistencies with the Enabled property and
behavior.  I also see some open questions in the code about how to treat
software devices during enable/disable.  I've filed
https://bugzilla.gnome.org/show_bug.cgi?id=747477 to track it.

Thanks!
Dan

> > $ systemctl reboot
> > .
> > .
> > .
> > 
> > 
> > $ nmcli networking 
> > disabled
> > 
> > $ nmcli networking connectivity 
> > none
> > 
> > $ brctl show
> > bridge name bridge id   STP enabled interfaces
> > bridge0 8000.   no  
> > 
> > $ nmcli device 
> > DEVICE  TYPE  STATE  CONNECTION 
> > bridge0 bridgeunmanaged  -- 
> > enp3s0  ethernet  unmanaged  -- 
> > ...
> > 
> > $ nmcli networking on
> > 
> > $ nmcli networking
> > enabled
> > 
> > $ nmcli networking connectivity 
> > none
> > 
> > $ brctl show
> > bridge name bridge id   STP enabled interfaces
> > bridge0 8000.   no  
> > 
> > $ nmcli device 
> > DEVICE  TYPE  STATE CONNECTION 
> > enp3s0  ethernet  disconnected  -- 
> > bridge0 bridgeunmanaged -- 
> > ...
> > 
> > $ su
> > Password: 
> > 
> > # nmcli networking 
> > enabled
> > 
> > # nmcli networking connectivity 
> > none
> > 
> > # nmcli networking off
> > 
> > # nmcli networking 
> > disabled
> > 
> > # nmcli networking on
> > 
> > # nmcli networking 
> > enabled
> > 
> > # nmcli networking connectivity 
> > none
> > 
> > # lsmod | grep bridge
> > bridge107941  1 ebtable_broute
> > stp12868  1 bridge
> > llc13941  2 stp,bridge
> > 
> > # modprobe -rv ebtable_broute
> > rmmod ebtable_broute
> > rmmod bridge
> > rmmod stp
> > rmmod llc
> > 
> > # lsmod | grep bridge
> > 
> > # modprobe -v ebtable_broute
> > insmod /lib/modules/3.18.11-200.fc21.x86_64/kernel/net/llc/llc.ko.xz 
> > insmod /lib/modules/3.18.11-200.fc21.x86_64/kernel/net/802/stp.ko.xz 
> > insmod /lib/modules/3.18.11-200.fc21.x86_64/kernel/net/bridge/bridge.ko.xz 
> > insmod 
> > /lib/modules/3.18.11-200.fc21.x86_64/kernel/net/bridge/netfilter/ebtable_broute.ko.xz
> >  
> > 
> > # lsmod | grep bridge
> > bridge107941  1 ebtable_broute
> > stp12868  1 bridge
> > llc13941  2 stp,bridge
> > 
> > # exit
> > exit
> > 
> > $ nmcli networking
> > enabled
> > 
> > $ nmcli networking connectivity 
> > none
> > 
> > $ brctl show
> > bridge name bridge id   STP enabled interfaces
> > 
> > $ nmcli device 
> > DEVICE  TYPE  STATE CONNECTION 
> > enp3s0  ethernet  disconnected  -- 
> > ...
> > 
> > $ nmcli networking off
> > 
> > $ nmcli networking 
> > disabled
> > 
> > $ nmcli networking on
> > 
> > $ nmcli networking 
> > enabled
> > 
> > $ nmcli networking connectivity 
> > full
> > 
> > $ brctl show
> > bridge name bridge id   STP enabled interfaces
> > bridge0 8000.001234567830   no  enp3s0
> > 
> > $ nmcli device 
> > DEVICE  TYPE  STATE CONNECTION 
> > bridge0 bridgeconnected bridge0
> > enp3s0  ethernet  connected base0  
> > ...
> > 
> > 
> > $ NetworkManager --version
> > You must be root to run NetworkManager!
> > 
> > $ NetworkManager --help
> > You must be root to run NetworkManager!
> > 
> > $ su
> > Password: 
> > 
> > # NetworkManager --version
> > 1.0.0-8.fc21
> > 
> 
> Disabled 'networking', reboot and bridge connection will start working *only* 
> after kernel module reload.
> Bug or feature?
> 
> ___
> 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: How to get secret of a Setting throw D-Bus

[Dan Williams]

On Tue, 2015-04-07 at 11:00 +0800, 张天晔 wrote:

> ​How can I use GetSecrets?
> I don't know what setting_name is to parse to D-Bus when I want to get
> a secret!

The 'setting_name' for GetSecrets is name of the Setting object you're
requesting secrets for.  Each Setting object has a name, like
'802-3-ethernet' and '802-11-wireless'.  These are described in
https://developer.gnome.org/NetworkManager/0.9/ref-settings.html .  They
are also used as the keys in the Connection dict, and quite a few other
places in the API.

Dan 

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Timeout for VPN connections

[Dan Williams]

On Tue, 2015-04-07 at 12:14 +0200, Franck Routier (perso) wrote:
> Hi list,
> 
> I have a problem with a (open)VPN connection that times out with Network 
> Manager, but will work fine with command line openvpn.
> It will take a long time (2-3 minutes), but it will finally work.

Any idea why it takes so long?  I'm not against bumping the timeout, I'm
just curious.  It seems like 40 seconds with OpenVPN would either be
extreme latency on the link, high packet loss, or a very loaded server?

Dan

> It seems that a 40s timeout is hardcoded in NetworkManager 
> (vpn-manager/nm-vpn-connection.c)
> 
> static void
> connect_success (NMVPNConnection *connection)
> {
>  NMVPNConnectionPrivate *priv = NM_VPN_CONNECTION_GET_PRIVATE 
> (connection);
> 
>  /* 40 second timeout waiting for IP config signal from VPN service */
>  priv->connect_timeout = g_timeout_add_seconds (40, 
> connect_timeout_cb, connection);
> 
>  g_hash_table_destroy (priv->connect_hash);
>  priv->connect_hash = NULL;
> }
> 
> 
> See also this ticket on Ubuntu, with a patch and PPA : 
> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/420411
> 
> Would it make sense to change the default timeout, or even better make 
> it configurable ?
> 
> Regards,
> 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: Look for suggestions for booting from iscsi

[Dan Williams]

On Sat, 2015-04-04 at 12:21 +, allspace wrote:
> Hello,
> 
> Look into the mail list 6 years ago, some one had asked for suggestions for 
> booting from iscsi. At that time, the recommend was to turn off 
> NetworkManager.
> 
> Is there any improvement in NetworkManager on supporting such kind of network 
> booting (iscsi or nfs)?

Yes, there have been massive improvements in network booting in the past
6 years.  NetworkManager will seamlessly take over whatever
configuration exists on the interface at startup, and should not touch
anything.  If it does, that's a bug and we'll fix it.

So your procedure would simply be to just boot up normally, and NM will
detect the interface, read its configuration, and continue with no
interruption in network connectivity.

NM also has an 'ibft' system settings plugin that reads the iBFT config
from your firmware and presents those as immutable connections in
'nmcli' and the CLI/TUI/GUI tools, but that's just cosmetic and
shouldn't affect actual operation.  The interface configuration before
NM starts is authoritative.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Adding a LastSeen property to accesspoints and ScanDone signal

[Dan Williams]

On Thu, 2014-09-04 at 22:04 -0400, Mathieu Trudel-Lapierre wrote:
> Hi,
> 
> We've been trying to use NetworkManager to get a better idea of the
> reliability of wireless networks (their age, mostly) for use by
> applications.
> 
> I expanded LastSeen to be exposed both over DBus for this purpose, as
> well as in libnm-glib. I've also added a SCAN_DONE signal NMDeviceWifi,
> again to be exposed via DBus. I did run into minor issues with this though,
> and so patch 3/4 and 4/4 fix the supplicant sending extra ScanDone signals
> to NMDeviceWifi, and how the last-seen property gets updated at the end
> of a scan.

We revisited this on IRC:

Patch #2, #3, and #4 are fine.

Patch #1 needs some fixups, namely:

1) fix the D-Bus property documentation, and mention that the value is
absolute in CLOCK_BOOTTIME seconds, so CLOCK_BOOTTIME seconds -
last_seen = seconds ago the AP was last seen

2) make the property a u32 (it'll never be negative)

3) same thing for libnm-glib, a u32, and update the code documentation
to talk about CLOCK_BOOTTIME etc

4) for nm-wifi-ap.c, keep the current 'gint' stuff for
nm_ap_set_last_seen(), but in get_property() convert last_seen into
BOOTTIME units with nm_utils_monotonic_timestamp_as_boottime() from
Thomas' patch so that D-Bus clients see BOOTTIME, and add a code comment
about this in get_property()

Sound OK?

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list