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".