[nos-bbs] JNOS use of the poll/final bit in I-frames - comments ?

[Boudewijn (Bob) Tenty]

I guess he tested that from the command prompt of that tnc in the TS-2000, so using the ax25 stack in it.
Most hams put their  tnc into kiss, so the ax25-stack is offloaded to the packet program version in the PC.
May I assume that he doesn't see that problem when he put that tnc in his Kenwood  into kiss?

Boudewijn VE3TOK

On 7/22/25 22:17, maiko at pcsinternet.ca wrote:
> With permission from Dave Platt, AE6EO (openTNC project) ...
>
> Comments from anyone ? This is quite technical, would like to hear from
> those well versed in this stuff please ?
>
> 1. Let me preface this with a correction he sent to me afterwards
>
> did find one mistake in what I'd told you.  The T2 timer is controlled by
> the RESPTIME setting, not FRACK.  I've just checked the TASCO modem in my
> TS-2000, and its RESPTIME is set to 5, so it should be acknowledging I-frames
> by itself... but it doesn't do so, while my TNC-2 does (and, of course, so
> does OpenTNC).
>
> 2. Mentions an aspect of JNOS's use of AX.25 which seems a bit odd.
>
> it's different than any other TNC I've studied, and (unfortunately) it
> can "tickle" a bug/shortfall in certain other TNCs.
>
> It has to do with the use of the poll/final bit in I-frames.
>
> If one sets the P/F bit in an I-frame, it's a request to the peer to
> send back an RR/RNR/REJ at the earliest possible opportunity, to advance
> the transmit window (the RR/RNR/REJ is supposed to be sent back with the
> P/F bit set).  It's also (implicitly) an indication that "This is it for
> now, no further frames are coming during this transmission".
>
> Most TNCs will do this, setting the P/F bit in the last I-frame in a
> series that they're sending (i.e. the one which fills up the MAXFRAME
> window).  This causes the peer to acknowledge the received I-frames
> immediately, without having to wait for the peer's T2 "I have packets to
> acknowledge" timer to expire.  As far as I can tell this is not a
> mandatory "SHALL" part of the protocol, but it does seem to be very
> common practice, as it leads to a speedier connection.
>
> I stumbled across this issue when using our county's emergency-service
> JNOS BBS system, with my Kenwood TS-2000 and its internal TNC (which is
> reported a single-chip design by TASCO).  When downloading files and
> messages, the transmission was extremely slow:
>
>      * JNOS sends two I-frames
>      * TS-2000 just sits there.
>      * Several seconds pass.
>      * JNOS sends an RR with P/F set.
>      * TS-2000 sends back an RR with P/F set,
>             acknowledging successful reception of both I-frames.
>      * JNOS sends two more I-frames
>      * Lather, rinse, repeat.
>
> If I switched from the internal TASCO modem to an MFJ-1270 (a TNC clone)
> or a KPC-3 (or the Linux AX.25 stack) there were no such delays... the
> exchange would go directly from step 1 to step 5.
>
> What I've concluded is that the TASCO modem simply doesn't implement the
> T2 protocol timer at all!  It implements the FRACK command which is
> supposed to control T2, but this command doesn't actually affect
> operation.  The TASCO won't acknowledge inbound frames unless explicitly
> polled.  Really sloppy of them.
>
> If I use the TS-2000/TASCO combination to connect to a different TNC
> (something other than JNOS), the problem isn't evident, because the
> other TNCs I've tested do set the P/F bit in the last I-frame in each
> burst.  The TASCO immediately responds to this by sending an RR with P/F
> set, and the data transfer continues immediately.
>
> I've skimmed through the JNOS code, and as far as I can tell, it doesn't
> seem to have any logic which allows it to set P/F on an I-frame it
> transmits.
>
> What's more, it has an optimization for unacknowledged short I-frames -
> rather than polling to see if the other station got them, it just
> retransmits them verbatim.  I believe that this can cause a connection
> to hang forever, if it occurs when transmitting to a buggy TASCO modem,
> since the TASCO will never voluntarily acknowledge the short frame since
> there's no P/F bit set on it.
>
> So... it would be nice if JNOS could (perhaps optionally/selectively)
> set the P/F bit on the last I-frame in each sequence it sends. That
> would fix the bug with TASCO modems (which I believe are used in quite a
> few Kenwood radio models) and would probably increase the speed of
> transfers to other TNCs by eliminating the need for a T2 timeout during
> each send-and-acknowledge cycle.
>
> I'll spend a bit more time looking at how the AX25/LAPB code in JNOS
> handles the transmission of I-frames, and see if I can come up with a
> possible fix [snip] ..
>
> Best regards,
>
>     Dave AE6EO
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/nos-bbs_lists.tapr.org

-- 
There is nothing permanent except change
  
                                 Heraclitus