It's possible that the telnet support doesn't do anything with NVT CRs, I didn't dig in too deeply into the source, just noticed that it does do at leas
some option negotiation and will track the current state.

N/p, thanks for the tip nonetheless!

So likely you only need to do this if you need to accept or send character 255
(which is a special telnet character) such as for uploads and downloads.

That is *very* interesting. Since moving away from Vmodem / OS/2, putting
the DOS BBS behind any "proper" telnet server (like mystic's matrix menu) *breaks* file transfers, so apparently those don't necessarily do the right thing, either. ;)

I have it set up to be accessible via two ports. The primary allows folks
who have a terminal program capable of RAW mode to call in without the double-CR while also being able to do things like download a QWK packet.
The other port is behind a telnet server/listener that allows folks whose terminal program doesn't do RAW mode to call in and do just about
everything but transfer files.

Mike

* SLMR 2.1a * LSD: Virtual Reality without all the fancy hardware
--- SBBSecho 3.28-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)

Re: Re: Kannons and Katapults
By: Mike Powell to STEPHEN HURD on Sun Dec 07 2025 11:13 am

I have it set up to be accessible via two ports. The primary allows folks who have a terminal program capable of RAW mode to call in without the double-CR while also being able to do things like download a QWK packet.

To be clear, it's a CR LF, not a double-CR... but a lot of old software will interpret an LF as a CR, so it acts like a double-CR.

The other port is behind a telnet server/listener that allows folks whose terminal program doesn't do RAW mode to call in and do just about
everything but transfer files.

That is odd... a pcap would be elightening. Basically, for telnet, any IAC (character 255) needs to be converted to two IACs (ie: convert 0xFF to 0xFF 0xFF). Not doing that in one direction or the other is what the normal problem with file transfers over telnet ends up coming down to.
--- SBBSecho 3.32-FreeBSD
* Origin: BBSDev.net - The BBS Developers Network (1:103/1)

Re: Re: Kannons and Katapults
By: Stephen Hurd to Mike Powell on Sun Dec 07 2025 19:52:01

Re: Re: Kannons and Katapults
By: Mike Powell to STEPHEN HURD on Sun Dec 07 2025 11:13 am

I have it set up to be accessible via two ports. The primary allows folk who have a terminal program capable of RAW mode to call in without the double-CR while also being able to do things like download a QWK packet.

To be clear, it's a CR LF, not a double-CR... but a lot of old software will

I am a little leary to blame "old software" when the software itself has no issue interpreting the tap of the enter key as "one" return... CR or LF or whatever. It seems more like a case of syncterm, etc., sending an extra character when in telnet mode that older software -- i.e. most BBS software that isn't Synchronet or Mystic -- doesn't know what to do with.

That might be semantics but I it is odd that using an older terminal program over a telnet connection (with something like VMODEM) doesn't cause this, which makes me suspect it is the modern BBS terminal programs that have changed something. I am sure the answer is "cause telnet protocol" but since we are using these terminal programs to telnet into BBSes and not old VAX
or mainframe machines, I have to wonder who thought that was necessary.
--- SBBSecho 3.28-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)

Re: Re: Kannons and Katapults
By: Mike Powell to Stephen Hurd on Mon Dec 08 2025 09:10 am

Re: Re: Kannons and Katapults
By: Stephen Hurd to Mike Powell on Sun Dec 07 2025 19:52:01

Re: Re: Kannons and Katapults
By: Mike Powell to STEPHEN HURD on Sun Dec 07 2025 11:13 am

I have it set up to be accessible via two ports. The primary allows folk who have a terminal program capable of RAW mode to call in without the double-CR while also being able to do things like download a QWK packet.

To be clear, it's a CR LF, not a double-CR... but a lot of old software will

I am a little leary to blame "old software" when the software itself has no issue interpreting the tap of the enter key as "one" return... CR or LF or whatever. It seems more like a case of syncterm, etc., sending an extra character when in telnet mode that older software -- i.e. most BBS software that isn't Synchronet or Mystic -- doesn't know what to do with.

That's how the Telnet protocol is specified though. https://www.rfc-editor.org/rfc/rfc854:

"CR LF" or "CR NUL" is required in both directions
(in the default ASCII mode), to preserve the symmetry of the
NVT model. Even though it may be known in some situations
(e.g., with remote echo and suppress go ahead options in
effect) that characters are not being sent to an actual
printer, nonetheless, for the sake of consistency, the protocol
requires that a NUL be inserted following a CR not followed by
a LF in the data stream.

Note: there is no ASCII character for "the enter key", usually the enter key is represented by a single CR (^M, ASCII 13), but in the case of the Telnet protocol, it's not. When using Telnet and not in "binary transmit" mode, every CR character must be followed by either a NUL or an LF.

That might be semantics but I it is odd that using an older terminal program over a telnet connection (with something like VMODEM) doesn't cause this, which makes me suspect it is the modern BBS terminal programs that have changed something. I am sure the answer is "cause telnet protocol" but since we are using these terminal programs to telnet into BBSes and not old VAX
or mainframe machines, I have to wonder who thought that was necessary.

If the BBS doesn't actually support Telnet, then Telnet shouldn't be used.
--
digital man (rob)

Synchronet/BBS Terminology Definition #66:
RIP = Remote Imaging Protocol (e.g. RIPscrip)
Norco, CA WX: 82.0øF, 20.0% humidity, 0 mph NNE wind, 0.00 inches rain/24hrs --- SBBSecho 3.32-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: Kannons and Katapults
By: Mike Powell to Stephen Hurd on Mon Dec 08 2025 09:10 am

I am a little leary to blame "old software" when the software itself has no issue interpreting the tap of the enter key as "one" return... CR or LF or whatever. It seems more like a case of syncterm, etc., sending an extra character when in telnet mode that older software -- i.e. most BBS software that isn't Synchronet or Mystic -- doesn't know what to do with.

That's exactly what it is, but doing that is *required* by the telnet protocol under certain circumstances.

That might be semantics but I it is odd that using an older terminal program over a telnet connection (with something like VMODEM) doesn't cause this, which makes me suspect it is the modern BBS terminal programs that have changed something. I am sure the answer is "cause telnet protocol" but since we are using these terminal programs to telnet into BBSes and not old VAX
or mainframe machines, I have to wonder who thought that was necessary.

It's actually the other way around... the old things like VModem handled the telnet protocol and the door game didn't have to worry about it. Many modern doors however are being passed the socket itself and now the door needs to support the telnet protocol and every doorkit author needs to understand the telnet protocol instead of it being handled by the VModem and only the person who is setting out to write a telnet package needs to deal with the telnet protocol.

Having the door "speak" telnet when it is passed a socket also ends up causing issues when the BBS uses SSH instead of telnet because SSH is an 8-bit-clean protocol, so all of the telnet things that a door has to do, it has to not do for SSH.

Basically it's "cause door is being passed a raw socket and has to telnet protocol itself" instead of the much more sane "telnet server does telnet, door doesn't care".
--- SBBSecho 3.32-FreeBSD
* Origin: BBSDev.net - The BBS Developers Network (1:103/1)

Re: Re: Kannons and Katapults
By: Rob Swindell to Mike Powell on Mon Dec 08 2025 14:50:22

Hi, Rob.

"CR LF" or "CR NUL" is required in both directions
(in the default ASCII mode), to preserve the symmetry of the
NVT model. Even though it may be known in some situations
(e.g., with remote echo and suppress go ahead options in
effect) that characters are not being sent to an actual
printer, nonetheless, for the sake of consistency, the protocol
requires that a NUL be inserted following a CR not followed by
a LF in the data stream.

This finally explains why I kept triggering a bug on BeeBS a year or two ago - with CR -> CRLF disabled MuffinTerm was sending NULs after the CR and I could never work out why.

To be fair I didn't try that hard to work it out, I just switched CR -> CRLF on and Vela fixed the bug as well for good measure.

But, yeah - thanks for sharing :)

BobW
--- SBBSecho 3.32-Linux
* Origin: >>> Magnum BBS <<< - magnumbbs.net (2:250/3)

Re: Re: Kannons and Katapults
By: Bob Worm to Rob Swindell on Wed Dec 10 2025 10:25 pm

This finally explains why I kept triggering a bug on BeeBS a year or two ago - with CR -> CRLF disabled MuffinTerm was sending NULs after the CR and I could never work out why.

Glad that info helped!
--
digital man (rob)

Sling Blade quote #3:
Karl (re: killing Doyle): That second one just plum near cut his head in two. Norco, CA WX: 86.1øF, 18.0% humidity, 3 mph NW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.32-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)