Need help using a serial to Ethernet connector with my setup

Serial Communication
1

I’m trying to connect an older serial-only device to my network using a serial to Ethernet connector, but I’m confused about how to wire it, set the IP, and configure the virtual COM port. The manual is vague, and I keep losing the connection when I test it from my PC. Can someone walk me through the correct setup steps and common pitfalls so I can get stable remote access to this serial device over my LAN?

2

Short version so you can actually get it working instead of fighting the “manual”:

1. Wiring the serial side

First figure out what your old device is:

  • If it has a DB9 male connector it is usually a DCE device
  • If it has a DB9 female connector it is usually DTE

Most serial to Ethernet boxes present themselves as DTE, same as a PC. That means:

  • If your device is also DTE → you need a null‑modem cable or adapter
    • TX ↔ RX crossed
    • Pins: 2 ↔ 3, 3 ↔ 2, 5 ↔ 5 (ground)
  • If your device is DCE → you use a straight‑through serial cable
    • Pin 2 ↔ 2, 3 ↔ 3, 5 ↔ 5

Half the “it doesn’t work” posts are just the wrong cable. Ignore the manual’s vague picture and check the pinout printed on the device spec sheet if possible.

Also match baud rate, data bits, parity, stop bits, flow control on both ends. Typical defaults:
9600 8N1, no flow control.

2. Getting the Ethernet / IP configured

Most of these boxes support one of three methods:

  1. DHCP by default

    • Plug it into your router/switch
    • Log into the router and look at the DHCP client list
    • Find something like “SerialServer”, “USR‑TCP232”, “Moxa”, etc.
    • Grab its IP, then hit it in a browser: http://<that-IP>/

  2. Factory static IP (often 192.168.0.100 or 192.168.1.254)

    • Set your PC to a manual IP on the same subnet
      • Example: device is 192.168.0.100
        • Set PC to 192.168.0.10, mask 255.255.255.0, no gateway
    • Direct‑connect PC ↔ device or through an isolated switch
    • Open a browser and hit http://192.168.0.100/

  3. Vendor setup tool on Windows

    • A lot of these have a “Device Search” or “Device Manager” tool
    • It broadcasts on the LAN and finds the box even if the IP is unknown
    • Lets you set static IP, gateway, DNS, etc.

Once in the web UI:

  • Give it a static IP or DHCP reservation so it does not move
  • Set subnet mask and gateway correctly if you need access from other subnets
  • Save and reboot if the UI tells you to

3. Operate mode: TCP server vs client vs UDP

For classic “virtual COM port” use, the serial to Ethernet adapter usually should be:

  • TCP Server mode
    • Listens on a port such as 23, 3000, 4001, whatever the vendor default is
    • Your PC initiates the connection to the device’s IP and that port

Only use TCP client mode if your PC software expects incoming connections from the device, which is rare for old serial stuff.

4. Virtual COM port on Windows

You basically have two options:

A. Vendor’s COM port redirector

Most boxes come with a Windows utility that:

  1. Installs a custom driver
  2. Lets you map COMx → IP:Port

Typical steps:

  • Install their “Virtual COM” or “Port Redirector” tool
  • Add new COM port
  • Set IP to the serial to Ethernet box IP
  • Port equals the configured TCP port on the device (for ex. 4001)
  • Set “Always connect” or “Connect on open”
  • Test with PuTTY or TeraTerm
    • Open the new COM port in serial mode
    • See if you get data / can type commands

If it fails:

  • Double check that Windows firewall or AV is not blocking outbound TCP
  • Ping the device IP
  • Use telnet IP port or nc IP port to see if the port opens at all

B. Software‑only redirector (no vendor driver)

If the vendor software sucks or is missing, a product like Serial to Ethernet Connector works much better. It lets you:

  • Create a virtual COM port on your PC
  • Bind it to the IP and port of the serial to Ethernet hardware
  • Mirror or share the same serial device to multiple PCs if needed
  • Log and monitor traffic which is a life saver when the manual lies

You can read more about that kind of solution here:
advanced serial over Ethernet software

That “Serial to ethernet connector app” phrase from the docs is basically describing exactly this class of tool. The idea is: use a dedicated serial over IP application that creates reliable virtual COM ports, supports various TCP modes, and gives you better diagnostics than the cheap OEM utilities.

5. Basic sanity checks

If it still refuses to behave:

  1. Loopback test on the serial device

    • On the serial side, short pins 2 and 3 (TX and RX)
    • Open the virtual COM on your PC and start typing
    • If you see your own characters echo back you know:
      • PC ↔ Ethernet ↔ box network config is ok
      • Problem is likely baud / parity or wiring to the actual device

  2. Try direct TCP with a terminal app

    • In PuTTY choose “Raw” or “Telnet”
    • Host: device IP
    • Port: configured TCP port
    • If you see serial traffic, then the hardware and network are fine and the only issue is your virtual COM config or your legacy software.

Once you get any consistent chatter, take note of the working baud/format and lock it in on both ends.

That’s about it. 90% of setups fail because of:

  • wrong cable (null‑modem vs straight)
  • unknown IP / wrong subnet
  • serial settings mismatch
  • vendor’s garbage virtual COM tool

Fix those four and the old serial dinosaur usually plays nice on the LAN.

Need help using a serial to Ethernet connector with my setup
Need help using a serial to Ethernet connector with my setup1536×668 146 KB

2 Likes
3

Couple of extra angles to add on top of what @mike34 already covered, without repeating his whole textbook there.

1. Identify what your serial box really is doing

A lot of these cheap serial–Ethernet widgets lie with their marketing:

  • Some are pure TCP/UDP bridges only
  • Some properly support RFC 2217 (Telnet COM port control)
  • Some are “smart” and mangle data with extra framing or headers

Why it matters:
If your legacy software expects a plain COM port and is very picky, you really want a setup that behaves like a transparent serial pipe.

Quick tests:

  • Use a terminal like PuTTY in Raw mode to connect directly to IP:port
  • Send a few characters and sniff the serial line with a USB‑RS232 dongle + another terminal
  • If you see extra bytes, banners, or telnet negotiation junk, your box is not fully transparent and that can break older gear

This is where a software solution like Serial to Ethernet Connector is handy. It creates a proper virtual COM port on the PC and handles the messy IP side so the app still “thinks” it is talking to COM3 or whatever.

2. Double‑check RS‑232 vs RS‑422/485

The photo in your post looks suspiciously like some models that support RS‑232 and RS‑485 on the same terminal block.

Your old device might be:

  • RS‑232 only (DB9 connector)
  • RS‑485 2‑wire or 4‑wire (often screw terminals A/B)

If your adapter is in RS‑485 mode while your device is RS‑232, it will never work no matter how perfect the IP setup is.

Look in the web UI or DIP switches for:

  • “RS‑232 / RS‑485 / RS‑422” selector
  • “2‑wire / 4‑wire” choices

Make sure it is explicitly set to RS‑232 if you are using the DB9 side. Manuals love to hide this in one tiny table.

3. Flow control is not “extra,” it can totally kill comms

People match baud, data bits, parity and think they’re done. Then nothing works.

Check on both sides:

  • Hardware flow control (RTS/CTS)
  • Software flow control (XON/XOFF)

Many industrial devices are hard‑coded to no flow control.
Many serial–Ethernet boxes default to RTS/CTS.

If your device ignores CTS while the adapter is waiting for it, you get a dead session. Set no flow control first, then enable RTS/CTS only if you know the device supports it.

4. Forget the vendor’s virtual COM for a second

I’m going to slightly disagree with the “use the vendor redirector first” approach. Some of those drivers are ancient and flaky, and when they crash you’ve got random COM ports stuck open and you start questioning your life choices.

Alternative approach:

  1. Get the serial–Ethernet box working as a simple TCP server
    • Confirm with PuTTY Raw / telnet that you see real data
  2. Once you know IP and serial settings are correct, then introduce a COM redirector

For the redirector layer, Serial to Ethernet Connector is a solid, more modern tool:

  • It creates virtual COM ports on Windows
  • Binds them to IP and port on your adapter
  • Lets you share one serial device to multiple PCs if needed
  • Has logging so you can see exactly what’s sent over serial and TCP

That saves you a lot of guessing compared to the opaque OEM tools.

If you want to grab it, check out advanced Serial to Ethernet Connector downloads, the layout there is way easier to follow than many vendor “support” pages.

5. Simple step‑by‑step “am I crazy?” checklist

When everything feels cursed, walk through it in this order:

  1. Local serial sanity

    • Use a USB‑RS232 adapter direct into the old device
    • Confirm you can talk to it at all from a laptop
    • Note exact settings: baud, databits, parity, stop bits, flow, line endings

  2. Serial–Ethernet bridge only

    • Put a loopback on the serial output of the Ethernet box (short TX/RX)
    • Use PuTTY → Raw → IP:port
    • Type; if you see your own text, IP and serial config on the adapter are good

  3. Device with the adapter

    • Same PuTTY Raw → IP:port
    • No virtual COM yet
    • Do you see anything from the device at power‑up or when you send a known command?

  4. Finally introduce virtual COM

    • Configure a port in Serial to Ethernet Connector that points to the adapter IP:port
    • Point your old app at that COM
    • If it still fails, compare what your app sends vs what PuTTY sends; sometimes legacy software needs CR only, LF only, or CRLF and that tiny mismatch breaks everything

6. A small “don’t trust the manual” warning

You mentioned the manual is vague. Common lies I see:

  • Pinouts copied from a different model
  • Default IPs that do not match the current firmware
  • Claimed support for DHCP when it is disabled in reality
  • Stated max baud of 115200 while the device silently caps at 57600

If something in the manual does not match what you see in the web UI or the behavior, believe the behavior, not the PDF.

If you can post the exact model of the serial device and the serial–Ethernet box, plus the serial settings you think are correct, people here can usually spot what’s off in about 2 lines. The wiring is only half the battle; getting the modes and flow control right is where most of these fights are.

4

You’ve already got the “how” from @mike34 and @reveurdenuit, so I’ll stick to “how to debug this without losing your mind” and where the Serial to Ethernet Connector software actually fits in.

1. Don’t trust the LEDs blindly

Those link / TX / RX LEDs on the converter are useful, but only if you read them correctly:

  • Link LED on, activity flickering: network side is probably fine.
  • RX flashing but TX dead: the box is seeing data from the network but not sending anything to the serial device → wiring / mode / baud problem on serial side.
  • TX flashing but RX dead: your serial device is talking, but the PC isn’t actually opening the TCP connection or the virtual COM.

Watch the LEDs while:

  1. Powering on the serial device (a lot of gear spits a banner).
  2. Opening your virtual COM from the PC.
  3. Sending a simple command you know used to work.

That pattern alone usually tells you which “half” is broken.

2. Don’t overuse null‑modem adapters

Slight disagreement with the “null‑modem vs straight” focus: with industrial gear, I see a lot of folks stacking:

PC → USB‑RS232 dongle → null‑modem cable → serial server that is already DCE internally

Result: TX and RX end up crossed twice. If you have any gender changers / null‑modem blocks in the chain, simplify:

  • One cable, known pinout, no mystery adapters.
  • Check continuity pin‑to‑pin with a multimeter if in doubt.

If you cannot change the cable, flip TX/RX once at the terminal block (if your box has screw terminals) instead of hunting special cables.

3. Use Serial to Ethernet Connector only after a “raw TCP” success

Both @mike34 and @reveurdenuit mention using PuTTY or similar to hit IP:port directly. I’d go harder on that:

  1. Get this working first:

    • PuTTY (Raw) → IP of your box → port the box is listening on.
    • Confirm you see expected data and device responds.

  2. Only then bring in Serial to Ethernet Connector to create the virtual COM and present it to your legacy app.

Reason: if you jump straight into virtual COM, you are debugging 3 layers at once (legacy app + redirector + hardware). With raw TCP you only debug the hardware and serial settings.

4. Where Serial to Ethernet Connector helps (and where it does not)

Pros:

  • Much more stable than a lot of vendor redirectors.
  • Lets you create multiple virtual COM ports that all map to different IP:port pairs.
  • Has logging / monitoring so you can see exactly what your app sends and what comes back.
  • Can let multiple PCs access one serial device in some scenarios, which is useful for monitoring.

Cons:

  • It is still software glue on top of flaky hardware. If wiring or serial parameters are wrong, Serial to Ethernet Connector will not magically fix it.
  • Extra complexity compared to just using a terminal if all you need is basic access.
  • You need to maintain it across Windows updates, unlike simple TCP tools.

So use it to make your legacy program happy, not as a first‑line diagnostic tool.

5. Watch for “smart” modes that break transparency

Many serial servers have modes like:

  • Packet / delimiter modes
  • Modbus gateway
  • “Remote configuration” telnet ports

If any of those are enabled, your data may be chunked or wrapped. For a classic “turn COM1 into IP:port” use case, make sure the mode is a simple transparent TCP server, no protocol translation, no special framing.

Check for settings like:

  • Idle timeout
  • Packet size / timeout aggregation
  • Modbus / ASCII options

Turn that junk off at first.

6. Use a baseline: direct USB‑serial test

Before blaming the box, prove the device works and note exact parameters:

  1. USB‑RS232 dongle → device directly.
  2. Simple terminal program, no virtual COM, no IP.
  3. Confirm:
    • Exact baud.
    • Data bits, parity, stop bits.
    • Flow control.
    • Line ending the device expects (CR, LF, CRLF).

Then copy those settings verbatim into the serial server and into Serial to Ethernet Connector.

7. Competing advice from others, and how to reconcile it

  • @mike34 gave a very practical wiring and mode checklist. Good to follow for the first physical setup.
  • @reveurdenuit focused more on protocol transparency and RS‑232 vs RS‑485, which matters if your box can switch standards.

Combine them like this:

  1. Verify physical layer: RS‑232 vs RS‑485 mode, correct pins, no extra null‑modems.
  2. Confirm raw TCP transparency: PuTTY → IP:port, watch LEDs, watch data.
  3. Add Serial to Ethernet Connector so your old software just thinks it is talking to COMx.

If you post exact model numbers and the serial settings you’re using, you can usually get from “nothing works” to “it at least echoes” in a few small tweaks.