[nos-bbs] the 'noiac' or 'useiac' can of worms ...

Maiko Langelaar maiko at pcs.mb.ca
Mon Apr 18 23:49:52 EDT 2016


By introducing the IAC code into the telnet forwarding portion of JNOS I
have changed the default behavior of JNOS. For incoming telnet forwards,
JNOS will now enforce IAC manipulation, there is no way to turn that off
for particular incoming connections.

All nice and dandy if you're obcm (?) and linfbb, but not great if you
are BPQ (by the sounds of it) and other JNOS systems :) Before the new
IAC manipulation code, obcm (?) and linfbb are the ones that suffer, the
rest seem to be fine. Either way, some software systems will have issues
with the IAC stuff.

So should we stick to no IAC processing to keep the default behavior
intact and have a USEIAC option instead of NOIAC option ? Either way
I will have to have some type of command to flag telnet forwarding
from specific callsigns logging in, maybe something like :

      mbox useiac ve3tok
or
      mbox noiac bpqjoe ...

One problem (from my perspective) is that new JNOS will try and telnet
forward to an older JNOS that can't handle the IAC manipulation. So now
I am forced to make sure I specific noiac in my telnet forwards to other
JNOS systems. JNOS worked without it, so really both sides should not be
using IAC if you catch my analysis.

It's clear that some software is enforcing IAC manipulation, while other
software could not care, so there's your can of worms ...

To reiterate, the latest bleeding code that has the 'noiac' option, this
only applies for outgoing telnet forwards, not incoming.

Also to reiterate, JNOS default behavior now treats compressed 0xff as
an IAC where before it didn't. Do people see a problem here ? Comments ?

Please give it some serious thought, don't reply right away (I'm going to
sleep anyways, it's late, I'm tired, and I'm not checking my email for a
couple of days anyway).

Maiko



More information about the nos-bbs mailing list