pat
pat copied to clipboard
la5nta
Packet Script Support
Our local area winlink connection uses a vhf node that connects to the uhf winlink gateway. Using RMS express you can handle this by using a connect script instead of the digipeater mode. The script would look like the following( anything after // is a comment and not used in the actual rms script.):
C K7LL-7 // Connects to Node
Connected // Looks for this keyword to be returned from the node. Not case sensitive.
C K7LL-10 // Tells the node to connect to the Winlink gateway
Connected
We are trying to move away from rms express over to pat for our local emergency communications team.
Hi - thanks for the proposal.
We got a similar feature request on pat-users a while back. Maybe you could discuss this further with Mike to ensure that both use-cases can be handled by this feature request?
The syntax from your example script seems to be somewhat ambiguous IMHO, with even/odd lines indicating send/expect. Is this a common syntax for node traversal? Maybe we could come up with something a tittle more flexible and robust(?).
From the top of my head:
- An embedded scripting language Lua?
- Exec a process and connect stdin/stdout to the AX.25 stream (Use the returned status code to signal success/failure)
- Go's new plugin support
- Define our own syntax. E.g. (oh, please stop me...)
send "C K7LL-7\r\n" // Connect to node wait "*[Cc]onnect.*" // Wait for line that matches this regular expression - Keep it simple (your proposal)
I think no 2. (exec) probably would be the most realistic solution with regards to implementation complexity and usage flexibility. With that approach, you could even plug in a custom parser to support what ever syntax you prefer.
What do you think?
I think you are on to a good idea. I am pretty sure the idea is similar to what the other user was trying to describe. Basically instead of connecting through a digipeater we connect to a node and then have to tell that node to connect to the gateway. I can't say for certain that it is overly common, however, this is how RMS Express handles it. I think that number 2 is a good approach, but I also like the idea of going with the new go plugins. Please let me know if you need me to further clarify or if you need any help with testing things out since. Thanks again for all the work and time you put into this project.
Austin
---- On Mon, 18 Dec 2017 14:20:14 -0800 Martin Hebnes Pedersen <[email protected]> wrote ----
Hi - thanks for the proposal.
We got a similar feature request on pat-users a while back. Maybe you could discuss this further with Mike to ensure that both use-cases can be handled by this feature request?
The syntax from your example script seems to be somewhat ambiguous IMHO, with even/odd lines indicating send/expect. Is this a common syntax for node traversal? Maybe we could come up with something a tittle more flexible and robust(?).
From the top of my head:
An embedded scripting language Lua?
Exec a process and connect stdin/stdout to the AX.25 stream (Use the returned status code to signal success/failure)
Go's new plugin support
Define our own syntax. E.g. (oh, please stop me...)
send "C K7LL-7\r\n" // Connect to node wait "[Cc]onnect." // Wait for line that matches this regular expression
Keep it simple (your proposal)
I think no 2. (exec) probably would be the most realistic solution with regards to implementation complexity and usage flexibility. With that approach, you could even plug in a custom parser to support what ever syntax you prefer.
What do you think?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Hi again Austin,
I've done some research and preliminary tests on my suggested solution. It will be harder to implement than initially thought due to buffering in the system.
We may need to implement a pre-handshake hook in wl2k-go/fbb that redirects the output from the remote node for this to work properly. It would need to scan the remote stream line-by-line, and based on the content of the line, redirect it to the hook-script or send it to the handshake-procedure. The downside is that we will need to make some assumptions regarding line-feed etc. It complicated the solution quite a bit.
It doesn't seem that nasty to do this the way Winlink Express does it; i.e., inserting a node "dialing" protocol at the beginning of each ax.25 connection. The dialing scripts don't need to be complicated so it wouldn't be a heavy addition. I kind of think that the administrative burdens involved in using a plugin or spawning an external function would be greater, in fact. Winlink Express has files for scripts, which would be ugly, IMHO. Probably nicer and more idiomatic to add dialing parameters to the connection URLs. E.g. something like: ax25:///VE7GNU?connect=VE7NOD?expect=CONNECTED&connect=VE7GNU-10&expect=CONNECTED&end If this must eventually be made more user-friendly then something can read the config file, present a nice GUI to edit these and whatever else, then write it back.
I'm interested in this issue because around here there are lots of nodes and no digipeaters, I guess because digipeaters are disfavoured.
My local repeater also has a Winlink gateway behind a connection script selector, and this would be a game changer for me
