From c40f258323a51e7257df618cb07ddb687c86dc0e Mon Sep 17 00:00:00 2001 From: Daniel Barlow Date: Tue, 7 May 2024 17:50:13 +0100 Subject: [PATCH] think (foreshadowing) --- THOUGHTS.txt | 170 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 167 insertions(+), 3 deletions(-) diff --git a/THOUGHTS.txt b/THOUGHTS.txt index c185e23..e86dcc2 100644 --- a/THOUGHTS.txt +++ b/THOUGHTS.txt @@ -4726,9 +4726,9 @@ outside of it [X] 2) if so, convert it to lualinux [X] 3) add netlink socket to event loop [X] 4) make it send messages to subscribers -5) package it -6) make uevent-watcher use it instead of netlink directly -7) write an inout test variant that has the stick inserted +[X] 5) package it +[X] 6) make uevent-watcher use it instead of netlink directly +[X] 7) write an inout test variant that has the stick inserted at boot time already I'm also thinking we could wrap the raw fds from lualinux into small @@ -4741,3 +4741,167 @@ state before subscribing them [ needs a test ] figure out what event format the subscribers want? lua-ish or send the same messages as udev would? If we're going to send the originals, should we store them alongside the parsed, or reconstruct from parsed? + +Sat Apr 27 21:52:11 BST 2024 + +We have a passing inout test. Next thing to do is try it on +the actual arhcive hardware + +Next big thing is some kind of failovery service. Almost-obvious +candidate is LTE failover with aaisp l2tp tunnel + +Tue Apr 30 23:27:30 BST 2024 + +I want to connect my new ip camera to arthur without letting it reach the +internet, or the internet reach it. + +we could plug it into a gl.inet box running dhcp server on lan +and client on wan, then use NAT to expose the camera's http and rtsp +ports on whatever address it has on the wan interface + +Tue May 7 22:23:49 BST 2024 + +If we want to build a config with an l2tp upstream, it needs an +underlying dhcp interface not pppoe as we can't use the bordervm l2tp +account simultaneously. Having bordervm do dhcp might be quite useful +anyway for other applications, although it will have to double-nat to +the internet. We could give it an aaisp /64 and have routable ipv6 but +maybe that's a level of faff too high. + +Given that we can build xl2tpd and a service for it. + + +'re using the same l2tp account for thingy that we use to simulate ppp, +we need an upstream which is not ppp + +We need a less shit coldplug that copes with filenames containing spaces (!) + +Fri May 10 00:33:14 BST 2024 + +Getting xl2tp hackily running turned out to be not a lot of work. However, +we need to figure out routing + +- we need a route on lan device to the dns to lookup l2tp.aaisp.net.uk +- we need a route on lan device to l2tp.aaisp.net.uk + +also it doesn't die when the tunnel closes, which is a bit shit + +maybe this is where we lean into health check services + +a health check service is just a service that watches another service +and kills it if it's not healthy. + +for xl2tpd, "not healthy" is "there is no ppp process" or "there is no +tunnel" or "the tunnel has no sessions". I don't know how we +(robustly) test for no ppp process associated with the l2tp peer + +when ppp quits, does the tunnel come down? +in xl2tld.c child_handler we respond to sigchld by closing c->fd +and setting it to -1 + +Sat May 11 17:55:04 BST 2024 + +A better way to monitor the connection health would be to ping a +computer on the internet (preferably one that doesn't mind being +pinged). If we combine autodial with "is $isp still there" then we +should have something fairly robust. + +xl2tpd spawns pppd, we should equip it with config that writes the +ppp outputs (ip address etc) to the xl2tp service directory so +that it can be used like a regular ppp. This will also make +it possible to have the health check work by pinging the peer address + +Sun May 12 22:33:09 BST 2024 + +sleep until the interface is probably up +failure counter = 0 +loop indefinitely + get outputs/peer-address of watched ppp service + ping it + if ok + reset failure counter + else + increment failure counter + fi + if failure counter > threshold + bounce the ppp service + exit, if previous action didn't do that already + end + sleep(check interval) +end loop + + +# ps ax | grep l2tp + 72 root 1316 S s6-supervise l2tp.aaisp.net.uk.l2tp + 73 root 1316 S s6-supervise l2tp.aaisp.net.uk.l2tp-log + 122 root 1428 S {run.user} /bin/sh ./run.user l2tp.aaisp.net.uk.l2tp + 1099 root 1428 S {run.user} /bin/sh ./run.user l2tp.aaisp.net.uk.l2tp + 1102 root 1104 S {xl2tpd} /nix/store/i1bbqh7vybam03l6jzf4sm4np3k4ack5 + 1115 root 1420 S grep l2tp +# s6-rc -d change l2tp.aaisp.net.uk.l2tp +# ps ax | grep l2tp + 72 root 1316 S s6-supervise l2tp.aaisp.net.uk.l2tp + 73 root 1316 S s6-supervise l2tp.aaisp.net.uk.l2tp-log + 122 root 1428 S {run.user} /bin/sh ./run.user l2tp.aaisp.net.uk.l2tp + 1102 root 1104 S {xl2tpd} /nix/store/i1bbqh7vybam03l6jzf4sm4np3k4ack5 + 1122 root 1420 S grep l2tp + + +Mon May 13 19:45:59 BST 2024 + +We need to do the usb id swithcing dance thing for the lte modem. +At startup it's 12d1:14fe, which is "mass storage mode", although the +disks seem to disappear as soon as they appear which is weird + +probably the mode switch should be triggered by device insertion + +usb_modeswitch -v 12d1 -p 14fe --huawei-new-mode + +https://github.com/pixelspark/tymodem?tab=readme-ov-file + + +Tue May 14 21:58:25 BST 2024 + +[ we didn't need this. the first form is the default, the second +is what something on the internet said we should change it to, the +third is setting it back to default ] + +^SETPORT:A1,A2;12,1,16,A1,A2 +AT^SETPORT="FF;12,16" +AT^SETPORT="A1,A2;12,1,16,A1,A2" + + + +Wed May 15 21:55:11 BST 2024 + +we can use uevent-watch to look for devtype=usb_device product=12d1/14fe/102 +and trigger a oneshot that runs usb-modeswitch + +we can use uevent-watch to look for devtype=usb_device product=12d1/1506/102 +and trigger a oneshot that runs the AT commands + +if wwan0 is a triggered service how can dhcp depend on it? arse + +- we can get reverse dependencies from s6-rc-db, so the sematics of +starting a triggered service could include starting everything it +enables + +- we don't want to inadvertently start it on boot by putting it in the +global config.services + +Thu May 16 09:09:44 BST 2024 + +we could do something cleverish with the config.services at build time +by stripping from it everything depending on a trigger. but then how +_do_ they get started? the intent of putting it in config.services +is that it will be started when conditions are suitable. + +can we: go through each service in config.services, detect the trigger +that started it, and add it to a bundle named for that trigger? + +we need something in the triggering service to mark the triggered +service as not-for-boot, and then to apply that transitively to +everyting depending on it + +I don't think we have common code for triggers, so either we need to +add some or put this marking in all of the current examples