Connected Data from AGWPE client not sent

[jmkristian]

When an AGWPE client requests to send 5 data packets via connected AX.25, Direwolf sends only 4 of them. This problem occurs with Direwolf version 1.5 Beta (Jan 8 2018), but doesn't occur with Direwolf version 1.4. The problem doesn't occur when sending fewer frames.

To reproduce the problem, I requested to send 5 frames via an AX.25 connection with MAXFRAME 2. Direwolf sent 2 frames, received an acknowledgement (I cmd, n(r)=2), sent 2 more frames, received an acknowledgement (RR res, n(r)=4) and did not send more frames. After a long delay, the remote station sent a DISC.

I run Direwolf on Windows XP SP 3. The AGWPE client is Outpost Packet Manager version 3.2.0 c103.

[jmkristian]

Here is some output from Direwolf 1.5 Beta, which illustrates the problem.
1.5-beta.txt

And here is the output from Direwolf 1.4, which doesn't have the problem.
1.4.txt

[jmkristian]

Here's a copy of the direwolf.conf file I used for Direwolf 1.5 Beta.
direwolf.conf.txt

[dranch]

Hello John,
There have been some irregularities reported with Outpost's AGWPE's interface but it sounds like this might be a real issue. I have Outpost installed here on Linux (under Wine) and I'll try to reproduce. Any chance you can try with a newer version of Windows? Something like Win7, 8.1, or 10?

--David
KI6ZHD

[jmkristian]

Yes, I'll try it with Windows 8.1 Pro. What information would you like from that test? Best regards, John KM6LQZ

…

On 2/28/2018 7:44 AM, David Ranch wrote: Hello John, There have been some irregularities reported with Outpost's AGWPE's interface but it sounds like this might be a real issue. I have Outpost installed here on Linux (under Wine) and I'll try to reproduce. Any chance you can try with a newer version of Windows? Something like Win7, 8.1, or 10? --David KI6ZHD

[jmkristian]

The problem occurs with Direwolf 1.5 Beta running on Windows 8.1 Pro. Here is the output from Direwolf.
Win-8.1Pro.txt

[DonMcKee]

I am having the same problem as John. I'm running on a Windows 10 system with Direwolf 1.5 beta 2. I am also using Outpost (3.2.0 c106) on the front end, and talking to the same family of BBS' on the back end.

The issue is consistently reproducible for me. I've attached a couple of Direwolf logs. The first shows a successful transfer. The second shows a message 1 character longer that fails. Let me know if you need any more info.

-Don, KE6DM

1.5-beta2-works.txt
1.5-beta2-fails.txt

[wb2osz]

I have been able to reproduce the problem and understand why outgoing data will sometimes get stuck in the queue rather than being transmitted. A solution should be available soon.

[wb2osz]

I think this has been fixed in 1.5 beta test 3. Waiting for confirmation.

[DonMcKee]

v1.5 beta 3 fixed the problem I was having. Thanks!

-Don, KE6DM

[jmkristian]

Version 1.5 beta 3 doesn't have this problem, I find. Thank you!

For example, here's some output from Direwolf.
1.5-beta3.txt

[ixdy]

I'm having a related problem (maybe not the same one) with direwolf 1.5 beta test 3, using Outpost PM (via wine) and the AGWPE interface. All of this is running on macOS, though I don't think that's a factor here

Oddly, it sometimes works, but often does not. And I seem to be having much more trouble with one BBS (the closest one to me, actually the same one as @jmkristian) than some others.

Relevant configuration parameters in my direwolf.conf:

DWAIT 5
PERSIST 63
SLOTTIME 10
MAXFRAME 2
RETRY 10
FRACK 6
PACLEN 128

V20 W1XSC-1
V20 W2XSC-1
V20 W3XSC-1
V20 W4XSC-1
V20 W5XSC-1

aj6xz-w3xsc-1-working.txt
aj6xz-w3xsc-1-fail.txt

In this particular example, direwolf got stuck on A XSCEVENT\n, but I've seen it get stuck on other parts of this, too - it's definitely nondeterministic.

[ixdy]

Again, this time passing -dp to dump the ax.25 packets:
aj6xz-w3xsc-1-fail2.txt
aj6xz-w3xsc-1-working2.txt

[ixdy]

another example; this one got stuck even earlier:
aj6xz-w3xsc-1-fail-earlier.txt

[jmkristian]

I see that AJ6XZ had to retransmit SABM before W3XSC-1 responded. Perhaps AJ6XZ is having trouble transmitting to W3XSC-1. For example, perhaps the audio level is too high or too low, or the radio power is too low, or the transmitting antenna is in a difficult position.

To isolate this kind of problem, it would be helpful to have timestamps in the output from Direwolf. In this case, I'll suspect that W3XSC-1 transmitted DISC because it timed out awaiting RR. The elapsed time would help confirm or deny this suspicion.

[jmkristian]

To get timestamps, one can run Direwolf with the command line option -T "%H:%M:%S".

[ixdy]

Yes, the DISC was sent by W3XSC about a minute after the last RR frame was sent from AJ6XZ.

I'll re-run it tonight with timestamps, but my experience was that direwolf would send the RR frame (with f=0) and then do nothing else, and after about a minute or so, W3XSC would time out the connection and send the DISC command.

If it was a signal issue, is there no retry on RR frames?

What's also curious is that in the working cases direwolf sent that RR packet and then immediately sent the I packet without any acknowledgement from W3XSC. In the failing cases, it gets stuck.

[ixdy]

Also, I think that repeated SABM frame was because I forgot to turn on PTT on my Rigblaster before trying to connect. I've got a j-pole about 10ft above ground level, at 25W, and 4.1 miles to the BBS, so I would hope that's not the issue.

[jmkristian]

In all of the aj6xz-w3xsc-1 files, including the working ones, I see AJ6XZ retransmitted some packets. In the cases that worked, I suppose one of the retransmissions was received, In the cases that failed, it retransmitted RR (among other packets).

Perhaps the transmitted audio level is too high or too low, so W3XSC has trouble demodulating it. One way to adjust the level is to monitor the frequency with another radio, feed its received audio to an oscilloscope, and see if it's a nice sine wave. A common problem is that the audio is clipped by a circuit designed to prevent over-modulation.

[ixdy]

It's definitely possible that something is set up wrong between my rigblaster and radio. I don't have all the equipment I need to calibrate that, but I'll try to do that over the weekend. Regardless, I would've expected direwolf to handle this more gracefully.

I'm attaching another failure log here, this time with -do (for PTT/DCD debugging) and -t "%H%m%s" (for frame timestamps): 2018-07-19-aj6xz-w3xsc-failure.txt

[ixdy]

and for comparison, another successful session, with the same debugging arguments: 2018-07-19-aj6xz-w3xsc-success.txt

[jmkristian]

The Direwolf command line timestamp option is case-sensitive, so -t "%H%m%s" is different from -T "%H%M%S".

[ixdy]

good catch. I actually ran with -T "%H%m%s", but miscopied that to my comment here.

[wb2osz]

I believe this has been fixed in 1.5 beta test 4.
Are we ready to promote this to 1.5 stable release version?

[jmkristian]

I haven't tried 1.5 Beta 4. Actually I don't know how to try it. I see there's a git tag, but I don't know where to get a win.zip file, nor how to build one.

[DonMcKee]

I, too, am dependent upon the Windows build, so I haven't tried 1.5 beta 4. However, I've been using 1.5 beta 3 since it was released, and it's been working great. If the fix wasn't regressed between beta 3 and beta 4, it should be good to go!

-Don, KE6DM

[ixdy]

There appears to be a Windows build posted on the releases page now.

[jmkristian]

Since the Beta 4 release didn't include a complete DireWolf folder, I made a copy of my Beta 3 folder and replaced direwolf.exe by downloading from the Beta 4 release page. This problem does not occur in the result.

[wb2osz]

Fixed long ago.