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

['Gustavo Ponza']

All correct 100% Bob and naturally to Maiko again very TNX!

As per general information I want to participate to all
of you that, since this early morning I completely shut
down the gorgeous obcm and the xdfbb and remain in
full production with this last JNOS2 improve together
with the new entry test set, namely the emerging LinBPQ.

I'm puzzled of many data but can confirm that bpq at
VE3UIL is doing reverse forwarding in plain MBL/RLI style
toward the new I0OJJ-8 equipped by the 'bleed' JNOS2.

However, something obscure happens...:

12:40:13  I0OJJ-3 on port xnet - MBOX (ve3uil) reverse forwarding mail
12:40:13  I0OJJ-3 on port xnet - MBOX (ve3uil) proposal SB ALL @ WW < UT1HZM
12:40:17  I0OJJ-3 on port xnet - MBOX (ve3uil) sent $38970_ut1hzm
12:40:17  I0OJJ-3 on port xnet - MBOX (ve3uil) proposal SB ALL @ EU < I3XTY
12:40:17  - about to send ['Re:' is no command
]
12:40:17  - looks like sent [=>
]
12:40:17  I0OJJ-3 on port xnet - MBOX (ve3uil) sent $28243v_i3xty
12:40:17  I0OJJ-3 on port xnet - MBOX (ve3uil) proposal SB SATDIG @ WW < 
CX2SA
12:40:17  - about to send ['R:160417/1032z' is no command
]
12:40:17  - looks like sent [=>
]
12:40:17  I0OJJ-3 on port xnet - MBOX (ve3uil) sent $amsatbb11119
12:40:18  I0OJJ-3 on port xnet - MBOX (ve3uil) proposal SB SATDIG @ WW < 
CX2SA
12:40:18  - about to send ['R:160417/1029z' is no command
]
12:40:18  - looks like sent [=>
]
12:40:18  I0OJJ-3 on port xnet - MBOX (ve3uil) sent $amsatbb11120
12:40:18  I0OJJ-3 on port xnet - MBOX (ve3uil) proposal SB SATDIG @ WW < 
CX2SA
12:40:18  - about to send ['R:160417/1029z' is no command
]
12:40:18  - looks like sent [=>
]
12:40:18  I0OJJ-3 on port xnet - MBOX (ve3uil) sent $amsatbb11121
12:40:18  I0OJJ-3 on port xnet - MBOX (ve3uil) proposal SB KEPS @ AMSAT 
< CX2SA
12:40:18  - about to send ['R:160417/1028z' is no command
]
12:40:18  I0OJJ-3 on port xnet - MBOX (ve3uil) fwd exit
-------------------------


For not forget the problem: I noted that the forwarding
time rate of JNOS2 is about half an hour or a little more
and so too high for a normal operation,  I'd like that
Maiko introduce a *cron job* style feature for this need
and useful for other production PBBS routines.
A minimal msg editor on the console should be needed too.

For BPQ, if it functions, and as per my poor understanding,
the full compatibility with the JNOS2 should be reached
if the JNOS2 can fully use its TCPPORT which is claimed
as a real TCP connect... and NOT the so called FBBPORT
which was created by the author for the transparent TCP
connects, namely that used by the xdfbb forwarding :))
Then there is the dot (.) behind the caller... which is
understood only by the FBB systems, etc. ... but I just
speedy read ... and perhaps I can be confused :)

However Bob et al you may try if you want.

73, gus

On 04/19/2016 08:02 AM, Boudewijn (Bob) Tenty wrote:
> Make the default NOIAC (old behaviour) so that it still can 
> communicate with old jnos (and bpq?) installations
> over telnet.   Use "mbox  useiac callsign" (autoexec.nos)  for bbs 
> installations what use or can use IAC.
>
> Settings should be valid for in- and outgoing telnet sessions for that 
> particular bbs call. (This is important)
>
> No more extra options are needed in the forward.bbs.
>
> Everybody happy and it still works with old jnos installations and 
> winlink over telnet without any settings
> in the autoexec.nos.
>
> 73,
>
> Bob VE3TOK
>
>
> On 16-04-18 11:49 PM, Maiko Langelaar wrote:
>>
>> 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
>> _______________________________________________