think (foreshadowing)
This commit is contained in:
parent
471c63b399
commit
aa4b09da85
170
THOUGHTS.txt
170
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
|
||||
|
|
|
|||
Loading…
Reference in New Issue