Telnet "wont echo" is supressed by windows machines [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.

Closed 8 years ago.

Improve this question

In my code for telnet client, I want to echo always. So I will send wont echo to the server.

Linux machines obey the command, but windows machines suppress the wont command and send do echo command instead [confirmed from wireshark and GDB].

What could be the possible reason?

Answer 1

If I understand correctly, WILL and WONT indicate the "local" state. If you want the other party to switch to another mode, you have to send a DO or DONT command.

So, I guess you have to sent a "WILL ECHO", and "DONT ECHO" (meaning: I will perform the echo, so you don't have to echo).

Maybe this document will help:

The Q Method of Implementing TELNET Option Negotiation: https://www.rfc-editor.org/rfc/rfc1143

Answer 2

In my code for telnet client, I want to echo always. So I will send wont echo to the server.

That's wrong for a start. If you will echo, you need to send DONT echo. WILL/WONT is a response, not a request. And in any case if you want to echo why would you say you won't? It doesn't make sense.

Linux machines obey the command

It's not a command, it's a request. The server is free to agree or disagree. If the server disagrees it will send you the opposite WILL/WONT response. If it agrees it will send you an agreeing WILL/WONT response.

but windows machines suppress the wont command and send do echo command instead [confirmed from wireshark and GDB].

That's what you want! You want to echo, and it is telling you to echo. You got it wrong in the protocol but the end result is exactly as you wished.

Note: to avoid loops, if the peer had already sent a WILL/WONT response before you sent your DO/DONT, it won't send you the same message after it receives yours, if it now agrees with you. This can happen when either side initially disagrees. Again see the Telnet RFCs. You particularly need to read the one about how to implement this feature ('Q method').