think (foreshadowing)

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
+[X] 5) package it
-6) make uevent-watcher use it instead of netlink directly
+[X] 6) make uevent-watcher use it instead of netlink directly
-7) write an inout test variant that has the stick inserted
+[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