The TCP connection and port 23

Telnet does not move bytes across the network itself. It sits on top of TCP and lets TCP do the transport work: delivery, ordering, retransmission. What Telnet adds is meaning. Terminal semantics layered over a reliable byte pipe.

A Telnet session uses one TCP connection, and that connection is full duplex: both sides can send at the same time. Terminal data and Telnet control information travel through the same byte stream, in both directions. There is no second connection for control traffic. That choice has consequences we will get to in a later lesson.

Port 23

A Telnet server traditionally listens on TCP port 23. The client uses a temporary local port, picked by the operating system. So the complete connection is identified by both addresses and both ports:

client 192.0.2.10:53144 -> server 192.0.2.20:23

That four-part identifier is why a server can hold sessions with many clients at once, and even several sessions from the same client machine. Each one differs in at least the client port.

You can see the two endpoints of a live connection from the client side:

ss -tn | grep :23

ESTAB  0  0  192.0.2.10:53144  192.0.2.20:23

Port 23 is a convention, not part of the protocol grammar. A Telnet server can listen elsewhere, and a Telnet client can connect to any TCP port. That second half is the interesting one. It is what turns the client into a general tool for poking at text protocols, and you will do exactly that later in this course.

Connected is not working

A completed TCP handshake proves one thing: something accepted the connection. It does not prove that the service speaks Telnet, that your login will work, or that the session is safe.

This sounds obvious. It gets forgotten constantly. Connected to 192.0.2.20 means a process on that machine accepted a TCP connection on that port. It could be a Telnet server. It could be an HTTP server someone started on the wrong port. It could be a firewall’s decoy.

Keep the layers separate when you reason about failures. “Can I reach the port?” is a TCP question. “Does the service behave?” is an application question. The whole troubleshooting module of this course is built on telling those two apart.