I recently found out that JNOS is not B1F ready. It never was. If JNOS saw that
the SID of other station contained a B1F, it would actually ignore the '1' and
treat the connection as just plain old BF. Before B2F was implemented in JNOS,
this was not really a problem that I'm aware of. However, it can become a big
problem if you have B2F defined and in use on your JNOS 2.0i system.

B1F is FBB compressed forwarding version 1, BF is only version 0. They are not
the same, contrary to what others might say. Check the specification below :

     http://www.f6fbb.org/protocole.html

The B1F protocol contains an extra checksum and length data. So responding to
a system that expects B1F, but with BF format instead creates a big mess.

From a practical point of view, this problem goes something like this :

   "for a while now I have been forwarding with an xfbb (or other) system
    quite nicely, everything is working well. JNOS does the connect, and
    starts the forward process each time."

   "today it was decided to allow the other system to connect and initiate
    forwarding when it can. The result was a big mess. Messages coming in
    would be decoded and stored as garbage text, size in Megabytes, not the
    usual one or two kilobytes I expect a message to be. The system would
    lock up, the hard drive would be going full blast for several minutes,
    and the CPU usage was through the roof (intense) during forwarding.

One solution (for now) is IF you have B2F defined in your JNOS compile, in
other words you have a B2F ready system, then you MUST identify B1F capable
forwarding partners that most likely do not support the B2F protocol, ie :

   #
   # MY AUTOEXEC.NOS - I connect to a local RMS packet node, so I need
   # my default mbox level to be B2F (3) - new level in later releases.
   #
   mbox fbb 3
   #
   # here is a list of my forwarding partners
   # ve4bbs is running an older FBB 7.0 system, B2F not supported
   #
   mbox nob2f ve4bbs

Better yet, if you have no intention of ever using JNOS 2.0 with RMS or
Winlink stuff, then just #undef B2F and recompile JNOS from scratch, which
is probably the easier way to get rid of the *headache* mentioned above.

More analysis on this issue, a post I sent to NOS-BBS
-----------------------------------------------------

Okay, I think I know what is going on here. If you look carefully in the
code, JNOS never did support B1F, only BF. Up until the B2F showed up, JNOS
never had a problem dealing with xfbb or winfbb systems and others
that connected with a B1F in the their SID. Since JNOS never supported
it, it would always return the lower BF and everything was fine.

What happens if winfbb connects to a B2F enabled JNOS ? Well, it will
receive a SID that contains B2F. The winfbb system will send B1F back
to the JNOS and expect JNOS to continue with B1F. The problem here is
JNOS does NOT support B1F, it never did ! It ignores the '1', treating
the response as a plain old BF (FBBCMP version 0).

That becomes a problem. Version 1 has extra checksum and length info,
so sending Version 0 format to a system expecting Version 1 results in
the big mess mentioned in previous emails.

That is why I added the 'mbox nob2f option', to deal with systems that
are sending B1F SIDs to B2F enabled JNOS systems. In fact, I believe now
that if B1F is not supported, then JNOS should terminate the connection
at that point, since the lower denominator in the initial exchange is
simply not possible.

I will get this fixed, and add B1F support as soon as I can.

January 20, 2011

by Maiko Langelaar / VE4KLM