[Guy Harris <guy@xxxxxxxxxxxx>]

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.