• Please review our updated Terms and Rules here

Telnet daemon that supports Brutman's MTCP telnet client

Zare

Zare

Veteran Member
Joined
Mar 12, 2015
Messages
639
Location
Croatia
Does seem like a redundant question but I'm unable to engage session against telnetd provided in FreeBSD ports. I'm getting some junk as prompt and no local echo on the client side. Was just about to debug the connection and the daemon but there's really no point. What I want to do is use old PC as a terminal, and there is a ton of BBSes and other public telnet stuff that works normally, so I just wanted to ask people what kind of telnet server is appropriate for this client.

Preferably that telnet server would be supported by a modern distro so I can use it as a workspace.
 
I kind of object to the wording of the subject ... the mTCP Telnet client is a generic telnet client and you don't need a special Telnet server to support it. I routinely test it against Linux, NetBSD, and various Telnet BBSes. I'm pretty sure I've even used it against an AS/400.

Some questions
  • Are you using the standard telnet port? (23)
  • Can you send me a packet trace when you run the mTCP Telnet client so I can see the Telnet options negotiation phase?
  • Do you have a machine I can test against remotely to see if there is something tragically broken

-Mike
 
Hello Mike and let me first apologize about the wording; I wanted to make the shortest and down to point post possible. I can see now that it can be wrongly interpreted. I never doubted that your software is not by specification because it's basically a miracle for modern DOS networking. If it's possible and under rules of the board I can rename the topic.

Yes the issue is probably with FreeBSD's telnetd that has been pulled out from base system into 3rd party packages in the current (14) version. I believe there's an issue with SPX. And I'm running it on high port (2300), not under inetd.
But I don't mind booting up a Linux VM instance and try out. I can send you all diagnostic info you want but it's 99.99% the freebsd-telnetd. You may also try it out for yourself.
 
And please forgive my thin skin .. it's too early in the morning here. ;-0

The Telnet client expects port 23. If you use a different port then the Telnet options negotiation code does not run. You can force it to run using a command line argument - use the "-sessiontype telnet" argument on the command line.

After that you'll probably want to set the LANG environment variable to something useful, especially if the system is using UTF-8. The mTCP Telnet client has some Unicode support but it has to be explicitly enabled; see the PDF documentation for the details.

And if none of that works, then please, send a trace along and let's find out what the problem is ...
 
:)

How so, when you have port 8086 running on your server for RLE show? I'm also sure I connected via "telnet host port" to BBSes I discovered on telnetbbsguide . But let me try that out.

P.S. I get a normal connection against telnet-server package on Rocky Linux 9, so this is most definitely about broken FreeBSD daemon.
 
Last edited:
That server I have running on port 8086 for the RLE graphics is not a legitimate Telnet server - it's not doing any Telnet options negotiation. Given that it is not on port 23, the mTCP Telnet client doesn't try to use Telnet options against it.

The general problem is that Telnet is an overloaded term. Strictly speaking, Telnet is a protocol and the Telnet options negotiation at the start determines echoing, 7 bit vs 8 bit, and many other behaviors. But you can use a Telnet client to connect to non-Telnet servers, which is basically just sending raw bytes similar to the way a computer sent bytes to a BBS over a serial connection.

The mTCP Telnet client lets you force real "Telnet" with options negotiations, or "raw" without that. You still get the same terminal emulation (ANSI color, cursor movement, etc.) but it allows for compatibility with both real Telnet servers or BBSes responding on TCP/IP at arbitrary ports.

Send a packet trace and let's see what that server is doing ... Intructions are in the debug section of the mTCP PDF documentation.
 
You must log in or register to reply here.
Back
Top