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
speak up now.

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

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

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
events contain the desired info. But because its a bridge there is
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
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.


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

networkmanager-list mailing list
networkmanager-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]