QModMaster RTU over TCP Explained: Why There Is No Such Mode
You opened QModMaster’s connection settings, looking for “RTU over TCP” — and found only two choices: Modbus RTU and Modbus TCP. It is not a missing feature or a bug. QModMaster simply has no RTU-over-TCP mode, and understanding why will save you a long afternoon of failed connections.
The confusion usually starts at the network gateway. Many RS485-to-Ethernet gateways (Waveshare, Elfin, and similar) can move Modbus over the network in two completely different ways — and only one of them is “Modbus TCP”. This page maps all three frame formats, shows which QModMaster mode matches each, and gives you honest workarounds for the case QModMaster cannot cover natively.
The Three Ways Modbus Frames Travel
Modbus defines the application message (function code + data). How that message is packaged on the wire differs between the three transports you will meet in the field:
| Transport | Frame wrapper | Typical port | QModMaster mode |
|---|---|---|---|
| Modbus TCP | 7-byte MBAP header + Modbus PDU (no CRC) | 502 | Modbus TCP ✓ |
| RTU over TCP | Raw RTU frame (address + PDU + 2-byte CRC) stuffed into a TCP stream — no MBAP | 8899 (common for transparent mode) | None natively ✗ |
| Modbus RTU (serial) | RTU frame on the RS485/RS232 wire, silent-interval framing | Serial port (COMx / /dev/ttyUSBx) | Modbus RTU ✓ |
Notice the key difference: Modbus TCP wraps the payload in an MBAP header (transaction ID, protocol ID, length, unit ID). RTU-over-TCP keeps the original serial frame — including its 2-byte CRC — and just carries it inside TCP packets. A device expecting one format will not understand the other.
What QModMaster Actually Offers
QModMaster — the free, open-source (LGPLv3) Modbus master simulator from the upstream project — ships with exactly two connection types:
- Modbus RTU — talks to a serial port (real or USB-to-serial).
- Modbus TCP — talks Modbus TCP with an MBAP header, default port 502.
There is no “RTU over TCP” option in the connection dialog, and the upstream project has never added one. This is not unique to QModMaster: the split is a framing choice every Modbus tool makes. For example, open-source Home Assistant integrations commonly expose both options explicitly — one project’s README notes “if you instead run the gateway in transparent mode (raw RTU over TCP, usually port 8899), set protocol: rtu_over_tcp“, while another documents framing as “rtuovertcp for transparent bridges, tcp for gateways doing MBAP ⇄ RTU conversion” (Solis-Local, ha-toshiba-modbus). QModMaster simply only implements the two mainstream choices.
The Real Source of Confusion: Your Gateway’s Two Modes
Serial-to-Ethernet gateways typically run in one of two modes, and the names vary by vendor:
| Gateway mode | What it does | Port | Use in QModMaster |
|---|---|---|---|
| Conversion mode (e.g. Waveshare “Modbus TCP ⇔ Modbus RTU”) | The gateway parses the MBAP header itself and translates between Modbus TCP and serial RTU | 502 | Connect with Modbus TCP — works directly |
| Transparent mode | The gateway passes raw serial bytes through untouched — RTU frames (with CRC) ride inside TCP | 8899 (typical) | No native match — see workarounds below |
So the fix is usually not in QModMaster at all — it is one checkbox in the gateway’s web configuration. If your gateway is in conversion mode, just pick Modbus TCP in QModMaster and point it at the gateway’s IP, port 502. If it is stuck in transparent mode on 8899, read on.
Workarounds When the Gateway Is in Transparent Mode
QModMaster cannot speak raw RTU-over-TCP, so you have two honest options:
Option A (recommended): switch the gateway to conversion mode.
Open the gateway’s web UI, change the work mode from transparent to Modbus TCP ⇔ RTU (on Waveshare units this is often “Network A = TCP Server, port 502”), save, and reconnect QModMaster in Modbus TCP mode. No extra software, no extra failure points.
Option B: keep transparent mode and add a virtual serial port.
Run a TCP-to-serial redirector (e.g. socat on Linux, a virtual COM port driver on Windows) that maps the gateway’s 8899 stream to a virtual COM port, then point QModMaster’s Modbus RTU mode at that virtual port. It works, but you are adding a moving part that can break timing-sensitive RTU transactions.
Do not try the tempting shortcut of pointing QModMaster’s Modbus TCP mode at port 8899 in transparent mode: QModMaster will send MBAP-wrapped requests, the device behind the gateway will see garbage, and you will get timeouts — not useful error messages.
Spotting the Difference in QModMaster’s Bus Monitor
If you are unsure which format is on the wire, open QModMaster’s Bus Monitor and look at the raw bytes:
- Modbus TCP frames start with a 7-byte MBAP header: 2 bytes transaction ID, 2 bytes protocol ID (always
00 00), 2 bytes length, 1 byte unit ID — followed by the function code and data, with no CRC at the end. - RTU frames start with the slave address byte and end with a 2-byte CRC — no MBAP header anywhere.
A read-holding-registers request to unit 1 for 2 registers starting at 0 shows the contrast clearly: over Modbus TCP you will see something like 00 01 00 00 00 06 01 03 00 00 00 02 (MBAP + PDU); over RTU-over-TCP the same logical request arrives as 01 03 00 00 00 02 C4 0B (address + PDU + CRC). See our Bus Monitor guide for a full walkthrough of reading these captures.
Related Guides
- Modbus RTU/TCP Gateway Setup Guide
- What Is a Modbus Master?
- Registers Returned Don’t Match? Fix It
- QModMaster Bus Monitor Guide
Need a reliable RS485-to-Ethernet gateway?
Transparent vs. conversion mode is the setting that decides everything on this page — pick hardware that supports both.