Re: Approaching NetworkManager 1.2

[Dan Williams]

On Sat, 2015-11-21 at 10:02 +0100, Olaf Hering wrote:
> On Fri, Nov 13, Dan Williams wrote:
> 
> > Again, if you can get dispatcher debugging that would be great. 
> >  Slaves
> > should never have IP information *unless it's been added externally
> > to
> > NM* by something, since they are slaves.
> 
> I think the VPN route error happend with gsm. This week the reconnect
> did not even trigger the scripts.
> 
> Not sure why the eth got an address. Perhaps GNOME was messing around
> with the onboard card?
> 
> I'm have this in place as a dispatcher script. Is this similar to
> what
> the nm-dispatcher command would log?

Yeah, it should be.  When you see the issue again, lets see what the
logs from the file are like.

Dan

> #!/usr/bin/env bash
> dnsmasq_dyn_dir="/dev/shm/dnsmasq.d"
> dnsmasq_dyn_env="${dnsmasq_dyn_dir}/nm_dispatcher.env.txt"
> _x() {
> rm -f "${dnsmasq_dyn_env}.$$"
> }
> trap _x EXIT
> #
> mkdir -vp "${dnsmasq_dyn_dir}"
> {
> date -u
> cat /proc/uptime
> echo "$0 $*"
> env | sort
> } > "${dnsmasq_dyn_env}.$$"
> cat "${dnsmasq_dyn_env}.$$" >> "${dnsmasq_dyn_env}"
> #
> 
> Olaf
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Approaching NetworkManager 1.2

[Olaf Hering]

On Fri, Nov 13, Dan Williams wrote:

> Again, if you can get dispatcher debugging that would be great.  Slaves
> should never have IP information *unless it's been added externally to
> NM* by something, since they are slaves.

I think the VPN route error happend with gsm. This week the reconnect
did not even trigger the scripts.

Not sure why the eth got an address. Perhaps GNOME was messing around
with the onboard card?

I'm have this in place as a dispatcher script. Is this similar to what
the nm-dispatcher command would log?

#!/usr/bin/env bash
dnsmasq_dyn_dir="/dev/shm/dnsmasq.d"
dnsmasq_dyn_env="${dnsmasq_dyn_dir}/nm_dispatcher.env.txt"
_x() {
rm -f "${dnsmasq_dyn_env}.$$"
}
trap _x EXIT
#
mkdir -vp "${dnsmasq_dyn_dir}"
{
date -u
cat /proc/uptime
echo "$0 $*"
env | sort
} > "${dnsmasq_dyn_env}.$$"
cat "${dnsmasq_dyn_env}.$$" >> "${dnsmasq_dyn_env}"
#

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

Re: Approaching NetworkManager 1.2

[Dan Williams]

On Fri, 2015-11-13 at 21:38 +0100, Olaf Hering wrote:
> On Mon, Nov 02, Lubomir Rintel wrote:
> 
> > If anyone believes anything important is missing it's a good time
> > to
> > speak up now.
> 
> The interface for scripts in /etc/NetworkManager/dispatcher.d/ is in
> a
> poor state. IMO there are likle two ways how third party apps
> interact
> with NM: either they receive "events" via the dispatcher hooks, or
> they
> are a dbus client. I dont know much about the latter, thats why I
> assume
> that an app is notified via dbus and get to the "full state" of NM
> via
> dbus. I assume such app does not need dispatcher events.
> 
> For apps/scripts called via the dispatcher interface the event should
> be
> a snapshot of the "full state". But instead they just get some "hey,
> something happend" event with an incomplete chunk of info.
> Essentially
> they are forced to make some sense of this incomplete chunk of info
> and
> maintain the state on their own. This is cumbersome and the amount of
> work
> to get this right is equal to turn them into full dbus apps and grab
> all
> the info from there. For short, the even must include the full info.
> 
> Examples:
> The remote VPN gateway sometimes drops the connection, or the router
> reconnects and gets a new public address. As a result openvpn
> reconnects. The reconnect event does not include the VPN route info,
> just the IPv4 address data. I'm sure NM still knows the routes, but I
> have not looked in dbus whats actually in there.

Can you grab some debug output from the dispatcher when this happens? 
 You can run the dispatcher like so:

nm-dispatcher --debug --persist

and it'll dump out exactly what it's sending to the scripts in the
environment.  Scripts should get a "vpn-down" without much info
(because the connection is already gone) and then a "vpn-up" with all
the addresses and routes in the environment.  If not, then its a bug.

> The bridge interface does dhcp, and the "up/dhcp4-change/dhcp6
> -change"
> events contain the desired info. But because its a bridge there is
> also
> the ethN slave. Most of the time its event carries no info. But it
> happend two times during boot that ethN instead of br0 carried the
> address info. Since my scripts have to ignore ethN the required info
> was
> essentially lost and the system in a wedged state.

Again, if you can get dispatcher debugging that would be great.  Slaves
should never have IP information *unless it's been added externally to
NM* by something, since they are slaves.

Dan

> Please either fix this, or document it clearly in NetworkManager(8)
> that
> the environment info for each event may be incomplete.
> 
> 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: Approaching NetworkManager 1.2

[Olaf Hering]

On Tue, Nov 03, poma wrote:

> Please bring the bridges back to network-manager-applet!

Thanks for finding this...

The current way of how things are broken is that even if a bridge is
active the GNOME GUI still wants to manage a "cabled connection". But
instead of actually doing that it tries to fiddle with the slave of the
bridge instead of the bridge itself. As a result one gets two
connections: one is the bridge with its slave, and another one for eth0.

Please break things properly...


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

Re: Approaching NetworkManager 1.2

[Olaf Hering]

On Mon, Nov 02, Lubomir Rintel wrote:

> If anyone believes anything important is missing it's a good time to
> speak up now.

The interface for scripts in /etc/NetworkManager/dispatcher.d/ is in a
poor state. IMO there are likle two ways how third party apps interact
with NM: either they receive "events" via the dispatcher hooks, or they
are a dbus client. I dont know much about the latter, thats why I assume
that an app is notified via dbus and get to the "full state" of NM via
dbus. I assume such app does not need dispatcher events.

For apps/scripts called via the dispatcher interface the event should be
a snapshot of the "full state". But instead they just get some "hey,
something happend" event with an incomplete chunk of info. Essentially
they are forced to make some sense of this incomplete chunk of info and
maintain the state on their own. This is cumbersome and the amount of work
to get this right is equal to turn them into full dbus apps and grab all
the info from there. For short, the even must include the full info.

Examples:
The remote VPN gateway sometimes drops the connection, or the router
reconnects and gets a new public address. As a result openvpn
reconnects. The reconnect event does not include the VPN route info,
just the IPv4 address data. I'm sure NM still knows the routes, but I
have not looked in dbus whats actually in there.

The bridge interface does dhcp, and the "up/dhcp4-change/dhcp6-change"
events contain the desired info. But because its a bridge there is also
the ethN slave. Most of the time its event carries no info. But it
happend two times during boot that ethN instead of br0 carried the
address info. Since my scripts have to ignore ethN the required info was
essentially lost and the system in a wedged state.


Please either fix this, or document it clearly in NetworkManager(8) that
the environment info for each event may be incomplete.

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

Re: Approaching NetworkManager 1.2

[David Woodhouse]

On Mon, 2015-11-02 at 18:02 +0100, Lubomir Rintel wrote:
> Hello everyone,
> 
> It's been some time since the work on NetworkManager 1.2 has begun. A
> lot of what's been planed has been implemented and we believe we
> should
> wrap up the work and do a major release.
> 
> The wiki page with 1.2 feature page has been updated with the
> features
> we're like to see in the release (most of it already implemented):
> https://wiki.gnome.org/Projects/NetworkManager/12FeaturesPlanning
> 
> If anyone believes anything important is missing it's a good time to
> speak up now.

It would be *really* useful to solve the proxy problems. I've finally
written this up coherently (I hope) at 
https://wiki.gnome.org/Projects/NetworkManager/Proxies

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Approaching NetworkManager 1.2

[Tore Anderson]

* Dan Williams

> I wouldn't get rid of "Automatic (Addresses only)" since this is what
> enables you to ignore DNS servers/routes and use your own.

Actually, contrary to to what you'd intuitively expect, that method
does *not* ignore receive routes. Only DNS servers are ignored. The
only difference compared to the «Automatic» is ignore-auto-dns=true
gets set.

This is a very good example of what was getting at. Instead of having a
separate "method" just to ignore received DNS server, this should have
been a simple checkbox to override the default behaviour, in the same
way privacy extensions already are.

With the current arrangement, if you want to allow the user to ignore
routes but not DNS servers, you'd need a third «Automatic (..)»
flavour. If you want to allow to ignore both routes *and* DNS servers,
you'll need a fourth. One "method" for each possible permutation of the
settings simply won't scale.

> Yeah, we've talked about that for a couple years but nobody's gotten
> around to it.  Note that you can currently use SLAAC in addition to
> manual addresses already, though what you probably want is SLAAC to
> deliver the prefix/DNS/etc and use a static IP with that prefix?

That would be one possible use case. Note that I'm not really talking
about a specific need of my own here, but rather to make it more
flexible in general than it currently is.

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

Re: Approaching NetworkManager 1.2

[Dan Williams]

On Wed, 2015-11-04 at 07:53 +0100, Tore Anderson wrote:
> * Lubomir Rintel 
> 
> > If anyone believes anything important is missing it's a good time to
> > speak up now.
> 
> A couple of suggestions:
> 
> 1) IPv6 method cleanup:
>* Get rid of «Automatic (DHCP only)»
>* Get rid of «Automatic (Addresses only)»

I wouldn't get rid of "Automatic (Addresses only)" since this is what
enables you to ignore DNS servers/routes and use your own.

>* Replace «Ignore» with «Disabled», which should set the
>  disable_ipv6 sysctl).
> 
> (In general I think the «method» concept is somewhat misguided to begin
> with, even for IPv4. I'd rather see it be replaced by a set of mostly
> independent toggles to enable/disable various features, to allow for
> arbitrary combinations. For example: It is currently impossible to use
> SLAAC in combination with a manual static address. I can't see any good
> reason for that.)

Yeah, we've talked about that for a couple years but nobody's gotten
around to it.  Note that you can currently use SLAAC in addition to
manual addresses already, though what you probably want is SLAAC to
deliver the prefix/DNS/etc and use a static IP with that prefix?

Dan

> 2) Support for IPv6 sharing. Relevant technologies here:
>* DHCPv6 Prefix Delegation (RFC 3633)
>* ND Proxy (RFC 4389)
>* 3GPP /64 share (RFC 7278) [Note: ND Proxy covers this use case]
> 
> Maybe I'll think of more later.
> 
> Tore
> ___
> 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: Approaching NetworkManager 1.2

[Tore Anderson]

* Lubomir Rintel 

> If anyone believes anything important is missing it's a good time to
> speak up now.

A couple of suggestions:

1) IPv6 method cleanup:
   * Get rid of «Automatic (DHCP only)»
   * Get rid of «Automatic (Addresses only)»
   * Replace «Ignore» with «Disabled», which should set the
 disable_ipv6 sysctl).

(In general I think the «method» concept is somewhat misguided to begin
with, even for IPv4. I'd rather see it be replaced by a set of mostly
independent toggles to enable/disable various features, to allow for
arbitrary combinations. For example: It is currently impossible to use
SLAAC in combination with a manual static address. I can't see any good
reason for that.)

2) Support for IPv6 sharing. Relevant technologies here:
   * DHCPv6 Prefix Delegation (RFC 3633)
   * ND Proxy (RFC 4389)
   * 3GPP /64 share (RFC 7278) [Note: ND Proxy covers this use case]

Maybe I'll think of more later.

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