<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:Consolas;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sometimes when this happens, we’ll also see entries like the following in our log:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoPlainText>Tue Aug 18 08:42:22 2015 - MBOX (callsign-1) fwd failed - DM received errno 111<o:p></o:p></p><p class=MsoPlainText>Tue Aug 18 12:42:22 2015 - MBOX (callsign-1) fwd failed - DM received errno 111<o:p></o:p></p><p class=MsoPlainText>Tue Aug 18 16:10:27 2015 - MBOX (callsign-1) fwd failed - DM received errno 111<o:p></o:p></p><p class=MsoPlainText>Tue Aug 18 17:10:57 2015 - MBOX (callsign-1) fwd failed - DM received errno 111<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><span style='font-family:"Calibri",sans-serif'>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.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-family:"Calibri",sans-serif'>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.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-family:"Calibri",sans-serif'>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.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-family:"Calibri",sans-serif'>Both ends are using Kantronics KPC-3+ TNCs. <o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-family:"Calibri",sans-serif'>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.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I did find this related thread:<o:p></o:p></p><p class=MsoNormal>http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So has anyone seen this problem (port stops answering connect requests, or the TNC starts buffering data, or lots of “DM received”)?<o:p></o:p></p><p class=MsoNormal>If so, what did you do to correct it?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(I’m hoping for an answer other than “switch to a different brand of TNC”).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Michael<o:p></o:p></p><p class=MsoNormal>N6MEF<o:p></o:p></p></div></body></html>