Wireshark-users: Re: [Wireshark-users] help in capturing Modbus traffic
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 12 Mar 2008 19:04:44 -0700

On Mar 12, 2008, at 3:46 PM, Niko Kozobolidis wrote:

Dear Wireshark-users:

Our Nicaraguan non-profit development organization is in the process of trying to determine a operator panel periodic freeze. This operator panel receives instructions from a controller. The operating panel and controller automate the operations of a 930 kW small hydro plant that provides electricity to a number of rural towns and villages.

The representative of the control system in Finland indicates that we should tap directly into the cable that sends data back and forth between the AC800M controller and the 235 Operator Panel. This is a special cable that has a female 9-pin RS-232 plug on one end and an RJ-45 male plug on the other end. A direct serial connection. How can one capture Modbus traffic or in other words obtain a trace file from this serial connection?

The control system representative also says that the software must support “MODBUS” protocol. When you open the Wireshark main page, and drop-down the HELP menu, there is a part of the HELP that gives a list of “ 911 protocols and packet types supported by Wireshark”. On this list we find “MODBUS/TCP” but not “MODBUS”. The representative from Finland thinks that “MODBUS” is different from “MODBUS/TCP”, and that we need Wireshark to support the “MODBUS” protocol to analyze the AC800M-to-Operator Panel traffic. Is Modbus/ Tcp different from Modbus and if so can wireshark capture traffic in the Modbus protocol or possibly translate from one protocol to the other?

Well:

	http://en.wikipedia.org/wiki/Modbus

"For serial connections, two variants exist, with different representations of numerical data and slightly different protocol details. Modbus RTU is a compact, binary representation of the data. Modbus ASCII is human readable, and more verbose. Both of these variants use serial communication. The RTU format follows the commands/ data with a cyclic redundancy check checksum, while the ASCII format uses a longitudinal redundancy check checksum. Nodes configured for the RTU variant will not communicate with nodes set for ASCII, and the reverse.

For connections over TCP/IP (e.g. Ethernet), the more recent variant Modbus/TCP exists. It is easier to implement than Modbus/ASCII or Modbus/RTU because it does not require a checksum calculation."

Following links from there to

	http://www.modbus.org/

and then looking for the documentation, there's

	http://www.modbus.org/docs/PI_MBUS_300.pdf

for an older specification for Modbus-over-serial-line, describing both ASCII and RTU,

	http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

for a newer specification, also describing both ASCII and RTU, and

	http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

for Modbus/TCP.

If the application-layer portion of the protocol is the same for Modbus-over-serial and Modbus-over-TCP, most of Wireshark's dissection code could be used for both, although we might have to split the dissector up. However, the lowest layers transporting the application- layer PDUs are different, so, yes, "MODBUS" (by which I assume the representative from Finland means Modbus-over-serial, given that the device uses a serial connection) is different from Modbus-over-TCP.

It appears that Modbus-over-serial uses standard asynchronous communication, with either

	1) 8 bits plus a parity bit, 1 stop bit

or

	2) 8 bits without a parity bit, 2 stop bits

so a standard computer's serial port hardware could handle it if it supports whatever the baud rate is for the controller. The framing for RTU mode is done with "silent times" on the serial line, which means software to capture those packets would have to look for those silent times to decide when a frame was done. For ASCII mode, a frame is terminated by a CR-LF pair.

In theory, somebody could:

get DLT_MODBUS_ASCII and/or DLT_MODBUS_RTU DLT_ values from tcpdump.org;

write code to read Modbus packets from a serial line and supply them as DLT_MODBUS_ASCII or DLT_MODBUS_RTU, and add that to the libpcap/ WinPcap library;

add support for DLT_MODBUS_ASCII and/or DLT_MODBUS_RTU to Wireshark, and build a version of Wireshark and run it using the modified version of libpcap/WinPcap;

in which case if you were able to put a serial line tap of some sort on the serial line in question, you would be able to sniff the Modbus traffic in Wireshark. However, that would, as Jaap noted, not be an off-the-shelf solution.

Searching for

	modbus analyzer

in Google found some items such as

	http://www.commfront.com/RS232_Protocol_Analyzer_Monitor/Modbus-Control-Protocol-Analyzer.htm

and

	http://www.modbus.org/viewdevice.php?id=453

and

	http://www.imperioustech.com/Pricing.html

so it sounds as if off-the-shelf solutions exist.