Jump to content
  • Advertisement
Sign in to follow this  
Leo28C

Yet another question about Telnet

This topic is 4226 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone! Okay. I've been making some random Telnet programs until I found one I liked. They all work fine on Windows' Telnet client, but when I try PuTTY it won't work right (characters don't show, escape sequences show on screen, text appears disaligned, etc.) Many sites say to set options like ECHO on the client, but programs like NetHack work flawlessly on every client I've tried without having to set any options. How can I detect my terminal type? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
There are three ways:

1) Use the built-in OS services. On UNIX this works fine (for example, getenv("TERM"), or use termcap or terminfo).

2) Use a common identification sequence until you get back a known response. Send clear screen as soon after as you can.

3) Assume some common baseline, such as ANSI or VT-52 or possibly VT-100.

Share this post


Link to post
Share on other sites
1. So just send "getenv("TERM")\r\n" and it'll send me the terminal? What if I'm not on UNIX?

2. [noob alert] How? :-) [/noob alert]

3. What if they're on something else?

I think #2 is the one I need. Can you explain it to me, please? Thanks!

Share this post


Link to post
Share on other sites
No. getenv() is a function.

It would be helpful if you specified what kind of program you're trying to write. A telnet protocol client (like a MUD client)? A telnet protocol server program (like a MUD game)? Do you deal with telnet connections directly, or do you go through the host OS? A little more information is needed for us to help you.

Share this post


Link to post
Share on other sites
Quote:
Original post by Leo28C
They all work fine on Windows' Telnet client, but when I try PuTTY it won't work right (characters don't show, escape sequences show on screen, text appears disaligned, etc.)
Your server needs to respond to telnet negotiation. Windows telnet doesn't actually send anything, but PuTTY sends something like 21 bytes of telnet negotiation, which you should either drop or respond to. There's some RFCs about this somewhere (Google "Telnet RFC").

It's usually just a case of reading the first byte, and if it's 0xff (255), you can ignore the next two bytes. Responding to it requires understanding the negotiation strings.

No idea about the escape sequences appearing on screen - what escape sequences are you sending? As for the text appearing disaligned, are you terminating lines with "\r\n" instead of just "\n"?

Share this post


Link to post
Share on other sites
I'm making a protocol server program.

Isn't there a site that lists all popular Telnet clients and their specific options? The RFC's seem pretty old (1983?) and confusing...

I'm sending escape sequences like \x1b[A for moving my character around, however on PuTTY and Mac OS X telnet clients instead of moving the character it shows the string '\x1b[[A' (note the two brackets instead of just one, and replace the \x1b with a little left arrow).

I analyzed PuTTY's negotiation string and it does start with 0xff, but is followed by 34 more characters.

I want to support all Telnet clients. Why isn't there a standard?!

Thanks!

Share this post


Link to post
Share on other sites
Quote:
Original post by Leo28C
Isn't there a site that lists all popular Telnet clients and their specific options? The RFC's seem pretty old (1983?) and confusing...
Have a look on Google. The options should be the same for all clients, just the defaults may change (E.g. local echo on/off).

Quote:
Original post by Leo28C
I'm sending escape sequences like \x1b[A for moving my character around, however on PuTTY and Mac OS X telnet clients instead of moving the character it shows the string '\x1b[[A' (note the two brackets instead of just one, and replace the \x1b with a little left arrow).
I'd guess that PuTTY expects some sort of negotiation in order to use that correctly. I don't know what though.

Quote:
Original post by Leo28C
I analyzed PuTTY's negotiation string and it does start with 0xff, but is followed by 34 more characters.
Telnet negotiation strings are always 3 bytes long, if there's 35 characters then that's 11 and a bit strings (Are you sure it's not a multiple of 3 bytes in total?).

Quote:
Original post by Leo28C
I want to support all Telnet clients. Why isn't there a standard?!
There is. It's just different clients have different defaults.

Here's a bit of code from my own MUD, which logs 3 bytes of the negotiation, with a bunch of known commands:

static void LogTelnetNegotiation(const unsigned char* pData)
{
EStringstream str;
str << L"DEBUG : Client sends negotiation option \"";
switch(pData[1])
{
case 251: str << L"WILL "; break;
case 252: str << L"WON'T "; break;
case 253: str << L"DO "; break;
case 254: str << L"DON'T "; break;
default: str << L"Unknown(" << (int)pData[1] << L") "; break;
}

switch(pData[2])
{
case 0: str << L"BINARY"; break;
case 1: str << L"ECHO"; break;
case 3: str << L"SUPPRESS-GO-AHEAD"; break;
case 5: str << L"STATUS"; break;
case 6: str << L"TIMING-MARK"; break;
case 18: str << L"LOGOUT"; break;
case 20: str << L"DATA-ENTRY-TERMINAL"; break;
case 24: str << L"TERMINAL-TYPE"; break;
case 25: str << L"EOR"; break;
case 27: str << L"OUTPUT-MARKING"; break;
case 28: str << L"TTY-LOCATION"; break;
case 30: str << L"X.3-PAD"; break;
case 31: str << L"NAWS"; break;
case 32: str << L"TERMINAL-SPEED"; break;
case 33: str << L"REMOTE-FLOW-CONTROL"; break;
case 34: str << L"LINEMODE"; break;
case 35: str << L"X-DISPLAY-LOCATION"; break;
case 36: str << L"ENVIRONMENT-VARS"; break;
case 39: str << L"NEW-ENVIRONMENT-VARS"; break;
case 42: str << L"CHARSET"; break;
case 44: str << L"COM-PORT-CONTROL"; break;
default: str << L"Unknown(" << (int)pData[2] << L")"; break;
}

str << L"\"\n";
ELog::Get().DebugLog(str.str());
}


Every command is IAC (0xff), then WILL, WON'T, DO or DON'T, then a command. Have a look at the RFC for details of what these mean (WILL/WON'T means the client is telling the server something about itself, DO/DON'T is a request to [un]set an option I think - it's been a while since I did this stuff though).

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by Leo28C
I analyzed PuTTY's negotiation string and it does start with 0xff, but is followed by 34 more characters.
Telnet negotiation strings are always 3 bytes long, if there's 35 characters then that's 11 and a bit strings (Are you sure it's not a multiple of 3 bytes in total?).


No, that's a subnegotiation string, looking something like:

IAC SB TERMINAL-TYPE IS "vt100" SE


...where anything not quoted is a one-byte special character. To get the terminal type, you need to do the normal negotiation to check the feature's available, then send IAC SB TERMINAL-TYPE SEND IAC SE to request a terminal type string, and then look for subnegotiation strings like the above. You keep sending IAC SB TERMINAL-TYPE SEND IAC SE collecting strings until you get the first one again, at which point you continue to send until the last one it sends is the 'mode' you desire.

Speaking to the original poster: note that 99% of the time this shouldn't matter. You should be coding to the standard (and by the way, the fact that the RFCs are old is a good thing - that's because these standards are robust and don't change all the time) and then you'll find most compliant clients work properly. And if in doubt, if it doesn't work on PuTTy then your server is wrong, because PuTTy is far, far more standards compliant than Microsoft Telnet.

eg.
- What kind of characters don't show? Because anything that isn't ASCII is a control character, in theory.
- What 'escape sequences' are you using? Because they're part of the VT100/ANSI codes, which may not be the terminal mode you're operating in (though I've never had a problem with PuTTy not recognising these instantly, so you're probably sending them wrongly).
- Text appears disaligned - how are you aligning it? Telnet has no real concept of text alignment, though it's both possible to position the cursor on screen and to use tab characters (the width of which is client-specific)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!