Startup sequence improvements

[bennlich]

cc @jhpoelen

The home node startup sequence is finicky. It seems like the two main components, tunneldigger and babeld, need to be started in a certain sequence, and with adequate delay between the two. Some notes:

1. On boot, the home node starts up a bunch of processes, including babeld and tunneldigger. At some point, dhcp messages trigger the /etc/udhcpc.user script to wait, pinging (or, after patch23, inspecting the public route table) in a loop until finding evidence that packets are routing through the l2tp interface successfully (see here). This usually does not work the first time (maybe it never works the first time). Instead, 20 of these checks fail, then /etc/init.d/meshrouting restart is called, restarting both tunneldigger and babeld. Routing tends to get setup successfully on this second attempt.

2. Restarting tunneldigger by itself breaks the routing table (all routes become unreachable). This makes some sense--I might not expect babeld to know that the tunnel interface is back up and ready. Maybe it eventually checks? In my recent tests, I didn't wait long enough. Restarting babeld quickly brings the route table back.

3. Restarting tunneldigger + babeld via /etc/init.d/meshrouting restart also tends to break the routing table. Again, restarting babeld is a quick fix. In this case, /etc/init.d/meshrouting restart should probably be improved to just work.

[gobengo]

systemd has built in support for managing dependencies like this I think. Can we use it here to help, instead of crafting dependency management into init.d scripts?

…

On Fri, Mar 23, 2018, 7:50 AM Benny Lichtner ***@***.***> wrote: cc @jhpoelen <https://github.com/jhpoelen> The home node startup sequence is finicky. It seems like the two main components, tunneldigger and babeld, need to be started in a certain sequence, and with adequate delay between the two. Some notes: 1. On boot, the home node starts up a bunch of processes, including babeld and tunneldigger. At some point, dhcp messages trigger the /etc/udhcpc.user script to wait, pinging (or, after patch23 <sudomesh/bugs#23>, inspecting the public route table) in a loop until finding evidence that packets are routing through the l2tp interface successfully (see here <https://github.com/sudomesh/makenode/blob/a3b243e69d2e4bddedbbb0a48f24315d4ea04e14/configs/ar71xx/home_nodes/templates/files/etc/udhcpc.user#L44-L62>). *This usually does not work the first time* (maybe it never works the first time). Instead, 20 of these checks fail, then /etc/init.d/meshrouting restart is called, restarting both tunneldigger and babeld. Routing tends to get setup successfully on this second attempt. 2. Restarting tunneldigger by itself breaks the routing table (all routes become unreachable). This makes some sense--I might not expect babeld to know that the tunnel interface is back up and ready. Maybe it eventually checks? In my recent tests, I didn't wait long enough. Restarting babeld quickly brings the route table back. 3. Restarting tunneldigger + babeld via /etc/init.d/meshrouting restart also tends to break the routing table. Again, restarting babeld is a quick fix. In this case, /etc/init.d/meshrouting restart should probably be improved to just work. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#128>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKfBoulfV9vyeOztqFxKvvbpPMJGVSsks5thJsjgaJpZM4S4P_z> .

[jhpoelen]

thanks for sharing/articulating your observations.

In attempts to get rid of funky restart logic in https://github.com/sudomesh/makenode/blob/a3b243e69d2e4bddedbbb0a48f24315d4ea04e14/configs/ar71xx/home_nodes/templates/files/etc/udhcpc.user#L44-L62 , I briefly looked at startup sequences, only to end up refactoring the restart logic in the udhcpc.user script a little. However, I did learn a little open openwrt's startup sequence (https://wiki.openwrt.org/doc/techref/process.boot) and that opkg packages define the startup sequence in a START=70 from https://github.com/sudomesh/sudowrt-packages/blob/master/net/babeld-sudowrt/files/babeld.init . Would be nice to have explicit dependencies instead (e.g., start x only after starting y).

Not quite sure whether openwrt supports systemd. There's an old stale thread on it here: https://forum.openwrt.org/viewtopic.php?id=49599 .

[paidforby]

currently zeroconf does not automatically start meshrouting. A somewhat relevant discovery: doing something like this is bad, 3f6f2ac, looks like meshrouting does not like being put into uci defaults, not sure why. How else can it be started on boot? Any ideas?