Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Modbus Encapsulated Interface Transport

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 25 Sep 2008 12:01:35 -0700

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.