Every so often, a familiar question shows up in technical communities: the device on hand has nothing but an RS232 port — perhaps the console of an aging industrial PC, a measuring instrument, or the console port of a rack switch — while the maintenance computer sits somewhere else on the site. The goal is always the same: get the RS232 device onto the local area network, then open a terminal session from any PC on that LAN with Tera Term or PuTTY, typing commands and reading responses as if standing right in front of the equipment.
The standard answer to this problem is an RS232 to Ethernet converter (also called a serial device server): a palm-sized box with a serial connector on one end and an Ethernet port on the other, wrapping RS232 data into TCP packets that travel across the LAN. The device itself needs no code changes whatsoever.
Before touching any hardware, decide which software route to take — this determines every configuration step that follows.
Route one: direct TCP access.The converter runs in TCP Server mode and listens on a port within the LAN. PuTTY and Tera Term both speak TCP natively, so no extra software is needed on the PC. In PuTTY, choose Raw or Telnet as the connection type and enter the converter's IP address and port; in Tera Term, create a new connection with the TCP/IP option, pick Telnet or Other as the service (Other is plain raw TCP), and enter the same address and port. Open the connection and a transparent serial terminal appears.
Route two: virtual COM port.If the software on the PC only recognizes local COM ports — a fair number of long-established SCADA packages and device configuration tools work exactly this way — install virtual COM software instead. It creates a virtual COM port in the operating system, with the data silently travelling over the network to the converter. From the software's point of view, the device is plugged straight into a local serial port, and not a single line of the program changes.
Step 1, wiring.RS232 needs three lines: TX, RX, and GND. The converter's TX connects to the device's RX, and RX to TX — crossed over. This is the most common failure point, and the symptom is distinctive: the connection looks perfectly fine, yet commands get no response.
Step 2, parameters.Open the converter's built-in web configuration page in a browser (the default IP is in the manual) and do three things. First, match the serial parameters to the device exactly — baud rate, data bits, parity, and stop bits all have to line up; a mismatched baud rate turns the terminal into a wall of garbled characters. Second, set the working mode to TCP Server. Third, note the listening port number; defaults typically sit somewhere around 4001.
Step 3, the session.In PuTTY, select Raw as the connection type, enter the IP and port, and click Open. In Tera Term, choose a TCP/IP connection and enter the same address and port. Once commands can be typed and responses come back, the link is up.
One advanced detail worth knowing: when a device's serial parameters change often, a converter supporting RFC2217-style protocols allows baud rate, stop bits, and other settings to be modified remotely within the TCP session — no trip to the equipment rack required.
A word on network addressing, since it saves troubleshooting later: a converter that will be reached by IP address deserves a stable IP. Either assign a static address in the web configuration page, or reserve an address for it in the DHCP server, so the address in the saved PuTTY session never silently changes after a power cycle. The web page also shows the connection status and traffic counters, which makes it the first place to look when a session suddenly goes quiet.
Experience from field deployments points to three checks that settle most ordering mistakes in advance. First, pull the exact serial parameters from the device's label or manual before ordering anything — baud rate, data bits, parity, stop bits, and the connector type, whether it is a DB9 or a terminal block. Converters ship with different connectors, and adapters in the wiring path are one more thing that can go wrong. Second, look at who needs access and with what software: a PuTTY or Tera Term user only needs direct TCP access, while software that insists on a local COM port calls for the virtual COM route. Third, count the devices. A cabinet with one console port is a one-port job, but a site mixing an RS232 console and RS485 sensors is better served by a dual-port box than by two separate converters.
One device, pure terminal access — USR-TCP232-302.A single RS232 port with virtual COM support, heartbeat packets, and the ability to change serial parameters dynamically over the network-side protocol. One box per device makes this the lowest-cost option.
Tight spaces, several people watching — USR-DR132/DR134.A lipstick-sized DIN-rail body with push-type pluggable terminals, so wiring needs no screwdriver. In TCP Server mode it supports multiple simultaneous TCP client connections, holding up even when several people keep terminals open on the same device at once. RS232 and RS485 interface versions are available, chosen to match the device.
Terminal access plus data collection — USR-TCP232-410s.Its RS232 and RS485 ports work simultaneously, with a baud rate range of 600 to 230.4 kbps. It carries a Modbus TCP/RTU gateway, MQTT connectivity, a metal housing, wide-range power input, and a -40°C to +85°C industrial-grade design. The console talks over RS232 to the terminal while sensors feed data over RS485 to the platform — one box handling both jobs.
Getting an RS232 device onto the network is half hardware and half a decision: direct TCP access or a virtual COM port. Once that route is settled, a suitable RS232 to Ethernet converter plus three steps — wiring, matching parameters, opening a terminal — brings legacy serial equipment onto the LAN for good.
