Have a question for the telnet gurus out there. Trying to get to the bottom of why file transfers (using any serial based protocol) don't work on my OS/2 SIO based BBS nodes via a double telnet.

Tried this with Mystic in front and GameSrv (TelnetDoor) in front and seeing the same problems. File transfers will error out no matter which one you select.

If I telnet directly to the nodes, file xfers work just fine. It is just in the "double telnet" setup that the file xfers fail.

Was wondering if anyone has any ideas on why that is the case and if there is a way around the problem?

Thanks!

- Mark

--- WWIVToss v.1.52
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

Re: Question for telnet/BBS gurus.
By: Mark Hofmann to All on Wed Jun 17 2020 18:04:50

If I telnet directly to the nodes, file xfers work just fine. It is just in
the "double telnet" setup that the file xfers fail.

do you mean like telnetting from one system to another and then downloading and expecting it to cross both telnet hops?

if yes, i would first be looking at the connection between the two servers and seeing if it is a binary capable stream or not... if it is not, is there an attempt to switch it to being so? whatever the client passes to the
first server might should also be passed to the second server so channel switches like this can take place...

if this switching is being sent to the first server but not passing on to the second one, well... i dunno... could be a security thing or just a defect... or maybe even a policy thing... more research is needed ;)


)\/(ark
--- SBBSecho 3.11-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Re: Question for telnet/BBS gurus.
By: Mark Hofmann to All on Wed Jun 17 2020 06:04 pm

Have a question for the telnet gurus out there. Trying to get to the bottom of why file transfers (using any serial based protocol) don't work on my OS/2 SIO based BBS nodes via a double telnet.

It would probably be because one of the (telnet) streams (or both), are not put into "binary mode" - and thus the telnet client or server is interpreting some of the binary chars that would be sent.

As per the wikipedia:
https://en.wikipedia.org/wiki/Telnet

"Another difference between Telnet and other TCP terminal clients is that Telnet is not 8-bit clean by default. 8-bit mode may be negotiated, but octets with the high bit set may be garbled until this mode is requested, as 7 bit is the default mode."

...δεσ∩

... Where there's a will, there's a lawsuit.
--- SBBSecho 3.11-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

do you mean like telnetting from one system to another and then
downloading and expecting it to cross both telnet hops?

if yes, i would first be looking at the connection between the two
servers and seeing if it is a binary capable stream or not... if it is
not, is there an attempt to switch it to being so? whatever the client passes to the first server might should also be passed to the second
server so channel switches like this can take place...

Basically, yes. Where one program accepts the telnet and then performs another telnet to another application.

The wildcard here is the second destination is running Raymond Gwinn's SIO drivers (telnet emulation for serial ports). Transfers work fine over telnet if you go directly to the nodes running SIO. It is only the "double telnet" situation where the downloads don't work.

Figure it has something to do with telnet control codes/binary mode or something. The xfers will start but get lots of errors and eventually terminate.

- Mark

--- WWIVToss v.1.52
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

It would probably be because one of the (telnet) streams (or both), are
not put into "binary mode" - and thus the telnet client or server is interpreting some of the binary chars that would be sent.

If telnet xfers work without the double telnet situation, could that still mean both streams could be an issue?

Not 100% sure, but the only reports I'm aware of this happening is when using the SIO drivers as the second destination. They work fine as the first destination.

Since there is no way to make changes to SIO these days, hoping there is another way to get this working.

- Mark

--- WWIVToss v.1.52
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

Tried this with Mystic in front and GameSrv (TelnetDoor) in front and seeing th
same problems. File transfers will error out no matter which one you select.

To add to what Mark and Deon said... from experience, the Mystic matrix as
a front-end for telneting to another board does not create a binary
connection. You won't be able to do file transfers from the BBS that
Mystic is transfering the connection to.

I have not tried GameSrv.

Mike


* SLMR 2.1a * STRING space corrupt? But I always use TAPE!
--- SBBSecho 3.11-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)

Re: Re: Question for telnet/BBS gurus.
By: Mark Hofmann to Deon George on Thu Jun 18 2020 09:06 am

If telnet xfers work without the double telnet situation, could that still mean both streams could be an issue?

Yes - if one of the streams doesnt negotiate 8bit binary mode.

So if you have:

A <---> B B <---> C

So "B" is both a client and a server (or a server running a client telnet).

If "C" says "lets go binary", the "B client" probably says "OK", but it probably doesnt tell the "B server" to negotiate binary mode with "A".

...δεσ∩

... MONEY TALKS...but all mine ever says is GOODBYE!
--- SBBSecho 3.11-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

To add to what Mark and Deon said... from experience, the Mystic matrix
as a front-end for telneting to another board does not create a binary connection. You won't be able to do file transfers from the BBS that
Mystic is transfering the connection to.

I have not tried GameSrv.

I tried GameSrv (TelnetDoor) and had the same issue so it must not be creating a binary connection, either. It wasn't clear as to just being a "double telnet" related issue or something else.

It sounds like the way to get this working would be to have whatever sits in front that accepts the 1st inbound telnet - have it initiate an outbound binary telnet connection to the second host.

- Mark

--- WWIVToss v.1.52
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

A <---> B B <---> C

So "B" is both a client and a server (or a server running a client
telnet).
If "C" says "lets go binary", the "B client" probably says "OK", but it probably doesnt tell the "B server" to negotiate binary mode with "A".

Is there any harm to always forcing a binary connection for telnet? That way it would be covered either way? Not sure what effect that would have on regular text.

- Mark

--- WWIVToss v.1.52
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

I tried GameSrv (TelnetDoor) and had the same issue so it must not be creating a binary connection, either. It wasn't clear as to just being
a "double telnet" related issue or something else.

There is no such thing as "creating a binary connection" via telnet.

Telnet options are negotiated after the connection. Binary mode is something the server would request and the client would respond to.

One way to test Mystic specifically is if you use the outbound telnet to connect to your own Mystic BBS again. The transfers still work even when you connect through multiple telnet connections. I just tested that again in the latest Windows build and the transfers were working fine with NetRunner
Zmodem.

--- Mystic BBS v1.12 A46 2020/06/11 (Windows/64)
* Origin: Sector 7 | Mystic WHQ (1:129/215)

Re: Re: Question for telnet/BBS gurus.
By: Mark Hofmann to Deon George on Fri Jun 19 2020 08:56 am

Is there any harm to always forcing a binary connection for telnet? That way it would be covered either way? Not sure what effect that would have on regular text.

During a telnet session, the server and client exchange information on demand - "Telnet IAC", which you would loose if it was in a permanent binary session.

These IAC commands return cursor positions, echo mode, terminal info, etc...

...δεσ∩

... I've got Parkinson's disease. And he's got mine.
--- SBBSecho 3.11-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Re: Re: Question for telnet/BBS g
By: James Coyle to Mark Hofmann on Fri Jun 19 2020 12:10 pm

There is no such thing as "creating a binary connection" via telnet.

Well, I'm no expert, and it may come down to "interpretation of words" as to whether you "create a binary connetion" or you start a telnet session and turn on "binary mode".

But https://tools.ietf.org/html/rfc856 talks about Telnet Binary Transmission.

Thus, after connection, one side sends IAC DO TRANSMIT-BINARY, and the other side responds IAC WILL TRANSMIT-BINARY - and the session is now 8 bit right?

...δεσ∩

... There are always alternatives. Spock, The Galileo Seven, stardate 2822.3. --- SBBSecho 3.11-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Re: Re: Question for telnet/BBS gurus.
By: Deon George to Mark Hofmann on Sat Jun 20 2020 09:54 am

During a telnet session, the server and client exchange information on demand - "Telnet IAC", which you would loose if it was in a permanent binary session.

Actually, I was wrong here.

After a little more reading, the IAC codes are still "scanned", they just need to be doubled up to be acted on.

...δεσ∩

... Chuck Norris can divide by zero.
--- SBBSecho 3.11-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Telnet options are negotiated after the connection. Binary mode is something the server would request and the client would respond to.

One way to test Mystic specifically is if you use the outbound telnet to connect to your own Mystic BBS again. The transfers still work even when you connect through multiple telnet connections. I just tested that again in the latest Windows build and the transfers were working fine with NetRunner Zmodem.

Yes, doing a double telnet from Mystic back to Mystic and then doing a transfer works. That is the only example of the double telnet that works to my knowledge for transfers.

It apparently has something to do with the telnet negotiation process. Maybe other BBS platforms are sending the negotiation to just one of the telnet processes. Not sure, but it appears to have something to do with auto negotiation. Just trying to figure out if there is a way around this somehow.

- Mark

--- WWIVToss v.1.52
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

Actually, I was wrong here.

After a little more reading, the IAC codes are still "scanned", they just need to be doubled up to be acted on.

The other question would be when the telnet negotiation happens, is this for both telnet sessions in the double telnet situation or just the new one connecting?

- Mark

--- WWIVToss v.1.52
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

Re: Re: Question for telnet/BBS gurus.
By: Mark Hofmann to Deon George on Sat Jun 20 2020 09:31 am

The other question would be when the telnet negotiation happens, is this for both telnet sessions in the double telnet situation or just the new one connecting?

So the assumption I've been working on, is that by "double telnet", you actually mean "two telnet sessions" right?

If this is true, then each session negotatiates what happens on that session. So if one session wants to go 8 bit (to do binary transfers), the other session needs to do the same. But the problem that probably exists, is nothing is triggering the other session to do it...

...δεσ∩

... Diplomacy is the art of letting someone else have your way.
--- SBBSecho 3.11-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

So the assumption I've been working on, is that by "double telnet", you actually mean "two telnet sessions" right?

Yes, basically nested telnet sessions.

If this is true, then each session negotatiates what happens on that session. So if one session wants to go 8 bit (to do binary transfers),
the other session needs to do the same. But the problem that probably exists, is nothing is triggering the other session to do it...

Sounds very reasonable.

- Mark

--- WWIVToss v.1.52
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

Re: Re: Question for telnet/BBS gurus.
By: Deon George to Mark Hofmann on Sat Jun 20 2020 09:54 am

Re: Re: Question for telnet/BBS gurus.
By: Mark Hofmann to Deon George on Fri Jun 19 2020 08:56 am

Is there any harm to always forcing a binary connection for telnet? That way it would be covered either way? Not sure what effect that would have on regular text.

During a telnet session, the server and client exchange information on demand - "Telnet IAC", which you would loose if it was in a permanent binary session.

These IAC commands return cursor positions, echo mode, terminal info, etc...

Telnet binary mode has to do with the translation of received CR/LF and CR/NUL pairs to a single carriage-return character (0x0D) and nothing to do with the Telnet IAC character (0xFF) which must always be escaped and parsed correctly, always, binary mode or not.

digital man

Synchronet "Real Fact" #55:
Synchronet Terminal Server introduced RLogin support w/v3.00c (2000).
Norco, CA WX: 74.1°F, 66.0% humidity, 13 mph ENE wind, 0.00 inches rain/24hrs

Re: Re: Question for telnet/BBS gurus.
By: Rob Swindell to Deon George on Mon Jun 22 2020 07:32 pm

Telnet binary mode has to do with the translation of received CR/LF and CR/NUL pairs to a single carriage-return character (0x0D) and nothing to do with the Telnet IAC character (0xFF) which must always be escaped and parsed correctly, always, binary mode or not.

But isnt in telnet binary mode, 0xFF needs to be received twice consectively before the other end should interpret what should follow?

I must admit I havent read the finer details of how things are parsed when in it goes in this mode - but I assumed this mode assisted binary file transfers that are likely to have those special control chars that would normally be intepreted as IAC commands.

...δεσ∩

... Help a swallow land at Capistrano.
--- SBBSecho 3.11-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Re: Re: Question for telnet/BBS gurus.
By: Deon George to Rob Swindell on Tue Jun 23 2020 01:13 pm

Re: Re: Question for telnet/BBS gurus.
By: Rob Swindell to Deon George on Mon Jun 22 2020 07:32 pm

Telnet binary mode has to do with the translation of received CR/LF and CR/NUL pairs to a single carriage-return character (0x0D) and nothing to do with the Telnet IAC character (0xFF) which must always be escaped and parsed correctly, always, binary mode or not.

But isnt in telnet binary mode, 0xFF needs to be received twice consectively before the other end should interpret what should follow?

No. Only an actual 0xFF data byte needs to be escaped (by sending an IAC). This is true whether in binary mode or not.

I must admit I havent read the finer details of how things are parsed when in it goes in this mode - but I assumed this mode assisted binary file transfers that are likely to have those special control chars that would normally be intepreted as IAC commands.

No, Telnet binary mode only affects the interpretation of the CR/LF and CR/NUL byte pairs, which most definitely are likely to be contained in many/most file transfers and thus need to have binary mode enabled to be received correctly (e.g. for chksum/crc validation purposes, if nothing else).

digital man

Synchronet "Real Fact" #100:
You can leave a voicemail for The TechDorks (Stephen and I) at 951-523-7535. Norco, CA WX: 66.6°F, 82.0% humidity, 0 mph SE wind, 0.00 inches rain/24hrs

No, Telnet binary mode only affects the interpretation of the CR/LF and CR/NUL byte pairs, which most definitely are likely to be contained in many/most file transfers and thus need to have binary mode enabled to be received correctly (e.g. for chksum/crc validation purposes, if nothing else).

That appears to be what is happening in the case of the nested telnets when doing a file transfer (other than Mystic->Mystic).

The transfer will start, get CRC errors, and eventually abort.

Mystic->Syncronet, Mystic->WWIV, GameSrv(TelnetDoor)->WWIV seem to suffer from this when doing file transfers. What is likely happening is the "enable binary mode" is only going to the nested telnet and not both the nested and the original one.
- Mark

--- WWIVToss v.1.52
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)