Unable to establish connections use AGW #497
Comments
|
Thank you for reporting issues encountered. There is a lot to digest here. This is trying to connect with AX.25 version 2.2 (SABME). Attempting connect to KZ2X-1 ... This is a really bad case of audio cross talk. The transmitted signal is being received. It is visually confusing but should not hurt. Direwolf release 1.7 avoids this. N1LKS audio level = 35(21/19) 334______ Connection is successful. What AX.25 implementation is used at KZ2X-1? KZ2X-1 audio level = 103(45/41) 0000001__ We get a greeting from the system. KZ2X-1 audio level = 104(43/41) 0000000__ Here we are sending the XID command to negotiate parameters such as packet data size, window size, whether SREJ is available, and so on. A v 2.2 implementation should be able to process this. [0L] N1LKS>KZ2X-1:(XID cmd, p=1) Half-Duplex REJ SREJ Multi-SREJ modulo-128 I-Field-Length-Rx=256 Window-Size-Rx=32 Ack-Timer=3000 Retries=10 This makes absolutely no sense at all. Why are we shutting down the connection? [0L] N1LKS>KZ2X-1:(DM res, f=1) To be continued... |
|
I'm not sure what kz2x-1 is using (I'll ask), but the Brock digipeater looks like a kantronics of some sort. |
|
Third example. AX.25 v2.0 was forced and we use SABM rather than SABME. Attempting connect to BROCK ... At this point, we should send an RR to ack the information frame. [0L] N1LKS>BROCK:(DM res, f=1) Could you try a different terminal app such as UZ7HO EasyTerm or QTterm - forget the exact name. Those two are known to work. To be continued. |
|
I live on Stedman St which crosses the Lowell/Chelmsford boundary. Do you have any connection to the street name? |
|
Sending two DM packets after receiving an "I" from makes to sense. |
I am using release 1.7.
Sure, I'll do that. I'll try to gather those logs later this evening (or tomorrow if that doesn't work out).
Not as far as I know! To add to the confusion, here's easyterm failing to connect to BROCK: And then here's the exact same connection working using qttermtcp: This seems repeatable (qttermtcp connects successfully when both easyterm and agwterm will not). In all cases, I'm running the clients on the same system and they are connecting to the same Direwolf instance (running on a raspberry pi). In both cases, the client is configured with a paclen of 128. My |
|
The really confusing thing is that later in the evening (i.e., now), the connection is suddenly working correctly with both agwterm and easterm. |
|
Capturing the trace was tricky because the behavior is inconsistent -- at times the connections Just Work, but then something happens and they reliably don't work. I thought that maybe some internal state in Direwolf was getting corrupt, but simply restarting Direwolf does not resolve the problem. Connections via the Linux ax.25 stack (e.g. using There are two traces here. First, here's a trace with Next, here's a successful connection initiated immediately after the previous one using qttermtcp: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm seeing some odd behavior trying to connect to remote systems via Direwolf's AGW support.
Originally I was writing my own code using the
wl2k-gopackage, and I thought maybe the problem was either with that package or with my code...but I'm able to reproduce the same behavior usingagwterm.The issue is that while connections are established successfully, Direwolf shuts down the connection as soon as the remote host sends an RR frame. That is:
I've been testing things against a local packet BBS and a local digipeater. For example, here's the log from attempting to contact a local packet BBS using
agwterm:A connection using the kernel AX.25 support (
axcall radio KZ2X-1) works just fine:If I configure the remote system as AX.25 V2.0 only by setting:
Then I see a similar problem. There's no XID response, but we immediately start replying with DM frames after receiving data from the remote host:
The text was updated successfully, but these errors were encountered: