Hi Aleksei and all, Thanks for your reply.
The problem is not the dispatcher scripts. I have one that is dumping the environment that comes from NetworkManager, so I can see what is passed from NM. The problem is that the dispatcher is not executed (from NM) at the point I would like to. Let me try to explain it. NM is configured to do connectivity checks: [connectivity] uri=http://network-test.debian.org/nm interval=60 I have three different interfaces all working properly (ethernet, wireless, cellular) #> route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.11.101 0.0.0.0 UG 100 0 0 eth0 0.0.0.0 192.168.11.101 0.0.0.0 UG 600 0 0 wlan0 0.0.0.0 77.210.151.17 0.0.0.0 UG 700 0 0 ppp0 ... At some point, if the ethernet interface loses the upstream connectivity (in other words, it's not able to reach the configured URI), then its metric is penalized so the overall system goes over a different working interface (in this case wireless). #> route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.11.101 0.0.0.0 UG 600 0 0 wlan0 0.0.0.0 77.210.151.17 0.0.0.0 UG 700 0 0 ppp0 0.0.0.0 192.168.11.101 0.0.0.0 UG 20100 0 0 eth0 ... At this point, the dispatcher is NOT fired, because the connectivity-check URI is still reachable via wireless. You need to lose the connectivity through ALL the interfaces so the dispatcher is executed. In that case, you see in the log: dispatcher: (5) dispatching action 'connectivity-change' nm-dispatcher: req:1 'connectivity-change': environment: CONNECTIVITY_STATE=LIMITED This is a fair design decision, but what I would like to is to fire the dispatcher when the connectivity check has failed for one interface even though the system has still connectivity via a different interface. So in the environment, you get something like: "INTERFACE=eth0 CONNECTIVITY_STATE=LIMITED" and then I can start some actions to recover that specific interface while the overall system still works properly using the other interfaces (wireless, cellular). I know this involves some patching of the code, and that's why I was asking some hints about how the original developers and maintainers of NM would address this change. Hope is more clear now. -- Thanks. Javier Viguera From: networkmanager-list [mailto:[email protected]] On Behalf Of Aleksei Sent: Tuesday, November 07, 2017 8:14 AM To: [email protected] Subject: Re: Launch dispatcher on upstream connectivity check failure per interface In the environment dispatcher scripts run in you have access to several variables to check interface name etc https://developer.gnome.org/NetworkManager/stable/NetworkManager.html. If you're still not able to solve your problem - post more details - how are you doing "connectivity check", what your configs and scripts look like. --Regards, Aleksei On 06/11/17 17:33, Viguera, Javier wrote: Hi all, I have a NM configuration using three interfaces: ethernet, wireless and cellular. I have enabled the "connectivity check" support and added some scripts in the dispatcher folder, so I can attend upstream network failure events. But as I'm seeing it, on connectivity check failures (no physical failures) the dispatcher is only fired when all the interfaces have lost the upstream connectivity (after the metrics for all interfaces have been penalized in the routing table). What I'm trying to do is to fire the dispatcher when the upstream connectivity check fails for one interface even though it's not failing for the other interfaces. For example, if the configure URI cannot be reached by ethernet fire a dispatch event even though that URL is still reachable via wireless and cellular. I'm looking at the code so I can hack the simplest patch to do the job, but just thought here would be the better place to ask for hints on where to start. Any help would be appreciated? -- Thanks. Javier Viguera _______________________________________________ networkmanager-list mailing list [email protected]<mailto:[email protected]> https://mail.gnome.org/mailman/listinfo/networkmanager-list
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
