Re: Approaching NetworkManager 1.2
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
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
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
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
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
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
* 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
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
* 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
Re: Approaching NetworkManager 1.2
On 02.11.2015 18:02, 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. > Thanks for the offer, - applet: drop bond, bridge, infiniband, team, and vlan support https://git.gnome.org/browse/network-manager-applet/commit/?id=4b8eade At one point we thought people would want/need to control their "enterprisey" devices via nm-applet, but nmcli (or static autoconnect=true configuration) turns out to be a better answer generally. Additionally, probably the most common case of bridges currently is when you are using virtualization or containers, and in that case the bridge is handled entirely by the virt/container system, and showing it in nm-applet just clutters things up, pushing Wi-Fi and VPN down to the bottom of the menu. So drop support for those devices. https://bugzilla.gnome.org/show_bug.cgi?id=753369 Bridges are "enterprisey" devices, really? - drop support for enterprisey device types https://bugzilla.gnome.org/show_bug.cgi?id=753369#c0 nm-applet tends to get cluttered up with virbr devices these days, and I think gnome-shell's approach (only showing ethernet, wifi, bluetooth, and mobile) is probably the right thing for GUIs. I really doubt anyone is using nm-applet to manage their team devices... Something is "cluttered" to -you- or to the -GNOME- "design"? :) Let's leave the GNOME to use what it uses, but do not take from the network-manager-applet. Please bring the bridges back to network-manager-applet! > Since the new release will bring significant changes, we'll be doing a > beta release (likely towards the end of this year) once the new APIs > are settled. > > When the remaining work that won't involve interface changes is done > we'll do a release candidate and repeat that until the wrinkles are > ironed out and the feedback is sufficiently good. > > Thanks, > Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Approaching NetworkManager 1.2
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. Since the new release will bring significant changes, we'll be doing a beta release (likely towards the end of this year) once the new APIs are settled. When the remaining work that won't involve interface changes is done we'll do a release candidate and repeat that until the wrinkles are ironed out and the feedback is sufficiently good. Thanks, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
