[nos-bbs] 2.0j.7v + bleeding + forward.c test summary

[Michael Fox - N6MEF]

Maiko and all:

 

I've tested everything I can think of related to JNOS 2.0j.7v + bleeding
edge + forward.c updates.  Following is a summary.  For the issues found, I
included a suggested solution.  This is not to be presumptuous, but to help
clarify the issue and because I hate it when folks only list problems and
don't suggest a solution.  Maybe there's an even better solution for each
issue than what I suggested.  If so, great!

 

Michael

N6MEF

 

Fixed:

 

JNOS is now able to forward compressed FBB over telnet with FBB.  FBB
settings of up to "N 15" were tested.  JNOS settings of "mbox fbb 2" and
"mbox fbb 3" were tested.

 

Expire future no longer prematurely expires messages received via BBS
forwarding.

 

 

Issues found:

 

Issue noted by Maiko:  Default behavior of handling IAC breaks forwarding
with legacy JNOS, BPQ and possibly other BBSs.  Another one is probably
N0ARY.  I no longer use telnet forwarding with N0ARY, but I used to, before
the IAC fix.  So the use of IAC may break that.

Suggestion by Bob Tenty:  Make no IAC the default behavior and add "mbox
useiac <callsign>" for bi-directional control if IAC.

 

Issue:  JNOS displays inconsistent SID.  With "mbox fbb 2", JNOS displays
only "BF" (FBB binary compression v0) for incoming connections.  But on
outgoing connections, if the remote end displays "B1F" (FBB binary
compression v1), then JNOS also shows "B1F".  

Suggestion:  Make JNOS SID consistent.  When set to "mbox fbb 2", if JNOS
can do B1F, then show B1F on incoming connections.  If JNOS cannot do B1F,
then don't show B1F on outgoing connections.

 

Issue:  On incoming sessions (remote BBS connects to JNOS), JNOS telnet
sessions hang if the remote end sends only a CR at the end of a command
because JNOS waits for the LF.  After 5 minutes (typical timeout interval),
the remote end gives up.

Suggestion:  Make JNOS more tolerant of end-of-line differences.  Perhaps
accept either CR or CRLF.  Or else make the "cronly" option (currently in
forward.bbs) apply to both incoming and outgoing connections.  For example:
"mbox cronly <callsign>"

 

Issue:  "!" in forward.bbs only works on outbound connections.  It would be
preferable to turn of compression in both directions for a remote BBS that
doesn't handle it well.

Suggestion:  Instead of "!" in forward.bbs, perhaps add:  "mbox nocmp
<callsign>"

 

Issue:  some error messages in nos.log do not include the connection info
(<ipaddr>:<port>) or the MBOX (<callsign>) info.  This makes them harder to
correlate when multiple connections are happening at the same time and it
makes them harder to find with common tools like grep.

Suggestion:  Add connection info and MBOX info to "fbb protocol error"
messages.  Add MBOX info to "lzhuf: . " error messages.

 

Issue:  JNOS sometimes quits a forwarding session prematurely.  Nos.log does
not display a reason.

Suggestion:  Have JNOS log the reason it needs to quit early so we can
understand and fix the problem.

 

Issue:  "!" in forward.bbs only works on outbound connections.  We need a
way to turn of compression in both directions for a remote BBS that doesn't
handle it well.

Suggestion:  Instead of "!" in forward.bbs, perhaps add:  "mbox nocmp
<callsign>"

 

Issue:  FBB binary compression (mbox fbb 2) works for inbound BPQ to JNOS
forwarding, but does not work for outbound JNOS to BPQ forwarding.

Suggestion:  None yet, until we can get more information on what the exact
problem is.  This is the lowest priority for me.  According to one BPQ user,
telnet forwarding is not used much and may not be compatible.  AXUDP is
preferred.  I will be switching to AXUDP for my BPQ link.  But I can wait
and leave telnet in place while this work on telnet is ongoing, if that is
helpful.

 

END

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20160420/bf4cf287/attachment.html>