[nos-bbs] Tuning nos

[Jay Nugent]

Greetings Skip,

On Sun, 23 Mar 2008, (Skip) K8RRA wrote:

> I have a situation and I wonder if others here have an improvement I
> might make.  The situation is that from time to time I get flooded with
> repeat TCP packets, and I generate a flood of answers.
> 
> For example, this afternoon my host replied "SMTP ready" in a string of
> 38 consecutive TCP packets with only two sequence numbers over a period
> of 15 minutes at 1200Baud.  I'm getting a similar number of incoming
> requests.

   Often times this can be caused by a known problem with the KISS 
protocol.  It goes something like this:

   o JNOS sends a frame (over KISS) to the TNC.
   o But the TNC hears something on the RF channel so it holds off 
     transmitting until the channel is clear.
   o The IP stack in JNOS doesn't see an ACK to the sent frame so the
     T3(?) timer times out, it assumes the frame was lost, and sends 
     a duplicate frame over the KISS link to the TNC.
   o We now have TWO copies of the SAME frame in the buffer of the TNC.
   o The IP stack times out yet again, and sends a THIRD frame, etc,
   o This process continues until the TNC finally sees that the radio 
     channel is "clear" of any other activity (DCD) and allows *ALL* of 
     the buffered frames to be burst out over the air all as one hugh 
     burst!

   Ya see, KISS doesn't "handshake" back to JNOS any information about the
status of the DCD line, the status of any frames pending, etc.  And JNOS
"assumes" that if it sent a frame toward the TNC that it actually got sent
out over the air.  A correct assumption as in *most* cases the frames DO
get sent and things chug along nicely.  But what situation(s) can occur
where duplicate frames get queued up???

   1) A lot of activity on an RF channel (even quite a distance away) can
      cause a TNC to hear constant carriers for long periods of time.

   2) Using a TNC that does *NOT* support "software-carrier-detect" (TAPR 
      called this the "DCD Mod" for its TNC-2 & clones) but leaving the 
      squelch control wide open.  The white noise hiss *may* cause the TNC 
      to 'think' a valid data carrier is present and therefore hold off 
      ever transmitting.

   3) Some TNC's don't adaquately clamp the transmit audio from the
      "MO"dulator part of the MODEM (the MODEM is continuously generating
      a tone even when not in use).  This can allow some of the audio
      energy to crosstalk back into the receive audio line, faking out the 
      MODEM into thinking that it hears a data carrier.  When in fact it
      is only hearing itself!
      NOTE: Some rigs are notrorious for this kind of 
            crosstalk (i.e. Kenwood TR-7400's)


> Further:  It *seems* like a huge waste of bandwidth.  Yet, I can't find
> anything to change...

   It certainly can be.  But when users hear these "monster frames" being
sent it is a good idea to identify WHO is sending them.  Then work with
that user to determine why the frames became backlogged.

 
> Something that complicates this is how hard it is to see the problem.
> Without the trace on I could not see the issue, and the only measurable
> effect is that it took more than an hour for SMTP to transfer a small
> mail -- nobody watches SMTP / it's as automatic as it gets.

   First thing I check for is that the SMTP sending station has his "smtp 
timer" set long enough that the entire transaction of sending a reasonably 
sized message can be completed BEFORE his smtp timer expires.  If it 
expires before the message is transfered, the WHOLE PROCESS is restarted 
from scratch and the message will be retried ad-infinitum...

   In the Michigan AMPRnet I still have a few nodes out there that have 
their SMTP TIMERs set at 300 (5 minutes).  This is too short in some 
situations and I have been extending them out to 15 to 20 minutes.  YMMV.

   Skip, I had a LONG smtp message recently try to get across a rather
slow RF path the other day.  It was unsuccessfull after several attempts.  
It appeared the TCP session was timing out before the message completed.  
I never did figure that one out and finally gave up and read the contents
of the senders /nos/spool/mqueue/<job_num>.txt file, then deleted it
(along with the matching .wrk and .lck files).  Sure, this didn't FIX the
offending problem, but it quieted all the chatter on the air that
afternoon :)

   Good luck in your diagnosis, sir!

      --- Jay  WB8TKL
          Chair, ARRL Michigan Section "Digital Radio Group" (DRG)
          [www.MI-DRG.org]

"Getting rid of terrorism is like getting rid of dandruff.  It cannot
 be done completely no matter how hard you try." -- Gore Vidal
+------------------------------------------------------------------------+
| Jay Nugent   jjn at nuge.com    (734)484-5105    (734)544-4326/Fax        |
| Nugent Telecommunications  [www.nuge.com]     (734)649-0850/Cell       |
|   Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.net] ISP & Modem Performance Monitoring |
| Web-Pegasus    [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
| LinuxNIC, Inc. [www.linuxnic.net]   Registrar of the .linux TLD        |
+------------------------------------------------------------------------+
  1:01am  up 151 days,  2:12,  5 users,  load average: 0.01, 0.04, 0.06