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
