Add connection prehook for scripted node traversal

[martinhpedersen]

Adds low-level connection prehook for all transports, implemented by spawning a user-defined process communicating with the remote station over stdio.

This enables scripted node traversal (#114) at the lowest possible level. To make it more practical and user-friendly, we need to add a layer on top. Not everyone is comfortable writing bash scripts/programs able to do this, so we need a simplified language with just enough flexibility to express the command/response sequences commonly used in packet node traversal.

---

TODO

• Write documentation
  • New connect URI query parameters (wiki + pat connect help)
  • Describe the protocol between Pat and the spawned process (wiki)

[martinhpedersen]

Example based on the initial feature request.

Script: my-prehook.sh

#!/bin/sh
set -e
function wait {
	local timeout=$1 keyword=$2 line=""
	while [[ $line != $keyword ]]; do read -t $timeout -r line; done
}
function print {
	shift
	echo "${@}\r"
}

#########################################
# The node traversal script starts here #
#########################################
print C K7LL-7
wait 10 Connected
print C K7LL-10
wait 10 Connected

Usage:

pat connect 'ax25:///K7LL-5?prehook=my-prehook.sh'

[martinhpedersen]

... We should probably define a location for these scripts and append that to the spawned process' PATH.

[xylo04]

This works, but in an earlier comment you described trying to append the prehooks dir to the process' PATH. If that worked the way I assumed, our prehooks dir would just be the first place LookPath would explore, and you wouldn't have to do two checks. I'm guessing that didn't work out?

[martinhpedersen]

Yes, that would be much easier. I thought the issue was that Go's standard library didn't provide a portable way of modifying $PATH. The syntax differs between Windows and linux/darwin.

.. However, while writing this comment I discovered os.PathListSeparator 😄 I'll give it another try! Thanks 🙂

[xylo04]

I suppose I could just try this, but I can also ask you about your intent: url.Params["prehook-arg"] gives back an array of args. If I have multiple args I need to pass to the script, do I make multiple URL params with the same key?

E.g. if I want to invoke the prehook script with:

my-prehook.sh --bool-arg --arg2=value

then I encode that in the URL as

ax25:///K7LL-5?prehook=my-prehook.sh&prehook-arg=--bool-arg&prehook-arg=--arg2=value

[martinhpedersen]

Yes, that's correct 🙂 As an alternative we could consider a single argument with a separator. However, then we would also need to implement escaping in case the separator should be passed to the script.

[xylo04]

High-level question: since we are making a connection pre-hook for initializing connections, does that now require that there's a post-hook for tearing the connection down cleanly? Maybe the proposed use case, AX.25 packet, is smart enough to tear down traversal links.

[martinhpedersen]

That's a very good question! 🤔

I would imagine that all connections would be teared down once one of the links are disconnected. Otherwise, you'd run the risk of dangling connections in case the dialer looses it's connection. But this is definitely something to investigate.

[martinhpedersen]

We could check to see if Winlink Express provides such a feature. If they don't, I would imagine it's not very common 😁

[xylo04]

How does the pre-hook script communicate its progress? Is exit code 0 the main/only way? I could see eventually expanding it to where the connection script can signal that the connection is ready, then Pat can signal when B2F is done and let the script tear down the connection. But I don't think that's necessary for v1.

[martinhpedersen]

Yes, exit code 0 == success. Any other exit code is assumed to be a failure, and the connection is closed with an error presented to the user.

I see your point. We could maybe use a signal like SIGCONT for this, to keep stdio as transparent as possible. We would also need another mechanism to communicate that the connection is ready for B2F, as this is currently implemented by the child process exiting. But yes, maybe not necessary for v1.