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 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)

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)

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)