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

Michael Fox (N6MEF) n6mef at mefox.org
Wed Aug 19 00:02:07 EDT 2015

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

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

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

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


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


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


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:



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





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

More information about the nos-bbs mailing list