On Sep 25, 2008, at 11:22 AM, Al Pfalzgraf wrote:
I have been using Wireshark 1.0.3 to capture Modbus TCP traffic.
There are messages using service 43 (0x2b), Encapsulated Interface
Transport, service 14 (0x0e) Read Device Identification.
The capture log does not identify the messages as Modbus/T, they are
simply tagged as TCP.
7 0.020159 151.110.68.215 151.110.1.137 TCP tclprodebugger > asa-
appl-proto [PSH, ACK] Seq=13 Ack=13 Win=65523 [TCP CHECKSUM
INCORRECT] Len=11
8 0.031007 151.110.1.137 151.110.68.215 TCP asa-appl-proto >
tclprodebugger [ACK] Seq=13 Ack=24 Win=511 Len=0
9 0.100040 151.110.1.137 151.110.68.215 TCP asa-appl-proto >
tclprodebugger [PSH, ACK] Seq=13 Ack=24 Win=511 Len=30
asa-appl-proto is 502, at least on my 10.5.5 Mac, so the traffic *is*
going to and from the Modbus/TCP port, so the Modbus/TCP dissector
should be called.
However, the dissector is checking to see whether the packet looks OK,
and:
[manual dissection of Ethernet, IP, and TCP headers elided]
00 02
Modbus/TCP transaction ID
00 00
Modbus/TCP protocol ID
00 05
Modbus/TCP packet length = 5
01
Modbus unit ID
2b
Modbus function code = 43
The current Modbus/TCP dissector rejects frames it doesn't think are
valid Modbus/TCP packets, presumably so that non-Modbus/TCP traffic to
or from port 502 can be seen by heuristic dissectors. It also thinks
valid Modbus/TCP packets have a function code in the set 1-24, 40,
125-127, so it doesn't handle a function code of 43/0x2b.
Does Wireshark not understand this service as part of the Modbus
protocol?
Unfortunately, no.
If you would like to see support for this Modbus function in Wireshark,
raise an Incident on bugzilla (