Re: Approaching NetworkManager 1.2

[Olaf Hering <olaf aepfle de>]

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