Handling Telnet negotiation

Question

I'm trying to implement Telnet Client using C++ and QT as GUI. I have no idea to handling the telnet negotiations. Every telnet command is preceded by IAC, e.g.

IAC WILL SUPPRESS_GO_AHEAD

The following is how I handling the negotiation.

1. Search for IAC character in received buffer
2. According to the command and option, response to the request

My questions are described as follows:

1. It seems that the telnet server won't wait for a client response after a negotiation command is sent. e.g. (send two or more commands without waiting for client reponse)

   IAC WILL SUPPRESS_GO_AHEAD

   IAC WILL ECHO

How should I handle such situation? Handle two requests or just the last one?

2. What the option values would be if I don't response the request? Are they set as default?
3. Why IAC character(255) won't be treated as data instead of command?

Answer 1

1. Yes, it is allowed to send out several negotiations for different options without synchronously waiting for a response after each of them.

   Actually it's important for each side to try to continue (possibly after some timeout if you did decide to wait for a response) even if it didn't receive a reply, as there are legitimate situations according to the RFC when there shouldn't or mustn't be a reply and also the other side might just ignore the request for whatever reason and you don't have control over that.

   You need to consider both negotiation requests the server sent, as they are both valid requests (you may choose to deny one or both, of course).

   I suggest you handle both of them (whatever "handling" means in your case) as soon as you notice them, so as not to risk getting the server stuck if it decides to wait for your replies.

   One possible way to go about it is presented by Daniel J. Bernstein in RFC 1143. It uses a finite state machine (FSM) and is quite robust against negotiation loops.

2. A compliant server (the same goes for a compliant client) defaults all negotiable options to WON'T and DON'T (i.e. disabled) at the start of the connection and doesn't consider them enabled until a request for DO or WILL was acknowledged by a WILL or DO reply, respectively.

   Not all servers (or clients for that matter) behave properly, of course, but you cannot anticipate all ways a peer might misbehave, so just assume that all options are disabled until enabling them was requested and the reply was positive.

3. I'll assume here that what you're actually asking is how the server is going to send you a byte of 255 as data without you misinterpreting it as an IAC control sequence (and vice versa, how you should send a byte of 255 as data to the server without it misinterpreting it as a telnet command).

   The answer is simply that instead of a single byte of 255, the server (and your client in the opposite direction) sends IAC followed by another byte of 255, so in effect doubling all values of 255 that are part of the data stream.

   Upon receiving an IAC followed by 255 over the network, your client (and the server in the opposite direction) must replace that with a single data byte of 255 in the data stream it returns.

   This is also covered in RFC 854.