Re: Approaching NetworkManager 1.2

[Dan Williams <dcbw redhat com>]

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