What Is the Modbus MBAP Header?
When Modbus moves from a serial line to TCP, it drops the serial address and CRC and instead prefixes each message with a small seven-byte structure called the MBAP header, short for Modbus Application Protocol header. Anyone reading a Modbus TCP capture in Wireshark or debugging a gateway needs to know what these bytes mean. This reference walks through each MBAP field, what it carries, and why the header exists at all.
Modbus MBAP Header in one line: The MBAP header is the seven-byte prefix on every Modbus TCP message. It has four fields: a two-byte transaction identifier that matches a response to its request, a two-byte protocol identifier that is zero for Modbus, a two-byte length giving the number of following bytes, and a one-byte unit identifier that routes to a serial device behind a gateway. It replaces the serial slave address and CRC.
Why Modbus TCP Needs the MBAP Header
Serial Modbus identifies a device by a one-byte slave address and detects corruption with a CRC, both of which suit a shared wire. On a TCP network the device is already identified by its IP address and TCP already guarantees ordered, error-checked delivery, so the serial address and CRC would be redundant. The MBAP header supplies what TCP does not: a way to match each reply to its request when several requests are in flight, and a way to reach a serial device sitting behind a gateway.
Because the header sits in front of the unchanged function code and data, the actual Modbus request is identical to its serial form once you strip the header. This is what lets a gateway translate cleanly between Modbus TCP and serial RTU. The broader packaging difference is laid out in the Modbus TCP vs RTU comparison.
The Four MBAP Fields
The transaction identifier is two bytes chosen by the master. The device copies it unchanged into the response so the master can pair a reply with the specific request that produced it, even when several are outstanding on one connection. This is the mechanism behind Modbus TCP pipelining and is why a master must not assume replies arrive in the order requests were sent.
The protocol identifier is two bytes and is always zero for Modbus; it exists so the same framing could in principle carry other protocols. The length field is two bytes and counts every byte that follows it in the message, namely the unit identifier plus the function code and data, so a receiver knows exactly where the message ends on a TCP stream that has no framing of its own.
The unit identifier is the final header byte and is the successor to the serial slave address. On a native Modbus TCP device it is often a placeholder because the IP address already identifies the device, but when a gateway bridges to a serial bus the unit identifier selects which serial device to forward the request to. Misusing it is a common gateway fault, discussed alongside the Modbus unit ID and slave address reference.
Frequently Asked Questions
How long is the MBAP header?
The MBAP header is seven bytes: two for the transaction identifier, two for the protocol identifier, two for the length, and one for the unit identifier. The function code and data follow immediately after those seven bytes, so the total application data unit on TCP is seven header bytes plus the protocol data unit.
Why is there no CRC in a Modbus TCP message?
TCP already provides its own checksums and guarantees reliable, ordered delivery, so a redundant Modbus-level CRC would add nothing. The MBAP header replaces the serial CRC entirely. This is why you will never find a CRC on a Modbus TCP capture, only the seven-byte MBAP header followed by the function code and data.
What does the unit identifier do on a native TCP device?
On a device that speaks Modbus TCP directly, the IP address already identifies it, so the unit identifier is usually a placeholder such as 1 or 255 and is ignored. It becomes meaningful only when a gateway forwards the request to one of several serial devices, where the unit identifier selects which serial slave address to target.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.