[nos-bbs] telnet sessions occasionally hang

[Michael Fox - N6MEF]

Maiko,

I'm trying to track down an occasional hang of the telnet session.  So far,
I can't reproduce it with any regularity so I'm gathering more data.  But in
the process of trying to understand the cause of the hang, I've been
investigating the behavior of "cronly".

Following is a summary of the behavior observed directly in telnet sessions.
Can you confirm that this is the intended behavior?  

When "cronly" is *NOT* added to the "tcp <host> <port>" line in forward.bbs,
then:
- JNOS will terminate each telnet line with CRLF (\x0d\x0a)
- JNOS expects each incoming telnet line to be terminated with CRLF.
- If the remote BBS sends a line ending only in CF (not CRLF), then JNOS
waits for the LF.  The session eventually times out.

When "cronly" *IS* added to the "tcp <host> <port>" line in forward.bbs,
then the behavior differs for inbound vs. outbound connections.
Specifically:

For outbound connections (JNOS telnets *TO* the remote BBS):
- JNOS will terminate each line with only CR (not CRLF).
- JNOS accepts either CR or CRLF at the end of each line sent by the remote
BBS.

For inbound connections (JNOS accepts a telnet session *FROM* the remote
BBS):
- JNOS will terminate each line it sends with CRLF (\x0d\x0a).  That is,
cronly does not affect the line termination used by JNOS on inbound
connections.
- JNOS *usually* accepts either CR or CRLF at the end of each line sent by
the remote BBS.  But sometimes it hangs on just CR.

Except for the hang, is that your understand of how "cronly" is intended to
work?


Also, here are a couple of examples of the hang.  They *seem* to only occur
on inbound connections (telnet *to* JNOS).

JNOS is configured with "cronly", but this is an *INBOUND* connection.
Notice in the second to last line in each case, FBB terminate the line with
just CR.  JNOS hangs.  After 5 minutes, FBB sends a timeout message and
disconnects.

Date/Time					Src	Dst	Telnet Data
Field

Apr 17, 2016 03:30:37.007642000	N6MEF	n6rme	\x0d\x0a,JNOS
(n6mef.ampr.org)\x0d\x0a,\x0d\x0a,login: 
Apr 17, 2016 03:30:37.090106000	n6rme	N6MEF
N6RME\x0d\x0a,bD9fZb91{4\x0d\x0a
Apr 17, 2016 03:30:37.090519000	N6MEF	n6rme	Password: 
Apr 17, 2016 03:30:37.112174000	N6MEF	n6rme
\x0d\x0a,[JNOS-2.0j.7v.XSC32.3-BFHIM$]\x0d\x0a,>\x0d\x0a
Apr 17, 2016 03:30:37.194550000	n6rme	N6MEF
[FBB-7.05f-ABFHM$]\x0d\x0a,FA B UT1HZM WW DXNEWS 425CAL1302 12393\x0d\x0a,FA
B C
Apr 17, 2016 03:30:37.215873000	n6rme	N6MEF	X2SA WW EQUAKE 42343-CX2SA
1664\x0d\x0a,FA B UT1HZM WW DXNEWS 425WW1302 
Apr 17, 2016 03:30:37.244896000	n6rme	N6MEF	13225\x0d\x0a,F> 35\x0d\x0a
Apr 17, 2016 03:30:37.251549000	N6MEF	n6rme	FS +-+\x0d\x0a
Apr 17, 2016 03:30:37.403348000	n6rme	N6MEF	\x01\"425 DX News #1302
Calendar
Apr 17, 2016 03:30:37.424911000	n6rme	N6MEF	g\xa3\xba\xd7\[binary data
clipped - let me know if you need to see it]
Apr 17, 2016 03:30:37.988935000	N6MEF	n6rme	FF\x0d\x0a
Apr 17, 2016 03:30:38.156983000	n6rme	N6MEF	FA B UT1HZM WW ALL
38970_UT1HZM 1747\x0dF> 14\x0d
Apr 17, 2016 03:35:38.053429000	n6rme	N6MEF	*** Timeout !!\x0d


Apr 17, 2016 09:00:19.459071000	N6MEF	n6rme	\x0d\x0a,JNOS
(n6mef.ampr.org)\x0d\x0a,\x0d\x0a,login: 
Apr 17, 2016 09:00:19.539719000	n6rme	N6MEF
N6RME\x0d\x0a,bD9fZb91{4\x0d\x0a
Apr 17, 2016 09:00:19.540163000	N6MEF	n6rme	Password: 
Apr 17, 2016 09:00:19.562336000	N6MEF	n6rme
\x0d\x0a,[JNOS-2.0j.7v.XSC32.3-BFHIM$]\x0d\x0a,>\x0d\x0a
Apr 17, 2016 09:00:19.645315000	n6rme	N6MEF
[FBB-7.05f-ABFHM$]\x0d\x0a,FA B KB8NW WW DX OPDX.1262 26776\x0d\x0a,F>
76\x0d\x0a
Apr 17, 2016 09:00:19.648080000	N6MEF	n6rme	FS +\x0d\x0a
Apr 17, 2016 09:00:19.886138000	n6rme	N6MEF	\x01&Ohio/Penn DX Bulletin
No. 1262
Apr 17, 2016 09:00:19.907888000	n6rme	N6MEF	N\xd6\x16/g\xa3[...binary
data clipped ...]
Apr 17, 2016 09:00:20.639920000	N6MEF	n6rme	FA B N1URO WW PACKET
16713_N1URO 2949\x0d\x0a,F>\x0d\x0a
Apr 17, 2016 09:00:20.808077000	n6rme	N6MEF	FS -\x0d
Apr 17, 2016 09:00:20.832261000	n6rme	N6MEF	FF\x0d
Apr 17, 2016 09:05:20.012732000	n6rme	N6MEF	*** Timeout !!\x0d

Michael
N6MEF