st 17. 12. 2025 v 19:26 odesílatel Philip Prindeville <[email protected]> napsal: > > > On Dec 12, 2025, at 6:48 AM, Oldřich Jedlička <[email protected]> wrote: > > > > čt 11. 12. 2025 v 4:45 odesílatel Philip Prindeville via openwrt-devel > > <[email protected]> napsal: > >> I previously tested with -z “$(ip -6 -o route show default)” but as > >> someone pointed out, if at the time that Bind starts up, someone later > >> brings up an IPv6 default route (say via DHCP or a tunnel), then this > >> caused a denial of service. > > > > If you have issues with network connectivity changes during startup, > > there is a way for the service to react. This is how I tried to solve > > similar startup issue (network not up or changed) for fwknopd: > > > > https://github.com/openwrt/packages/blob/master/net/fwknop/files/fwknopd.init#L16-L45 > > > > The procd options for service startup are described here, although I > > had to check the source code to really verify what is expected as input > > (network name or linux interface name): > > > > https://openwrt.org/docs/guide-developer/procd-init-scripts > > > > So when you correctly define your network dependencies, you should get > > restarted by procd automatically. > > > > Cheers, > > Oldrich. > > > I’ve noticed that if /etc/init.d/network restart is called, it makes the LAN > interfaces go away (especially the VLAN or bridge ones) which can make dhcpd > quit. > > What’s the “ubus” command to get the ifnames on the group “lan”? Or the > wrapper for that? Is it network_get_device()? > > I’m wondering if I need to do: > > procd_set_param netdev $dhcp_ifs > > in /etc/init.d/dhcpd … >
The fwknopd knows which network interface (in the sense of /etc/config/network interface name) it is listening to - this is configured. This one goes to procd_add_reload_interface_trigger (yeah, I feel the interface vs interface confusion). Then you need to find the existing physical interface (i.e. the Linux kernel one), which can be done by a call to network_get_device (function from the imported network.sh): https://github.com/openwrt/packages/blob/master/net/fwknop/files/fwknopd.init#L153 That physical interface (if found!) is the parameter to procd_set_param netdev. If the interface is not yet known, it means that it does not exist yet and the procd_add_reload_interface_trigger should handle that situation and reload the service. Reloading means that the start_service will be called again. One gotcha in the fwknopd script is that you actually let procd start and stop the application instances for you based on the procd_* definitions. This means that when you find the physical interface is missing, you do not define any procd_open_instance (the fwknopd needs an existing physical interface to start listening on). When you know the physical interface, that is the first time you call procd_open_instance. Procd is able to start/stop/restart application based on the definitions you provide, so just configure the instances (command line arguments, netdev...) you are sure about and procd will handle the rest for you. You can even define more instances too if necessary. I am using the following script for hostapd hotplug functionality with multiple daemons running: #!/bin/sh /etc/rc.common START=90 USE_PROCD=1 PROG=/usr/sbin/hostapd_cli start_service() { local ifnames ifnames=$(ubus call network.wireless status | jsonfilter -e "@[@.up=true].interfaces[*].ifname") for ifname in $ifnames; do procd_open_instance procd_set_param respawn procd_set_param command "$PROG" -a /usr/libexec/hotplug/hostapd -i $ifname procd_set_param netdev $ifname procd_close_instance done } service_triggers() { procd_add_reload_trigger "wireless" } Get the inspiration from the actual scripts in the packages repo, this one uses the same logic as fwknopd: https://github.com/openwrt/packages/blob/master/net/mini_snmpd/files/mini_snmpd.init Some scripts just use procd_add_reload_interface_trigger and not the procd_set_param netdev. I am not sure whether that is enough. Hope this helps :-) Cheers, Oldrich. _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
