transport: Support AGWPE over TCP (direwolf)
martinhpedersen opened this issue · comments
As pointed out by @kd8drx in #47, Direwolf appears to have a full AX.25 implementation exposed via the AGW-over-TCP format.
If we could implement a package to support AGW-over-TCP, that could be a nice way to support AX.25 on multiple platforms until #56 is resolved.
I would personally vote for the AGW route as this would allow you to leverage Direwolf's AX25 v2.2 stack and all of it's built-in intelligence vs. dumb things down via the KISS interface.
I have received some example C code from @wb2osz, and some documentation. If someone is willing to give this a go, then please let me know so I can forward the files.
I am considering to prioritize this feature soon... but I haven't found the time yet :/
I wouldn't mind seeing those files, but I know nothing of the code in this project to help at this time.
I would love to give this a go. If you could send me the example code and documentation, I'll take a crack at it.
I'm very glad to hear that! I've sent an inquiry to the original author today, requesting permission to share the code with you :)
Thank you!
@martinhpedersen I actually received some code and documentation from @wb2osz yesterday that I have started looking through.
AGWPE has a security feature that would be prudent to include for full AGWPE functionality. However, I believe Direwolf does not implement this.
From the documentation:
Login/Password validation.
The AGW Packet Engine user has now the ability to prohibit access of agwpe for other programs. The Security levels are 3.
- Allow any program to use agwpe.
- Allow only programs that run in his LAN.
- Allow only programs that run in his computer.
If the security level is set to 2 or 3. Then a program can gain access with a login validation procedure.
This is done using the new frame ‘P’ (capital letter P).
This is fairly simple to implement as it only requres sending the login frame to AGW. However, I don't see any straight forward way right now to pass AGW username and password information into the TNC open/init functions. It doesn't look like it can be done cleanly via the dialer url anyways.
What are our thoughts on this? Also, please let me know if this is the best place to post questions and seek feedback as I'm working on this.
Also, please let me know if this is the best place to post questions and seek feedback as I'm working on this.
Sure, we can continue the discussion here :) But feel free to email directly if you prefer.
However, I don't see any straight forward way right now to pass AGW username and password information into the TNC open/init functions. It doesn't look like it can be done cleanly via the dialer url anyways.
It sounds to me like this is something that we could add in a separate config section for agw, and pass to the TNC as part of the open/init function.
Dave Cheney's Functional options for friendly APIs comes to find as a nice way to open up for this but still maintain a good and uncluttered API.
Another approach could be to let Open() take an optional Config-struct Options-struct, similar to boltdb's API.
AGWPE has a security feature that would be prudent to include for full AGWPE functionality. However, I believe Direwolf does not implement this.
I suspect that most users will prefer Direwolf over AGWPE, simply because more than 95% of Pat users run Linux. So IMHO, I think we can defer this security feature. But that's for you to decide 👍
Thanks for taking the time to work on this!
For the record. https://github.com/la5nta/pat/wiki/Adding-transports was added today, as discussed in la5nta/pat#175.
Has there been any development on this feature addition? I would love to use pat without having to deal with kernel ax.25 or kiss. AGW is my preferred interface for APRS clients and is much, much easier to set up for users (I've been struggling with this the last several days).
This feature would be very beneficial. Setting up AX.25 for Linux is complicated and a new bug was discovered recently. https://groups.io/g/direwolf/message/5074
Adding voice in support of this. Thank you!
Sent my very first WinLink via RF packets tonight... Linux Ax.25 implementation made it terrible, with more obtuse configuration than expected and some kind of bug in reconnecting. I don't think the implementation feels ready for prime time.
I've started working on a transport package implementing this. Will probably take some time 🐌.
Sure, it would be great if you could share what you've found so far 👍
I'll try to push my branch within a couple of days so you can have a look at it. Maybe we can work on this together somehow 🙂
I have been using direwolf as my test modem, and it looks like the login procedure is not required at all. I've managed to register a callsign+port and also initiated the dialing operation by sending a 'c' frame to direwolf. Direwolf have some very handy logging capabilities, so that's going to be very helpful I think.
So far I have written code for encoding/decoding frames, and started implementing a TNC type to represent the AGWPE connection. I don't have a clear picture on how to manage the TNC state yet. From my own experience writing the ARDOP and WINOR packages, that's the hardest thing to get right when it comes to writing a transport driver. Especially for modems supporting concurrent connections. My plan is to do some experimenting with different designs to come up with a good approach for handling the TNC/port/connection states correctly, without too much complexity.
I've been using this as my protocol reference so far: https://www.on7lds.net/42/sites/default/files/AGWPEAPI.HTM.
Quick update: I've been making some progress on this over the summer. I believe I've found a good approach for managing the TNC state by demultiplexing the incoming frames to various goroutines. I have done some preliminary testing with two Pat instances (P2P) and a small "chat" app I wrote just to see how the TNC (Direwolf) behaves.
I still haven't tested with the original AGWPE application on Windows, but hopefully the two TNCs behave the same 🤞.
I've also started to fiddle with a solution for having multiple transports supporting the ax25:// scheme in Pat, with a config option to select the default driver.
To be continued...
@martinhpedersen Sounds great! Do you have code I could test and compare to what I have right now?
@KI7ODK - I've pushed the branch now :) Will push relevant changes to the Pat repo as soon as I have done my own review of the code.
Here is the chat app I've been using for testing purposes:
I've pushed a branch of Pat that uses this transport if anyone wants to check it out: https://github.com/la5nta/pat/tree/feature/agwpe-engine.