| Message ID | 20200319120320.28651-1-fe@dev.tdt.de |
|---|---|
| State | New |
| Delegated to: | Felix Fietkau |
| Headers | show |
| Series | [OpenWrt-Devel,1/1] netifd: add pre-up/down post-up/down callback handling | expand |
On 2020-03-19 13:03, Florian Eckert wrote: > In some situations it is useful to execute callback scripts when > manually triggering an ifdown/ifup event via the CLI/LuCI. > > In my case I have a monitoring for a cellular connection. > If this fails the command `ubus call network.interface up` is execute to > restart the connection if a config option in uci of the interface > (keep_connected) flag is set. > > But for me to disconnect correctly I need to know about a user > interaction with performed with CLI/LuCI. > > With this change we can decide if this is a user interaction with CLI/LuCI, > because with the new callback mechanism I can set/delete a uci config flag so > that the connection should really disconnected. And so does not restart on a > failed connetion tracking again because the uci config flag is not set. > > Signed-off-by: Florian Eckert <fe@dev.tdt.de> netifd already tracks for every interface if the user requested it to be enabled or not via the 'autostart' flag, which you can query via ubus. Is it enough for your use case to track that flag? If not, please go into more detail, because I don't think hacking hotplug-call invocations into the ifup script is a good solution. - Felix
network >> With this change we can decide if this is a user interaction with >> CLI/LuCI, >> because with the new callback mechanism I can set/delete a uci config >> flag so >> that the connection should really disconnected. And so does not >> restart on a >> failed connetion tracking again because the uci config flag is not >> set. >> >> Signed-off-by: Florian Eckert <fe@dev.tdt.de> > netifd already tracks for every interface if the user requested it to > be > enabled or not via the 'autostart' flag, which you can query via ubus. I know this is done wit the uci option auto for this interface. But if I disable this flag, then on the next boot this interface does not start on boot anymore. I have to start this manual. So I think this is not an option. > Is it enough for your use case to track that flag? As far as I can tell at this point, it's not an option to use this flag. > If not, please go into more detail, because I don't think hacking In the LuCI and in the CLI the command ifup/ifdown is used, if the user wants to start/stop this interface explicitly manual. The auto option is not touched. The ifup/ifdown script executes an ubus call to set the interface up/down [1]. After the execution is preformed by netifd (proto) then the hotplug scripts are execute with different ACTION (up/down/ifup-failed. If I want to know if the Command is execute by an user interaction by the CLI (ifup/ifdown) or LuCI [2][3] the only possibility I have is to hook into the ifup/ifdown command. I would also like to point out that debian also has this possibility [4] in the network configuration. - Florian [1] https://github.com/openwrt/openwrt/blob/master/package/network/config/netifd/files/sbin/ifup#L9 [2] https://github.com/openwrt/luci/blob/6c167ea880bd29c69730d802c48ebc2c0253b905/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js#L991 [3] https://github.com/openwrt/luci/blob/6c167ea880bd29c69730d802c48ebc2c0253b905/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js#L997 [4] https://wiki.debian.org/NetworkConfiguration
On 2020-03-20 15:21, Florian Eckert wrote: > network >>> With this change we can decide if this is a user interaction with >>> CLI/LuCI, >>> because with the new callback mechanism I can set/delete a uci config >>> flag so >>> that the connection should really disconnected. And so does not >>> restart on a >>> failed connetion tracking again because the uci config flag is not >>> set. >>> >>> Signed-off-by: Florian Eckert <fe@dev.tdt.de> >> netifd already tracks for every interface if the user requested it to >> be >> enabled or not via the 'autostart' flag, which you can query via ubus. > > I know this is done wit the uci option auto for this interface. > But if I disable this flag, then on the next boot this interface does > not start > on boot anymore. I have to start this manual. So I think this is not an > option. No, I'm talking about the internal per-interface 'autostart' variable, which gets set to false if the user does a manual ifdown of an interface (but not if it just failed to start up). It's not backed by configuration and you can query it via ubus. (e.g. ifstatus wan) - Felix
What is the reason that creating a script in /etc/hotplug.d/iface/ that checks $ACTION and $DEVICENAME doesn't solve for this use case? https://openwrt.org/docs/guide-user/base-system/hotplug On Fri, Mar 20, 2020, 11:02 AM Felix Fietkau <nbd@nbd.name> wrote: > On 2020-03-20 15:21, Florian Eckert wrote: > > network > >>> With this change we can decide if this is a user interaction with > >>> CLI/LuCI, > >>> because with the new callback mechanism I can set/delete a uci config > >>> flag so > >>> that the connection should really disconnected. And so does not > >>> restart on a > >>> failed connetion tracking again because the uci config flag is not > >>> set. > >>> > >>> Signed-off-by: Florian Eckert <fe@dev.tdt.de> > >> netifd already tracks for every interface if the user requested it to > >> be > >> enabled or not via the 'autostart' flag, which you can query via ubus. > > > > I know this is done wit the uci option auto for this interface. > > But if I disable this flag, then on the next boot this interface does > > not start > > on boot anymore. I have to start this manual. So I think this is not an > > option. > No, I'm talking about the internal per-interface 'autostart' variable, > which gets set to false if the user does a manual ifdown of an interface > (but not if it just failed to start up). > It's not backed by configuration and you can query it via ubus. > (e.g. ifstatus wan) > > - Felix > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel >
>> I know this is done wit the uci option auto for this interface. >> But if I disable this flag, then on the next boot this interface does >> not start >> on boot anymore. I have to start this manual. So I think this is not >> an >> option. > No, I'm talking about the internal per-interface 'autostart' variable, > which gets set to false if the user does a manual ifdown of an > interface > (but not if it just failed to start up). That doesn't help me. If I do an manual ifup (CLI) or an ubus call the value does change. I could not difference if this is a manual command by CLI or a direct ubus call. In my case a connection has been established by the protocol handler successfully by netif. But in the course of the established connection there is an error. To track this I am using the mwan3. The error can have different reasons. The problem I have especially with wireless cellular interfaces. * Layer 3 problem by the provider or in his backend * Bug in the Modem firmware Netifd can't detect this, because the operstate does not change on radio devices the firmware of the modem does not support this. Or it is an other problem that does not have to do with the modem. The only thing that helps me is to reestablish the connection with an ifup (CLI) or an ubus call. The Problem is now i can not stop the connection because it is for now not possible to distinguish if the stop is a user interaction or a script interaction. So If I only use ubus call on my script and user interaction uses ifup/ifdown CLI command and if I set a flag by ifup/ifdown I could solve my issue. So that if a user uses ifup/ifdown set the flag and so could proper stop the connection. The restart code could does test the flag an so does not restart on user interaction by the ifup/ifdown CLI command. I can also imagine that we extend the netifd so that we add a flag to the ubus call if it is a user interaction via the script ifup/ifdown. This way I can distinguish if the connection is coming from a script or the command ifup/ifdown. This is a very precise solution. The other one is more a general solution with which other things are possible. @felix thanks for reply :-) - Florian
diff --git a/package/network/config/netifd/files/sbin/ifup b/package/network/config/netifd/files/sbin/ifup index 5515b91f76..c92dd46550 100755 --- a/package/network/config/netifd/files/sbin/ifup +++ b/package/network/config/netifd/files/sbin/ifup @@ -6,7 +6,9 @@ setup_wifi= if_call() { local interface="$1" for mode in $modes; do + env -i ACTION="pre-${mode}" INTERFACE="$interface" /sbin/hotplug-call netifd ubus call network.interface $mode "{ \"interface\" : \"$interface\" }" + env -i ACTION="post-${mode}" INTERFACE="$interface" /sbin/hotplug-call netifd done }
In some situations it is useful to execute callback scripts when manually triggering an ifdown/ifup event via the CLI/LuCI. In my case I have a monitoring for a cellular connection. If this fails the command `ubus call network.interface up` is execute to restart the connection if a config option in uci of the interface (keep_connected) flag is set. But for me to disconnect correctly I need to know about a user interaction with performed with CLI/LuCI. With this change we can decide if this is a user interaction with CLI/LuCI, because with the new callback mechanism I can set/delete a uci config flag so that the connection should really disconnected. And so does not restart on a failed connetion tracking again because the uci config flag is not set. Signed-off-by: Florian Eckert <fe@dev.tdt.de> --- package/network/config/netifd/files/sbin/ifup | 2 ++ 1 file changed, 2 insertions(+)