-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
transport: Support AGWPE over TCP (direwolf) #57
Comments
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:
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. |
Sure, we can continue the discussion here :) But feel free to email directly if you prefer.
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
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). |
There has been some minor work done on it but I haven’t made any significant progress as of late. I’ll see if I can reprioritize this effort since you have expressed interest!
P.S. I have never had much luck using the kernel ax.25 implementation myself for some reason.
… On Feb 19, 2021, at 4:18 AM, italic ***@***.***> wrote:
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).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
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 🐌. |
I have picked my work on this back up within the past few weeks. I don’t have much done, but I can transfer what I’ve learned about the AGWPE protocol if you’d like. I feel like I have a good understanding of the protocol now, but I’ve been a little slow writing code since I’m still picking up golang.
… On Jun 7, 2022, at 1:28 PM, Martin Hebnes Pedersen ***@***.***> wrote:
I've started working on a transport package implementing this. Will probably take some time 🐌.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
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 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. |
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.
The text was updated successfully, but these errors were encountered: