[nos-bbs] "fwd failed - DM received"

[Michael Fox (N6MEF)]

We've been experiencing a problem with JNOS forwarding over RF with another
JNOS BBS.    I'm wondering if anyone has had similar symptoms and, if so,
whether or not you found a cure.

 

Occasionally, the interface will stop accepting connect requests.  A view of
the interface log shows the connect request isn't heard.  So either the TNC
is in some state such that it's not sending the connect requests through to
JNOS, or the JNOS port is in some state such that it's ignoring them.

 

Sometimes when this happens, we'll also see entries like the following in
our log:

 

Tue Aug 18 08:42:22 2015 - MBOX (callsign-1) fwd failed - DM received errno
111

Tue Aug 18 12:42:22 2015 - MBOX (callsign-1) fwd failed - DM received errno
111

Tue Aug 18 16:10:27 2015 - MBOX (callsign-1) fwd failed - DM received errno
111

Tue Aug 18 17:10:57 2015 - MBOX (callsign-1) fwd failed - DM received errno
111

 

These entries occur when our JNOS is calling the other JNOS.  But they are
not 100% correlated.  In other words, at the time the above log entries
happened, our JNOS was accepting connections just fine, but the other JNOS
was not.  On the other hand, sometimes when we see these entries, we check
our system and it has stopped accepting connections.

 

We also seen cases where the TNC on the other end would buffer data for
several minutes, such that what the other JNOS saw was several minutes
delayed.

 

In all cases, exiting JNOS, taking the TNC out of KISS mode, and then
restarting JNOS (which will put the TNC back into KISS mode) clears the
problem.

 

Both ends are using Kantronics KPC-3+ TNCs.  

 

We believe the problem is data related, but we have no proof.  The problem
does NOT occur on access ports.  Only the forwarding port.  So we suspect
that there's something in the forwarding data stream that's causing the TNCs
(or the JNOS ax.25 code) to wind up in some funky state.

 

I did find this related thread:

http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html

 

But as with many such threads, the information seems to be self-conflicting.
Specifically, they give the commands to disable software flow control (good,
we do that) but they also suggest shorting RTS and CTS together, which would
also disable hardware flow control.  That doesn't make any sense to me.

 

So has anyone seen this problem (port stops answering connect requests, or
the TNC starts buffering data, or lots of "DM received")?

If so, what did you do to correct it?

 

(I'm hoping for an answer other than "switch to a different brand of TNC").

 

Thanks,

Michael

N6MEF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20150818/703d2a44/attachment.html>