Add support for AGWPE over TCP

[martinhpedersen]

The AGWPE over TCP protocol is supported natively by Direwolf and AGWPE, allowing the host application to use the soft TNCs built-in AX.25 implementation.

With this, Pat users will be able to do AX.25 talking directly to the open-source software TNC Direwolf, without the hassle of kissattach and axports config. As oppose to today's Linux-only solution, this will be a platform independent feature since Direwolf runs on most operating systems.

See la5nta/wl2k-go#57 for initial discussion on this topic. The transport package is already written.

I'm currently working on integrating it into Pat in a way that (hopefully) will be backwards compatible with existing setups, easily configurable and mostly transparent to the everyday operation in Pat. By introducing the concept of an AX.25 engine, I hope it will be easy for users to select between multiple AX.25 packet implementations under the same ax25:// scheme.

[martinhpedersen]

Current WIP branch: https://github.com/la5nta/pat/tree/feature/agwpe-engine

[alaskalinuxuser]

Please let me know how/if I can help test this. I use Ubuntu 22 and use PAT with HF and ARDOP regularly. Not too familiar with DIREWOLF, trying to make AX.25 and Kissattach work and having a lot of trouble with it. Is the source code ready for test yet? Also, would this work with QtSoundmodem, which also can use AGWPE?

[martinhpedersen]

You'll need to build the feature/agwpe-engine branch from source.

1. Install Go: apt install golang
2. Build the agwpe branch of Pat: GOPROXY=direct go install github.com/la5nta/pat@feature/agwpe-engine
3. Start your TNC and make sure AGWPE is enabled on port 8000.
4. Run the custom Pat build: $HOME/go/bin/pat http.

If you're having troubles, please run with AGWPE_DEBUG=1 and include the full log output. (AGWPE_DEBUG=1 $HOME/go/bin/pat).

Please report back 🙂 Thank you!

[alaskalinuxuser]

alaskalinuxuser@alaskalinuxuser-CF-52NKE102M:~/installed$ GOPROXY=direct go install github.com/la5nta/pat@feature/agwpe-engine go: downloading github.com/la5nta/pat v0.13.1-0.20220824175112-4a0c4b7e2cb0 go: github.com/la5nta/pat@feature/agwpe-engine: github.com/la5nta/pat@v0.13.1-0.20220824175112-4a0c4b7e2cb0 requires github.com/harenber/ptc-go/v2@v2.2.3: verifying go.mod: checksum mismatch downloaded: h1:wubxr0EvHHQ++eIR/ZSP7yustDHEW0ROdMKmiu0eOVw= sum.golang.org: h1:SDIy4XqnUq6YYPcLLjDTfbLPf1/Z82ho1VPkPGVXSTo=

SECURITY ERROR This download does NOT match the one reported by the checksum server. The bits may have been replaced on the origin server, or an attacker may have intercepted the download attempt.

For more information, see 'go help module-auth'.

So, I tried ~/installed$ go clean -modcache And ran the command again, but it still errors on security.

Any thoughts?

[alaskalinuxuser]

So, I downloaded it by hand and built it:

52 mkdir patAGW 53 cd patAGW/ 54 cp ~/Downloads/pat-feature-agwpe-engine.zip ./ 55 unzip pat-feature-agwpe-engine.zip 56 ls 57 cd pat-feature-agwpe-engine/ 58 ls 59 go install ./ 60 ls ~/go/bin/ $ cd ~/go/bin/ $ ./pat http

And I got an error about my config file. I deleted the config file, and ran ./pat configure, filled in my usual info at the top and left the rest. I then ran QtSoundmodem, made sure to turn on AGW port 8000, and ran ./pat http, selected ax.25, the station I wanted, and this was the log:

2022/08/28 17:34:44 Starting HTTP service (http://localhost:8080)... 2022/08/28 17:35:06 AGWPE TNC initialization failed: dial tcp 127.0.0.1:8000: connect: connection refused

No time to play with it tonight, maybe tomorrow I can try it out some more. Thanks for including me in the testing!

[alaskalinuxuser]

Had a few more minutes, so I tested with Direwolf:

direwolf.conf $ cat direwolf.conf

My direwolf config

ADEVICE - plughw:2,0

ACHANNELS 1

CHANNEL 0

MYCALL KL4TH-0

MODEM 1200

TXDELAY 500 TXTAIL 50

AGWPORT 8000 KISSPORT 8001

IGTXLIMIT 6 10

I launched pat first, then direwolf, and it connected pat and direwolf right away: alaskalinuxuser@alaskalinuxuser-CF-52NKE102M:~$ sudo direwolf -t 0 -p [sudo] password for alaskalinuxuser: Dire Wolf version 1.6 Includes optional support for: gpsd hamlib cm108-ptt

Reading config file direwolf.conf Line 13: Invalid time for transmit delay. Using 30. Audio input device for receive: stdin (channel 0) Audio out device for transmit: plughw:2,0 (channel 0) Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate. Note: PTT not configured for channel 0. (Ignore this if using VOX.) Ready to accept AGW client application 0 on port 8000 ... Ready to accept KISS TCP client application 0 on port 8001 ... Virtual KISS TNC is available on /dev/pts/4 Created symlink /tmp/kisstnc -> /dev/pts/4

Attached to AGW client application 0...

Ready to accept AGW client application 1 on port 8000 ...

=========================

Then I tried ax.25 and attempted connection: alaskalinuxuser@alaskalinuxuser-CF-52NKE102M:~/go/bin$ ./pat http 2022/08/28 17:47:19 Starting HTTP service (http://localhost:8080)... 2022/08/28 18:37:10 AGWPE TNC (2005.127) initialized 2022/08/28 18:37:10 Connecting to KL7EDK-10 (ax25+agwpe)... 2022/08/28 18:38:03 Unable to establish connection to remote: *** DISCONNECTED RETRYOUT With KL7EDK-10

=============================

With direwolf reporting: Ready to accept AGW client application 1 on port 8000 ... Attempting connect to KL7EDK-10 ... [0L] KL4TH>KL7EDK-10:(SABME cmd, p=1) [0L] KL4TH>KL7EDK-10:(SABME cmd, p=1) [0L] KL4TH>KL7EDK-10:(SABME cmd, p=1) [0L] KL4TH>KL7EDK-10:(SABM cmd, p=1) [0L] KL4TH>KL7EDK-10:(SABM cmd, p=1) [0L] KL4TH>KL7EDK-10:(SABM cmd, p=1) [0L] KL4TH>KL7EDK-10:(SABM cmd, p=1) [0L] KL4TH>KL7EDK-10:(SABM cmd, p=1) [0L] KL4TH>KL7EDK-10:(SABM cmd, p=1) [0L] KL4TH>KL7EDK-10:(SABM cmd, p=1) Failed to connect to KL7EDK-10 after 10 tries.

So it looks like your portion works! Not sure why my direwolf or qtsoundmodem can't connect to the other station. Same rig, dials, etc, same laptop dual booted to windows with rms and soundmodem hooks right up, but that is probably my issue, not yours.

[alaskalinuxuser]

Either way, this is way better than dealing with axports and kissattach!

[alaskalinuxuser]

Oh, and with debug on both Qt and DW

Debug with QtSoundmodem and pat: AGWPE_DEBUG=1 $HOME/go/bin/pat http 2022/08/28 20:26:49 Starting HTTP service (http://localhost:8080)... 2022/08/28 20:27:29 -> Port: 0. Kind: X. From: KL4TH. To: , Data: "" 2022/08/28 20:27:29 <- Port: 0. Kind: x. From: KL4TH. To: , Data: "\x01" 2022/08/28 20:27:39 demux closing (1 clients)... 2022/08/28 20:27:39 demux exited 2022/08/28 20:27:39 chain exited 2022/08/28 20:27:39 demux closing (2 clients)... 2022/08/28 20:27:39 demux exited 2022/08/28 20:27:39 read failed: read tcp 127.0.0.1:53284->127.0.0.1:8000: use of closed network connection 2022/08/28 20:27:39 TNC run() exited 2022/08/28 20:27:39 AGWPE TNC initialization failed: context deadline exceeded

=====================

Debug with Direwolf and pat: $ AGWPE_DEBUG=1 $HOME/go/bin/pat http 2022/08/28 20:30:19 Starting HTTP service (http://localhost:8080)... 2022/08/28 20:30:37 -> Port: 0. Kind: X. From: KL4TH. To: , Data: "" 2022/08/28 20:30:38 <- Port: 0. Kind: X. From: KL4TH. To: , Data: "\x01" 2022/08/28 20:30:38 Port 0 registered as KL4TH 2022/08/28 20:30:38 -> Port: 0. Kind: R. From: . To: , Data: "" 2022/08/28 20:30:38 <- Port: 0. Kind: R. From: . To: , Data: "\xd5\a\x00\x00\u007f\x00\x00\x00" 2022/08/28 20:30:38 AGWPE TNC (2005.127) initialized 2022/08/28 20:30:38 Connecting to KL7EDK-10 (ax25+agwpe)... 2022/08/28 20:30:38 -> Port: 0. Kind: C. From: KL4TH. To: KL7EDK-10, Data: "" 2022/08/28 20:31:31 <- Port: 0. Kind: d. From: KL7EDK-10. To: KL4TH, Data: " DISCONNECTED RETRYOUT With KL7EDK-10\r\x00" 2022/08/28 20:31:31 disconnect frame received - connection teardown... 2022/08/28 20:31:31 demux closing (1 clients)... 2022/08/28 20:31:31 demux exited 2022/08/28 20:31:31 Unable to establish connection to remote: DISCONNECTED RETRYOUT With KL7EDK-10

And that's all for tonight. Thanks for working on this!

[martinhpedersen]

Thanks for the detailed report @alaskalinuxuser 🙂

It looks like QtSoundmodem is sending an 'x' frame (unregister frame) in response to the register frame sent by Pat. According to my reference specs, the TNC should never send this frame... but I guess it's the QtSoundmodem's authors way of nack'ing the registration command 🤔.

Maybe QtSoundmodem requires authentication? Can you please have a look at it's config and try to remove/disable any AGWPE auth?

[alaskalinuxuser]

I went through all the QtSoundmodem settings and the config file, and I don't see anything relating to authentication in there, for agwpe or anything else, either.

I did not review the source code, though.

[jboverfelt]

I just gave this branch a shot with direwolf and was successfully able to connect to a Winlink node on 2m using a Signalink USB on Linux. I wasn't able to get ax25 and kissattach working before so this is awesome! Let me know if you want me to try other things!

-Justin AB3E

[martinhpedersen]

Thanks 😊

Things to test, from the top of my head:

1. Normal session without traffic is working and does not leave the TNC/application in a bad state.
2. Unsuccessful connect does not leave the TNC/application in a bad state.
3. Dial cancellation (abort before remote answer) is working and does not leave the TNC/application in a bad state.
4. Sending of outbound message (> 1kB) gives correct progress indication in UI.
5. Incoming P2P connections are working.
6. Transfer of large messages are working as expected, both inbound and outbound.
7. Subsequent connections are working as expected.
8. Loss-of-link produces session error and does not leave the TNC/application in a bad state.
9. The listener, when enabled, is automatically re-established after TNC restart.

And of course random stress testing under various conditions. Use it as often as possible 😊

If you discover a reproducable bug, please report back with the full debug log output when running Pat. Debug output is enabled by setting the environment variable AGWPE_DEBUG=1.

Thanks!!

[jboverfelt]

I'll detail the things from your list I was able to try below. First though, I noticed some output from direwolf after every session (successful or not):

Error getting message header from AGW client application 1. Tried to read 36 bytes but got only 0. Closing connection.

I'm wondering if direwolf is expecting some kind of wrap-up that Pat isn't providing. Either way, it doesn't seem to affect the actual function of Pat and doesn't leave direwolf in a bad state. Send me an email at [callsign] [at] arrl.net (address is also on QRZ) and I'll send you the Pat debug output if you'd like. You can also send me a message on Winlink. Pat itself doesn't display an error or give any indication that anything went wrong. The connection string I'm using is just: ax25+agwpe:///N3HYM-10

1. Works - no issues
2. Works
3. Works
4. The progress indicator seems to go 100% before the message is actually done, but sending of a large (several kilobyte) message works without issue
5. Haven't tried yet
6. Works
7. I tried all these tests in succession and didn't have any problems
8. Works
9. Haven't tried yet

The club I'm in uses Winlink regularly so I should have lots of opportunity to put this through the paces. The only Winlink node close to me is very close to me though, so I probably can't test poor conditions very well.

-Justin AB3E

[martinhpedersen]

Thanks for testing and reporting back @jboverfelt 🙂

I had some time to test this myself yesterday, and identified a few issues related to connection teardown, Write throttling and flushing. I've updated the branch. Please keep on testing. 😃

It looks like Direwolf's AGWPE implementation have some issues that we might not be able to work around in a way that is compatible with other implementations. I'll keep focusing on Direwolf since that is very portable and seems most popular on most UNIX platforms. But we should probably start testing against other TNCs soon, and at least keep a list of "compatible AGWPE software" in the wiki for reference. For instance, Direwolf users should be recommended to make sure they at least run >= v1.6. Direwolf v1.1 and below will definitely not work, as it's lacking very important AGWPE features.

[wb2osz]

Rather than trying to work-aound issues with the AGW protocol implementation in direwolf, please work with me directly so we can get those issues resolved.
I strongly urge you to use the "dev" development branch (which will be version 1.7) because it fixed a problem with "Proper counting of frames in transmit queue for AGW protocol 'Y' command." There might have been other minor changes that I did not bother to put in the high level change log. When reporting issues, be sure to use the "-d a" command line option to display everything being sent over the protocol.

Thanks & 73, John WB2OSZ

[martinhpedersen]

Thanks for getting involved John, it's highly appreciated 😊 I will re-run my tests against your dev branch when I have time. I'll keep you in the loop and report any issues I find 👍

[jboverfelt]

@martinhpedersen I've pulled the latest branch changes for pat and I'm still seeing that same "tried read 36 bytes but only got 0" from Direwolf (v1.6). Everything that worked before still seems to work though - I have not noticed anything which has prevented me from sending or receiving messages. When sending a longer message, the progress percentage goes directly to 100% just as before. Not sure if you expected these things to be fixed or not with the new commit.

Unfortunately I don't have other TNCs to test against, though I do have a NucleoTNC board coming soon so I could build that and give it a shot. Direwolf definitely seems to be the most popular given the number of people that run pat on raspberry pis.

[martinhpedersen]

Thanks @jboverfelt 🙂

When sending a longer message, the progress percentage goes directly to 100% just as before. Not sure if you expected these things to be fixed or not with the new commit.

What was the uncompressed size of that message? I guess if the message is short enough not to exceed MAXFRAMES*PACLEN bytes (usually 7*128 for Pat) in compressed form, then you would get that behavior. The problem is that AGW does not report the number of bytes in the tx buffer queue, so we can't get 100% reliable progress. But you should see an approximately correct progress indicator when sending messages of larger sizes (e.g. > 10kB).

[jboverfelt]

Alright I sent a message body of about 20kB (that took a while at 1200 baud!!), and the progress worked perfectly. Everything I was sending before was much smaller.

[martinhpedersen]

I'd love to get more feedback on this feature ❤️

For anyone willing to test:

1. Prepare prerequisites:
   • Install Go
   • Install Direwolf (latest stable version)
   • Configure and start Direwolf (AGWPE is enabled by default - See example config below)

2. In your terminal:

   # Build the agwpe branch
   mkdir -p "$HOME/pat-agwpe" && GOBIN="$HOME/pat-agwpe" go install github.com/la5nta/pat@af2d73e
   
   # Run the custom build
   cd $HOME/pat-agwpe
   ./pat connect ax25:///FOOBAR

Here is the minimal direwolf config (direwolf.conf) required on my Macbook Pro:

ADEVICE  "MacBook Pro-mikrofon"  "MacBook Pro-høyttalere"

[jboverfelt]

Your comment reminded me I tried something else and neglected to mention it: the gateway I normally used changed locations and I now use a digipeater to access it. I was able to successfully use AGWPE and pat to access!

[martinhpedersen]

Excellent! Thanks 😀

[richcannings]

I just installed and ran today on my IC-705 and M2 Macbook Air. It works amazingly. Note I needed to skip the checksums when installing using, "GOPROXY=direct GOSUMDB=off go install github.com/la5nta/pat@feature/agwpe-engine". I am using the macports version of Direwolf (1.6).

Test 1 through 4 in https://github.com/la5nta/pat/issues/367#issuecomment-1264456814 worked perfect for me.

[martinhpedersen]

Thank you @richcannings 😊

[JohnRudolfLewis]

I was banging my head against the wall trying to fix the kernel issue I was experiencing while trying to configure ax.25 on my laptop. I just tried this out, was able to connect to a nearby 2m RMS host and send/receive emails. I hope this gets merged into mainline soon.

[martinhpedersen]

Thanks @JohnRudolfLewis 👍

There is a lot of good feedback here, at least from Direwolf users. No bugs have been uncovered afaik. I guess it's time to consider releasing it then, at least as an experimental feature 🙂

[martinhpedersen]

I forgot, Periodic beacon is still TODO. I think we should finish that before releasing as it is required to operate a packet station in most countries.

[martinhpedersen]

Beaconing done ✅

[pliniker]

Thank you so much for this feature! ❤️