C# Telnet服务端与Python telnetlib客户端登录对接异常排查

PuTTY连接正常、Python telnetlib对接失败是简易Telnet服务端的典型兼容问题，和登录业务逻辑无关，核心诱因共3点：

• Telnet IAC选项协商处理缺失：你找到的开源C# Telnet服务端属于极简实现，没有遵循RFC854规范处理协商流程。PuTTY自带兼容逻辑：发出协商请求后短时间没收到响应就自动降级为明文传输模式，不阻塞后续流程；但Python telnetlib会持续等待协商应答，甚至会把后续收到的用户名、密码提示文本解析为协商指令，导致read_until匹配不到提示关键字，流程卡死。
• 换行符规则不匹配：PuTTY按下回车时默认发送\r\n（CRLF，十六进制0x0D 0x0A）作为行结束标记，C#常用的StreamReader.ReadLine()可以正常识别该标记判定输入完成；但多数人写telnetlib客户端时直接调用write()发送用户名密码明文，末尾没加CRLF标记，服务端会一直等待行结束符，永远收不到完整提交内容。
• 回显指令逻辑缺失：密码输入阶段Telnet协议约定服务端需要发送IAC指令关闭客户端本地回显，你的服务端没实现该逻辑时，部分版本的telnetlib会持续等待回显控制指令，甚至过滤掉后续发送的密码字节，导致服务端收不到密码。

快速验证（改Python客户端，5分钟定位） #

先修改客户端代码，跳过协商等待、显式补充行结束符，能直接验证是不是上述问题：

import telnetlib

tn = telnetlib.Telnet(host="127.0.0.1", port=23, timeout=10)
# 清空连接初期收到的协商垃圾字节
tn.read_very_eager()

# 等待用户名提示，编码和服务端保持一致即可，多数场景为utf8或gb2312
tn.read_until(b"Username: ", timeout=5)
# 注意末尾必须加\r\n，不要只加\n
tn.write(b"your_login_name\r\n")

tn.read_until(b"Password: ", timeout=5)
tn.write(b"your_login_pwd\r\n")

# 读取登录后返回结果
print(tn.read_all().decode("utf8", errors="ignore"))

运行后如果能正常完成登录，就可以确认是协商和换行符导致的兼容问题。

长期修复（改C#服务端，兼容所有Telnet客户端） #

在Client.cs的数据接收入口加IAC协商处理逻辑，不要把协商字节当成业务文本处理：

// 收到客户端数据后先判断是否为IAC协商序列（协商字节固定以0xFF开头）
if (receiveBuffer[0] == 0xFF)
{
    // 构造WONT响应，拒绝所有客户端发起的协商请求，直接进入明文传输模式
    byte[] rejectResponse = new byte[] { 0xFF, 0xFC, receiveBuffer[2] };
    networkStream.Write(rejectResponse, 0, rejectResponse.Length);
    // 跳过当前包的后续处理，不要把协商内容传给业务逻辑
    return;
}

同时把服务端的行读取逻辑做兼容，支持识别\r、\n、\r\n三种换行格式，覆盖不同客户端的换行实现差异。

排查时直接在C#服务端的数据接收位置打日志，把收到的所有字节转十六进制打印：

• 如果收到的用户名字节末尾没有0x0D 0x0A，就是客户端没提交正确的行结束符
• 如果连接刚建立就收到连续的0xFF开头的字节序列，就是telnetlib发送的协商包，服务端未做处理
• PuTTY连接时收不到这类0xFF开头的包，是因为PuTTY探测到服务端不支持协商后自动停止发送协商请求，这就是PuTTY能正常连接的核心原因。

内容的提问来源于stack exchange，提问作者aasdfw asdasczdc