commit aa4b09da859e49447fa6dc6e2905de6eb3fb0b7e
parent 471c63b3998ab626abd80064b7961495fce9d6e3
Author: Daniel Barlow <dan@telent.net>
Date: Tue, 7 May 2024 17:50:13 +0100
think (foreshadowing)
Diffstat:
| M | THOUGHTS.txt | | | 170 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- |
1 file changed, 167 insertions(+), 3 deletions(-)
diff --git 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
