Vous êtes sur la page 1sur 32

Application Guide

Volume II

AG2012-15

Using Wireshark to Troubleshoot Protocol


Communications Issues on an RTAC
Chris Bontje

INTRODUCTION
With the SEL-3530 Real-Time Automation Controller (RTAC), a wide variety of
communications schemes can be integrated into an industrial automation network, including some
that were not possible with the SEL-2030 and SEL-2032 Communications Processors. In addition
to supporting traditional intelligent electronic devices (IEDs) or client protocols, such as SEL Fast
Metering, the RTAC also adds client support for both serial and Ethernet variations of DNP3 and
Modbus protocols. A similar suite of protocols is available for supervisory control and data
acquisition (SCADA) or server interfaces to allow data communication to the selected host
platform or human-machine interface (HMI).
A configuration software suite is provided with the RTAC. The ACSELERATOR RTAC
SEL-5033 Software allows the user to configure, load, and monitor the RTAC with client and
server protocols, as well as set several other advanced options, controlling engineering access
tunneling and custom IEC 61131-3 logic. A useful communications monitoring tool is also
provided with ACSELERATOR RTAC to allow detailed monitoring of all client and server serial
and Ethernet traffic present on the RTAC. The communications monitoring tool displays and
saves raw communications traffic. Protocol analysis for any communications typically requires
extensive effort on the part of a troubleshooting engineer to manually decode each message.
While a communications monitor is typically provided with many different data concentrator and
remote terminal unit (RTU) products, a clean and portable way to save the communications
traffic into a file format for offline troubleshooting is often not provided. However, the
ACSELERATOR RTAC communications monitor provides the ability to save the captured
communications traffic in pcap (packet capture) format, which allows for offline analysis by
third-party network administration tools such as tcpdump, Microsoft Network Monitor, and the
free, open-source tool Wireshark.
Wireshark is a particularly useful third-party tool for offline analysis because it is capable of
automatically decoding the traffic from several industrial protocols, such as DNP3 and Modbus
TCP, and presenting the data in a user-readable format. This eliminates the need for any manual
decoding of raw protocol traffic and can save a large amount of time when troubleshooting a
malfunctioning communications link.
This application guide outlines the process of capturing Ethernet or serial communications traffic
in the pcap format using a variety of methods and then discusses how to use the functionality of
Wireshark to decode the raw captured data into a user-readable format.

Date Code 20121221

SEL Application Guide 2012-15

BACKGROUND
Wireshark is well known in the information technology (IT) community as a network
troubleshooting tool, but its user base continues to expand as its capabilities grow.
For more background information, visit the Wireshark home page. Wireshark can be downloaded
free of charge from http://www.wireshark.org.
Originally, network hubs were the most common devices used to connect network equipment to a
network. A network hub simply received Ethernet messages on one port and repeated identical
messages to every other active port on that hub (this is referred to as Layer 1 technology). Due to
this behavior, Ethernet networks based on hubs quickly experienced excessive loading and
performance degradation due to several message collisions and subsequent retransmissions.
Eventually, a Layer 2 network switch evolved from the hub-based Layer 1 technology and added
a very important featurelow-level analysis of Ethernet packets to allow selectivity in which
messages are forwarded to which port. Essentially, an Ethernet switch learns the media access
control (MAC) address, or Layer 2 address, of the Ethernet frame of each device connected to it
and analyzes any incoming messages. It pays particular attention to the destination address field
of the Ethernet frame. Once the destination address is known, the switch forwards that particular
Ethernet packet only to the appropriate port that has the destination device connected to it. In
migrating from hub-based to switch-based Ethernet connectivity, large gains in performance are
realized.
One major drawback of using network switches rather than hubs is that network-wide packet
analysis is generally no longer possible with standard equipment because a device connected to
one port can no longer see any messages addressed to the other ports. However, there are several
ways around this limitation that are discussed in the next section.
Over time, many network switch manufacturers have added even more functionality to their
devices, with advanced features that provide extensive control and security for individual ports on
the switch. These devices are referred to as managed switches, whereas classic switches with
basic functionality are referred to as unmanaged. A typical managed switch includes many
advanced functions, such as virtual local-area network (VLAN) priority tagging, quality of
service (QoS) guarantees, Rapid Spanning Tree Protocol (RSTP), port disabling, port mirroring,
Simple Network Management Protocol (SNMP), web management, and real-time network
statistics.

CAPTURING DATA PACKETS


Before Wireshark can be used for troubleshooting, the Ethernet traffic must first be captured into
the Wireshark-compatible pcap file format. While there are several methods that can be used to
capture Ethernet packets for troubleshooting analysis, this application guide outlines the
following three methods:

Capturing packets using Wireshark with a managed switch mirrored port.

Capturing packets using Wireshark with a temporary network hub.

Capturing packets using ACSELERATOR RTAC communications monitor.

SEL Application Guide 2012-15

Date Code 20121221

Each example in this application guide uses a typical industrial Ethernet network based on the
standard configuration shown in Figure 1.
SCADA Host
Interface

Engineering
Workstation

Industrial Network Switch

SEL-3530 RTAC

IED

IED

IED

IED

Figure 1 Typical Ethernet-Based Industrial Automation Network

Capturing Packets Using Wireshark With a Managed Switch Mirrored Port


In this method, the Wireshark program is installed on the engineering workstation and all
Ethernet traffic is monitored and captured from that point.
Many managed switches provide port mirroring, whereby all traffic sent or received from a
configured port can be manually mirrored to a second port. This is typically only used in
diagnostic scenarios, and it works quite well for packet capturing purposes. To use this function
for packet capturing, configure the network switch to mirror the RTAC switch port to the
engineering workstation switch port, as shown in Figure 2. By doing so, the engineering
workstation and Wireshark gain visibility of the RTAC network traffic.
SCADA Host
Interface

Engineering
Workstation

Mirrored Port

Wireshark Installed

Managed Ethernet Switch

SEL-3530 RTAC

IED

IED

IED

IED

Figure 2 Industrial Automation Network With Managed Switch

Date Code 20121221

SEL Application Guide 2012-15

Step 1
To begin capturing packets in Wireshark, launch the software from the provided desktop icon or
Start menu icon and wait for the front page to appear, as shown in Figure 3.

Figure 3 Wireshark Front Page

Step 2
Once the front page is loaded, the software is ready to capture packets. Choose Capture >
Interfaces from the drop-down menu. Wait until the Capture Interfaces dialog box is displayed,
as shown in Figure 4.

Figure 4 Start Wireshark Interface Capture

SEL Application Guide 2012-15

Date Code 20121221

Step 3
Most computers have several interfaces present, including virtual private network (VPN) and
wireless Ethernet network adapters, so look for the hard-wired Ethernet adapter that is connected
to the Ethernet switch and has an incrementing number of packets being monitored. Once the
identity of the adapter is established, check the box beside that adapter, and click Start to begin
packet capture. New received (and captured) Ethernet messages appear sequentially in the main
Wireshark display, as shown in Figure 5.

Figure 5 Wireshark Real-Time Packet Capture

Step 4
Once the desired messages have been captured, choose Capture > Stop, as shown in Figure 6.

Figure 6 Stop Wireshark Interface Capture

Step 5
Choose File > Save to save the captured packets as a pcap file.
Note: Newer Wireshark versions may ask to save as a pcapng (pcap next generation) file type.
This file format is newer and adds various features, such as user annotations and other
extended information, but saving as a classic pcap format is still recommended as a valid
alternative for maximum compatibility.

Date Code 20121221

SEL Application Guide 2012-15

Capturing Packets Using Wireshark With a Temporary Network Hub


In this method, Wireshark is still installed on the engineering workstation computer, but a
temporary network hub is installed to allow visibility between devices connected on the switch.
As shown in Figure 7, all traffic among the SCADA host, RTAC, and the uplink to the IED
switch is visible on the engineering workstation. Because hubs repeat network messages to all
ports, Wireshark receives a copy of all messages that are sent and received and can capture
extremely detailed logs at this point. Packet capturing is set up and run with exactly the same
procedure as with the managed Ethernet switch in place, but no networking settings need to be
adjusted besides the addition of the hub. This setup is recommended only for troubleshooting
purposes. No permanent installation should contain a network hub because of performance and
security issues.
SCADA
Host Interface

Temporary Hub

Engineering
Workstation

Industrial Network Switch

Wireshark Installed

Unmanaged
Ethernet Switch

SEL-3530 RTAC

IED

IED

IED

IED

Figure 7 Industrial Automation Network With Temporary Hub Installed

Capturing Packets Using ACSELERATOR RTAC Communications Monitor


It is also possible to perform packet capture and create pcap files directly from the RTAC using
ACSELERATOR RTAC rather than the Wireshark program.
Step 1
In order to use the communications monitor features, ACSELERATOR RTAC must be in Online
mode with the RTAC. In order to reach online mode, there are two possibilities.

SEL Application Guide 2012-15

Date Code 20121221

If the running RTAC configuration is identical to the loaded ACSELERATOR RTAC


configuration, click Go Online in ACSELERATOR RTAC in the toolbar, enter the address and
security credentials, and click Login (see Figure 8). Once the Status tab indicates that the user
has connected to the RTAC, click Go.

Figure 8 Go Online in ACSELERATOR RTAC

If the running RTAC configuration is unknown or different from a stored ACSELERATOR RTAC
configuration, close any open projects, click SEL in the upper left corner, and select Read. Enter
the RTAC address and security credentials, and click Login, as shown in Figure 9. Once the
Status tab indicates that the user is connected to the RTAC, click Read. After the project has
been completely read, open the newly available project in ACSELERATOR RTAC and follow the
instructions to go online.

Figure 9 Read Settings in ACSELERATOR RTAC

Step 2
Once in online mode, the Go Online button is unavailable, and the Go Offline button becomes
available. Choose the Comm Monitor option from the toolbar to launch the communications
monitor dialog box, as shown in Figure 10.

Figure 10 Launch the Comm Monitor


Date Code 20121221

SEL Application Guide 2012-15

Once the Comm Monitor is launched, a simple selection window (see Figure 11) shows all the
different types of communications traffic that can be captured, grouped by capture source. For the
various capture source options, refer to Table 1.

Figure 11 Select Comm Monitor Capture Source


Table 1 Communications Monitor Capture Options
Name

Description

From File

Load previously captured traffic, saved as a pcap file, into the


ACSELERATOR RTAC Comm Monitor view.

Live Direct Serial Device

Capture communications traffic from client and server protocols or an


access point configured on the local RTAC serial ports.

Live Ethernet and Tunneled


Serial Devices

Capture communications traffic from a client and server protocols or


an access point configured over an RTAC Ethernet channel.

Live All Ethernet Traffic

Capture all Ethernet communications traffic on the RTAC, including


all client and server protocols and access point traffic, as well as local
process and configuration software traffic.

Step 3
If the Live Direct Serial Device or Live Ethernet or Tunneled Serial Devices capture
source is chosen, a list of the available devices becomes available. Check the box next to the
device for which the user wishes to monitor communication, as shown in Figure 12.

Figure 12 Configure Comm Monitor Window

SEL Application Guide 2012-15

Date Code 20121221

Step 4
When the Comm Monitor window opens, click Start to begin capturing data live, as shown in
Figure 13.

Figure 13 Active Comm Monitor Window

Step 5
After the desired test is complete (field status event generation, SCADA command, and so on),
the Comm Monitor must be stopped in order to complete packet capture. Click Stop, and choose
Save Capture from the toolbar at the top of the Comm Monitor window. This provides the
functionality to save all the captured communications monitoring data in pcap or text format.

USING WIRESHARK TO DECODE DATA CAPTURES


Using Wireshark to Interpret Previously Captured DNP3 Ethernet Data
After Wireshark is launched, select File > Open to choose the previously saved pcap file (or
double-click the saved file via Windows Explorer). The main Wireshark program produces the
three panes of data shown in Figure 14 and described as follows:

The top frame in Figure 14, the packet summary pane, shows all captured data packets in
sequence, along with the time of capture (offset since first packet), source and destination
Internet Protocol (IP) addresses, detected protocol, length (in bytes), and automatically
decoded information from the message.

The middle frame in Figure 14, the detailed frame information pane, shows the decoding
of various frame layers of the Ethernet frames. Because the packet capture in this
example is software-generated by the ACSELERATOR RTAC communications monitor
(rather than from an actual network card), there is no actual Ethernet frame information

Date Code 20121221

SEL Application Guide 2012-15

10

(for example, MAC addresses) and the packet is labeled as a Linux cooked capture. The
IP and Transmission Control Protocol (TCP) frame information is listed next, and finally,
the DNP3 message information is decoded. The typically valuable components of the
DNP3 frame are the data link layer, which shows DNP3 link addresses, and the
application layer, where all the function codes and data objects are decoded.

The bottom frame in Figure 14, the raw data display pane, shows the raw bytes captured
on the wire, which are the same data shown in the Comm Monitor display. The frame
information can be manually decoded from this area if desired. A DNP3 message always
starts with 0x0564 (see Figure 14), and that portion of the data message can be viewed
starting at packet offset byte 0x0044.

Figure 14 Wireshark Major Display Panes

Using Wireshark to Identify Common DNP3 Messages


Once the raw DNP3 data stream has been decoded in Wireshark, it is helpful to identify common
messages seen in many client and server DNP3 conversations. These common messages help to
determine the behavior of the DNP3 communications network as well as show any internal data
points as information is passed between the client and server.

SEL Application Guide 2012-15

Date Code 20121221

11

Class 1, 2, 3 Event Poll


The most common message is a Class 1, 2, 3 (Event) poll, as shown in Figure 15. This is a small
message using the Read function code (0x01) and containing the three class data objects. These
three class objects are typically configured on the DNP3 server IED to represent changed data
(binary, analog, or counter) and are used in a report-by-exception (RBE) polling scheme.

Figure 15 DNP3 Class 1, 2, 3 Data Poll

Class 1, 2, 3 Response With No Data


When RBE class polling is performed, it is quite typical for the DNP3 response message to
contain no data in a static system with wide analog dead bands. This is indicated by the presence
of a Response message (function code 0x81), Internal Indications (IIN) bits, and no data objects
being present, as shown in Figure 16. This is completely normal and simply shows that no data
have changed since the last poll.

Figure 16 DNP3 Response No Changed or Static Data Available

Date Code 20121221

SEL Application Guide 2012-15

12

Class 1, 2, 3, 0 Integrity Poll


A Class 1, 2, 3, 0 (Integrity) poll is nearly identical to the Class 1, 2, 3 (Event) poll, except that it
adds the Read request for the Class 0 object. This is a special-purpose object in many DNP3
server implementations because it triggers a response with a static (or snapshot) copy of the entire
DNP3 data map of an IED. An example of an Integrity poll can be seen in Figure 17.

Figure 17 DNP3 Class 1, 2, 3, 0 Integrity Poll

DNP3 Message Transport Layer With Segmented Messages


Due to the backward-compatible serial and radio communications allowances of the DNP3
protocol, the maximum response message size cannot exceed 255 bytes. However, if an IED has a
significantly sized data map, a DNP3 response (typically from an Integrity poll) can frequently
exceed the maximum message size limit. If this occurs, the Transport Layer portion of DNP3 uses
the FIR (first) and FIN (final) bits to indicate that subsequent messages are to follow and uses the
bits to sequence the messages together (see Figure 18). Wireshark automatically detects these
instances and reassembles the total Application Layer payload (typically data objects) in the
message that contains the FIN bit set. The reassembly frame number indicates to the user that the
Wireshark packet where the final decoded payload is positioned.

Figure 18 DNP3 Response Larger Than 255 Bytes

SEL Application Guide 2012-15

Date Code 20121221

13

Integrity Poll Response With Complete Static Data Map


A single-frame Integrity poll response from an IED is possible if the data map is relatively small
and the static data response is under the 255-byte Application Layer maximum size. Note that in
the message shown in Figure 19, both the FIR and FIN bits are set in the Transport Layer,
indicating a single-frame response.

Figure 19 DNP3 Integrity Response Complete Static Data Map

Binary Input Change With Time-Stamped Event


The DNP3 protocol supports transmission of time-stamped data from the source IED all the way
up to a SCADA system for display in a common event log. Often, there is confusion about the
differences in the recorded time stamps from a Sequential Events Recorder (SER) or sequence of
events table and the root cause of wrong or offset times. Using Wireshark, actual Binary Input
Change events passed on the channel can be captured and the time stamps can be compared with
the source SER log in the IED, the internal RTAC time stamp, the time stamp sent by the RTAC
to SCADA, and the SCADA event logger. A sample Binary Input Change event with a captured
time stamp is shown in Figure 20.

Figure 20 DNP3 Response Binary Input Change With Time Object

Date Code 20121221

SEL Application Guide 2012-15

14

DNP3 Command (Control Relay Output Block)


To confirm that a DNP3 command is being transmitted properly, first look for Application Layer
function codes 0x03 (SELECT), 0x04 (OPERATE), 0x05 (DIRECT OPERATE), or 0x06
(DIRECT OPERATE, NO ACK). The Control Relay Output Block object (Obj: 12, Var; 1), as
shown in Figure 21, is associated with these function codes and the details of the SCADAgenerated command can be checked. This includes details such as the Point Number (index) and
the Control Code specifics (latch, pulse, trip/close, and so on).

Figure 21 DNP3 Command Control Relay Output Block

Decoding DNP3 Messages on a Port Other Than TCP Port 20000


The default Internet Assigned Number Authority (IANA) port registration for DNP3 is TCP (or
User Datagram Protocol [UDP]) Port 20000. This standard is used to trigger Wireshark to
automatically decode any captured messages on TCP Port 20000 as DNP3 packets. In many cases
however, a serial or Ethernet port server is used that tunnels DNP3 protocol over a nonstandard
port. TCP Port 1040 was used in Figure 22. TCP Port 1024 was assigned a protocol named
netarx, and Wireshark does not recognize these packets as DNP3 data.

Figure 22 DNP3 Messages on Nonstandard TCP Port


SEL Application Guide 2012-15

Date Code 20121221

15

The following steps describe how to override the default port processing mapping of Wireshark
and perform a manual Decode As function.
Step 1
Right-click on the first packet in the capture, and choose Decode As, as shown in Figure 23.

Figure 23 Right-Click Menu of First Packet

Step 2
DNP3 is considered a Transport protocol in Wireshark, so click on the appropriate tab, and select
DNP3 from the list of available protocols (see Figure 24). Also, choose the appropriate TCP ports
for the manual handling (Source, Destination, or Both).

Figure 24 Select Decode As

Date Code 20121221

SEL Application Guide 2012-15

16

After the manual Decode As processing is applied to the packets defined as DNP3, the messages
are flagged as DNP 3.0 protocol and have the appropriate DNP3 layer decoded (see Figure 25).

Figure 25 DNP3 Messages Manual Decode As

Decoding Modbus TCP Messages on TCP Port 502


Wireshark also automatically decodes Modbus TCP Ethernet messages (but not Modbus RTU
over TCP, which is essentially Ethernet-tunneled serial data) that are routed through TCP
Port 502. The actual message header and addressing information can contain some useful data,
but the register data payload is typically not decoded because Modbus does not standardize on a
data type from raw Holding and Input Registers (integer, unsigned integer, floating point, and
encoded binaries). Rather, the data types used by Modbus tend to vary between manufacturers
and require careful analysis of the IED documentation to allow conversion back to engineering
units.
Frequent uses of the decoded Modbus TCP packet data include checking timing, performance,
and the sequence of register scans that are performed.

SEL Application Guide 2012-15

Date Code 20121221

17

As shown in Figure 26, this particular Modbus TCP message is a scan from a client to a server
and is using the Read Input Registers function (0x04) to specify six 16-bit register words,
beginning at register offset 0.

Figure 26 Modbus TCP Message Decoding

Decoding Communications Traffic to Troubleshoot SEL Protocol


Failure to Connect
When decoding raw protocol communications traffic for the purpose of troubleshooting an
Ethernet-tunneled serial connection to an SEL protocol device, the ACSELERATOR RTAC
communications monitor or Wireshark captures raw Telnet data and displays the data as shown in
Figure 27. This particular set of data traffic was produced from an RTAC conversation to an
SEL-501 Dual Universal Overcurrent Relay through an SEL-3610 Port Server. The SEL-3610
accepted a connection at TCP Port 1024 (configured in the SEL client settings) from the RTAC
local TCP Port 47370, which is automatically determined.

Figure 27 Raw Capture From SEL-501 Ethernet-Tunneled Serial Connection


Date Code 20121221

SEL Application Guide 2012-15

18

The RTAC online monitoring capabilities (accessed via ACSELERATOR RTAC) indicated by the
Messages Sent and the Messages Received program organizational unit (POU) tags incrementing
that it was physically communicating to the device. Even though physical communication was
observed, the data tags for the device would not successfully come online and the Offline POU
tag stayed TRUE.
While it is still possible to manually troubleshoot this connection by observing the Telnet data
portion of the Ethernet messages, there is an automated Wireshark tool for displaying the ASCII
data stream sent via TCP packets.
Pick the first packet in the data stream to troubleshoot. From the Analyze menu, choose Follow
TCP Stream, as shown in Figure 28, which strips out all Ethernet headers and packets and leaves
only the Application Layer data.

Figure 28 Choose Follow TCP Stream

In the resulting Follow TCP Stream window, all sent data are displayed in red, and all received
data are displayed in blue (see Figure 29). Note that the red and blue colorings are determined by
which action occurred first in the conversation (in this case, it was a transmit). Red indicates
Point A to B, and blue indicates Point B to A. Also, be aware of Telnet functions such as Echo,
which automatically echoes back any sent characters to the sender.
Figure 29 is an example of the decoded data stream. It shows that the default ACC password
OTTER was the incorrect password for the SEL-501.

Figure 29 Observe Telnet Data Stream

Decoding RTAC-Captured Serial DNP3 Data in Wireshark


The functionality discussed in this section requires at least Wireshark Version 1.7.1. A download
link for the current Windows 32-bit version of Wireshark is available at http://www.wireshark.org
/download.html.

SEL Application Guide 2012-15

Date Code 20121221

19

Many industrial installations still use serial connections from an RTAC or data concentrator to
downstream IEDs (as shown in Figure 30) in cases where it is not necessarily guaranteed that the
IEDs support Ethernet. While Wireshark cannot capture any serial packet data from the IEDs
(because they are not on an Ethernet network), it is possible for the ACSELERATOR RTAC
communications monitor to capture serial data packets and still save them in pcap format.
SCADA Host
Interface

Engineering
Workstation

Industrial Network Switch

SEL-3530 RTAC

EIA-232 Serial
IED

IED

IED

IED

Figure 30 Industrial Automation Network With Mixed Serial and Ethernet

Note: Many SEL serial DNP3 devices have a parameter known as PSTDLY that is set to 0.00
seconds by default. This can be problematic with serial DNP3 packet capture because
during an IED DNP3 response, the changing of the serial control lines causes a new
packet to be generated in the ACSELERATOR RTAC communications monitor, and this
can occasionally segment the last byte or two bytes from a full DNP3 response message.
This frequently results in an incomplete cyclic redundancy check (CRC) for the DNP3
response message in question, and Wireshark reports the DNP3 packet as malformed and
fails to decode it. In order to correct this issue, the PSTDLY setting in the DNP3 serial
port of the SEL IED should be configured to be a non-zero value, such as 0.01 seconds.
Once a pcap file containing RTAC serial data traffic in Wireshark is launched, note that no
Ethernet or TCP frame is present and Wireshark reports that it cannot decode the packet. In place
of the expected Ethernet frame(s) is, in fact, a 12-byte header containing the serial control line
information (RTS, CTS, and so on) from the ACSELERATOR RTAC communications monitor, as
shown in Figure 31.

Figure 31 ACSELERATOR RTAC Comm Monitor Serial Line Information

After the 12-byte serial control line data header, the full DNP3 message can be clearly identified
by the starting protocol header of 0x0564.
In cases where nonstandard (i.e., no Ethernet header) packet captures are loaded, User
encapsulation link layer options (referred to as user DLT options) are offered so that decoders

Date Code 20121221

SEL Application Guide 2012-15

20

built into Wireshark can be applied to the application data known to be present in the nonstandard
messages (see Figure 32).

Figure 32 Wireshark Decode Errors on Nonstandard Packets

The following steps describe how to use the DLT options for decoding serial DNP3 messages.
Step 1
Select the Edit menu, and choose Preferences (see Figure 33).

Figure 33 Wireshark Preferences Menu Selection

SEL Application Guide 2012-15

Date Code 20121221

21

Step 2
Once in the Preferences dialog box, choose the Protocols group, and expand it by clicking the
+ symbol, as shown in Figure 34.

Figure 34 Wireshark Preferences > Protocols

Step 3
Select the DLT_USER field, and click the Edit button that appears on the right-hand pane of the
window, as shown in Figure 35.

Figure 35 Wireshark Preferences > Protocols > DLT_USER

Date Code 20121221

SEL Application Guide 2012-15

22

Step 4
Once in the User DLTs Table settings window, click the New button to create a new user decode
function, as shown in Figure 36.

Figure 36 Wireshark User DLTs Table > New

Step 5
When configuring the user DLT, ensure that the User 0 (DLT=147) option is selected and
complete the data fields exactly as shown in Figure 37.

Figure 37 Wireshark User DLTs for Serial DNP3 Data

This configures the user DLT decoder to manually strip off a 12-byte header containing raw data
(the serial control line information recorded by the ACSELERATOR RTAC communications
monitor) and process the rest of the file as DNP3, as shown in Figure 37. Click OK when the
three parameters are entered.
Step 6
Confirm that the User 0 (DLT=147) settings are the same as those shown in Figure 38, and
click OK.

Figure 38 Wireshark Confirmation of User DLT Settings

SEL Application Guide 2012-15

Date Code 20121221

23

Once the user DLT has been configured and activated, any serial data starting at byte 13 of the
data message and detected to be DNP3 (starting with 0x0564) is decoded into user-readable
DNP3 messages, as shown in Figure 39.

Figure 39 Wireshark Decoding of Serial DNP3 Data

Importing Raw DNP3 Text Data to Wireshark for Automatic Decoding


Importing raw DNP3 text data to Wireshark for automatic decoding is considered advanced
functionality. It requires the manual formatting of input text files and usage of command line
utility tools provided by Wireshark. Complete samples of raw and formatted data are located in
the appendix of this application guide.
Often when working with third-party protocol drivers, some form of communications monitoring
capability is built in for communications debugging purposes. Occasionally, the debugging tool
also allows the saving of captured raw data messages into text file format. A text file save of raw
DNP3 traffic cannot be opened in Wireshark directly, but with some intermediary steps, the user
can create a hand-crafted pcap file that allows use of the Wireshark internal decoding capabilities.
To prepare for importing raw DNP3 text data:

Ensure that the text2pcap.exe conversion utility is installed in the C:\Program


Files\Wireshark folder alongside Wireshark.exe. As indicated by the filename,
text2pcap takes text files containing packet data as an input and outputs pcap files for
Wireshark.

Obtain a raw text file capture of the DNP3 conversation to decode.

The raw DNP3 text capture likely contains several pieces of extraneous information that cannot
be processed by Wireshark properly, and the formatted text must follow strict syntax rules to be
interpreted by the text2pcap conversion utility. We recommend using a standard text editor for
editing the data file to ensure no extra characters or raw formatting codes are inserted into the
Date Code 20121221

SEL Application Guide 2012-15

24

data without the knowledge of the users. Notepad, Textpad, and Notepad++ are all excellent
tools for this job.
The raw DNP3 data text is most likely arranged in a manufacturer-determined custom format that
is similar to the following screen capture. In this example, there are 15 bytes per line and
additional information for message size and direction.
[15:17:04.507] Tx => (10 Bytes)
05 64 05 C0 0A 00 64 00 37 68
[15:17:04.710] Rx <= (10 Bytes)
05 64 05 00 64 00 0A 00 B4 C6
[15:17:04.757] Tx => (27 Bytes)
05 64 14 C4 0A 00 64 00 09 29 C1 C1 01 3C 02
06 3C 03 06 3C 04 06 3C 01 06 62 01

The raw DNP3 data must be manually formatted to follow a hexadecimal packet addressing
scheme, where each DNP3 message (sent or received) is assigned to a packet and each block of
packet data begins with a hexadecimal offset address starting with 000000. The following screen
capture is an example.
000000 05 64 05 C0 0A 00 64 00 37 68
000000 05 64 05 00 64 00 0A 00 B4 C6
000000 05 64 14 C4 0A 00 64 00 09 29 C1 C1 01 3C 02 06
000010 3C 03 06 3C 04 06 3C 01 06 62 01

As shown in the formatted example, each line of the edited text file starts with a packet address
offset and contains a maximum of 16 bytes. If a packet length is greater than 16 bytes, the next
line of the text file contains the next address offset and then continues on with the remaining
bytes. There is nothing to specify that the bytes have to be addressed in groups of 16. A user
could easily place 32, 64, 128, or even 256 bytes per line but could encounter text file formatting
issues when trying to display all the data at once in an editor (for example, word wrap).
Note that there does appear to be a requirement (in some versions of Wireshark) for text2pcap to
have a trailing byte added to the last packet in the text file. Otherwise, it skips the last valid data
byte. The addition of the trailing byte is straightforward, as seen in the following screen capture
(0x00 is used as an example, but the byte can be any 8-bit hexadecimal identifier).
000000 05 64 05 C0 0A 00 64 00 37 68
000000 05 64 05 00 64 00 0A 00 B4 C6
000000 05 64 14 C4 0A 00 64 00 09 29 C1 C1 01 3C 02 06
000010 3C 03 06 3C 04 06 3C 01 06 62 01 00

SEL Application Guide 2012-15

Date Code 20121221

25

Once the DNP3 data text has been fully formatted, we recommend saving the text file in an easily
accessible location (by command line), such as the root of the C drive. In the example shown in
Figure 40, the file has been saved as C:\in.txt.

Figure 40 Text2pcap Utility Output

Because text2pcap can only be executed from a command line interface (CLI), the user must
launch the appropriate CLI before using the utility (in Windows, select Start > Run > cmd).
Once the CLI is available, navigate to the Wireshark program folder using the cd command
(cd\Program Files\Wireshark). Once text2pcap is located in the proper directory, execute the
text2pcap utility using the following command line options (assuming that the input text file is
actually called c:\in.txt and located in the root of the C drive):
text2pcap -T 47000,20000 c:\in.txt c:\out.pcap
The -T 47000,20000 option included in the command line produces fake Ethernet and IP headers
at the beginning of each packet, with the source port at TCP Port 47000 and the destination port
at TCP Port 20000 (by default to indicate a DNP3 message). If the command line is successfully
executed, text2pcap generates messages indicating the addition of fake Ethernet, IP, and TCP
headers and the detection of each data packet present in the text file.
The output pcap file is called out.pcap and placed in the root of the C drive.

Date Code 20121221

SEL Application Guide 2012-15

26

As shown in the processed example in Figure 41, fake Ethernet, IP, and TCP headers have been
added to simulate a normal IP link (10.1.1.1 and 10.2.2.2) and each packet has been assigned an
automatically incrementing simulated time stamp to allow for time-based sorting.

Figure 41 Wireshark Text2pcap Converted DNP3 Text Data

For even more functionality, a user can also include the original time-stamp information (if
available) from the raw DNP3 data and place it into the formatted text DNP3 packet data as
follows (note the continued presence of the trailing byte).
15:17:04.507
000000 05 64 05 C0 0A 00 64 00 37 68
15:17:04.710
000000 05 64 05 00 64 00 0A 00 B4 C6
15:17:04.757
000000 05 64 14 C4 0A 00 64 00 09 29 C1 C1 01 3C 02 06
000010 3C 03 06 3C 04 06 3C 01 06 62 01 00

In order to process the new time-stamp information, the text2pcap command line options must be
expanded to specify the time-stamp format, as follows:
:
text2pcap -T 47000,20000 t %H:%M:%S. c:\in_ts.txt c:\out_ts.pcap
The addition of the t %H:%M:%S. option indicates to text2pcap that it must process a time
stamp, which is stored in HH:MM:SS.mmm format, located before each packet.

SEL Application Guide 2012-15

Date Code 20121221

27

After executing the text2pcap utility again with the additional time-stamp data and new command
line option code, the decoded data contain real-world time-stamp offsets for each packet. The first
packet is always assigned to 0.000000, with each following packet assigned a time stamp based
on the time offset from the first packet (see Figure 42).

Figure 42 Wireshark Text2pcap Converted DNP3 Text Data With Time Stamp

For the example in the previous screen capture, the first packet is tagged as 15:17:04.507 and the
second packet is tagged as 15:17:04:710. The text2pcap utility interprets these time stamps based
on an offset of 0 seconds for the first packet. Therefore, the time stamp of the second packet is
derived from (1).
(1)

15 :17 : 04.710 15 :17 : 04.507 = 203 ms

CONCLUSION
This application guide provides the steps to use the Wireshark software package (available at no
cost from http://www.wireshark.org) as a means of troubleshooting modern industrial SCADA
Ethernet networks and their associated equipment.
This application guide explains various methods to capture raw protocol data, as well as how to
use Wireshark to decode different data formats to a user-readable format.
For more information on the products in this application guide and relevant standards and
protocols, refer to the following web pages:

RTAC product information http://www.selinc.com/SEL-3530/

ACSELERATOR

SEL-2032 product information http://www.selinc.com/SEL-2032/

Date Code 20121221

RTAC Software download http://www.selinc.com/SEL-5033/

SEL Application Guide 2012-15

28

DNP3 users group forum http://www.dnp.org/default.aspx

Modbus Organization information http://www.modbus.org/

Internet Assigned Numbers Authority information http://www.iana.org/

Wireshark information http://www.wireshark.org/

APPENDIX
This appendix includes a portion of sample DNP3 text data, both raw and formatted, for practice
with the text2pcap utility discussed in the Importing Raw DNP3 Text Data to Wireshark for
Automatic Decoding subsection.

Sample DNP3 Raw Text


[15:17:04.507] Tx => (10 Bytes)
05 64 05 C0 0A 00 64 00 37 68
[15:17:04.710] Rx <= (10 Bytes)
05 64 05 00 64 00 0A 00 B4 C6
[15:17:04.757] Tx => (27 Bytes)
05 64 14 C4 0A 00 64 00 09 29 C1 C1 01 3C 02
06 3C 03 06 3C 04 06 3C 01 06 62 01
[15:17:04.804]
05 64 D7 44 64
20 02 17 0A 03
01 D5 08 09 01
A8 FC 03 01 23
01 5B BC AE FE
01 01 01 01 01
01 01 01 01 01
02 00 00 06 01
00 00 00 00 00
32 00 00 06 00
00 00 5C D6 C7
00 00 00 00 00
00 00 00 00 00
02 00 1B 25 21
21 FF 7F 01 00
22 00 01 00 00
00 01 CD B8 00

Rx
00
01
C7
01
01
FD
01
01
00
76
FF
3E
00
FF
00
01
00

<=
0A
5A
FF
05
02
22
01
81
00
FE
00
17
00
7F
01
00
FF

(248 Bytes)
00 9E 9B C0
03 05 01 A2
0B 01 C7 FF
01 6C FF 07
00 00 1D 01
01 01 01 81
01 74 13 01
01 01 01 01
1E 04 00 00
04 00 A2 01
00 A2 01 00
00 00 00 00
00 FF FF 00
01 3B 1F 01
00 00 01 00
00 01 00 00
FF

[15:17:04.866]
05 64 08 C4 0A
05 64 0E C4 0A
00 07 07 00 32

Tx => (36 Bytes)


00 64 00 7A 86 C2 C1 00 0D 0E
00 64 00 A3 ED C3 C2 02 50 01
4B

E1
D3
0D
01
01
01
01
FE
1A
03
00
00
00
FD
00
28

81
53
01
23
01
01
01
56
12
00
BE
00
70
45
01
02

80
01
BE
01
01
01
01
14
00
76
FC
00
17
48
00
00

08
07
C1
09
01
01
0A
05
13
FE
00
00
1E
00
DA
00

[15:17:04.929] Rx <= (17 Bytes)


05 64 0A 44 64 00 0A 00 F4 3E C1 C2 81 00 00
33 03
[15:17:09.780] Tx => (24 Bytes)
05 64 11 C4 0A 00 64 00 80 D1 C4 C3 01 3C 02
06 3C 03 06 3C 04 06 1B 6F
[15:17:09.827]
05 64 36 44 64
20 02 17 0A 0B
01 5A 03 05 01
BE FF 03 01 80
01 EC 35 36 00

SEL Application Guide 2012-15

Rx
00
01
6A
04
FF

<=
0A
C7
04
05
FF

(67 Bytes)
00 05 60 C2
FF 0D 01 A2
07 01 6A 04
01 91 05 07

E3
01
0D
01

81
DE
01
91

00
01
C7
05

08
03
1B
09

Date Code 20121221

29

Sample DNP3 Formatted Text


000000 05 64 05 C0 0A 00 64 00 37 68
000000 05 64 05 00 64 00 0A 00 B4 C6
000000 05 64 14 C4 0A 00 64 00 09 29 C1 C1 01 3C 02 06
000010 3C 03 06 3C 04 06 3C 01 06 62 01
000000
000010
000020
000030
000040
000050
000060
000070
000080
000090
0000A0
0000B0
0000C0
0000D0
0000E0
0000F0

05
02
08
01
FE
FD
01
01
04
A2
00
00
70
48
DA
00

64
17
09
23
01
22
01
01
00
01
00
00
17
00
22
01

D7
0A
01
01
02
01
74
01
00
03
BE
00
1E
21
00
CD

44
03
C7
05
00
01
13
01
1A
00
FC
00
02
FF
01
B8

64
01
FF
01
00
01
01
FE
12
76
00
00
00
7F
00
00

00
5A
0B
6C
1D
81
01
56
00
FE
00
00
1B
01
00
00

0A
03
01
FF
01
01
01
14
13
00
00
00
25
00
01
FF

00
05
C7
07
01
01
01
05
32
00
00
00
21
00
00
FF

9E
01
FF
01
01
01
0A
00
00
5C
00
00
FF
01
00

9B
A2
0D
23
01
01
02
00
00
D6
00
00
7F
00
01

C0
D3
01
01
01
01
00
00
06
C7
3E
00
01
00
00

E1
53
BE
09
01
01
00
00
00
FF
17
00
3B
01
00

81
01
C1
01
01
01
06
00
76
00
00
FF
1F
00
28

80
07
A8
5B
01
01
01
00
FE
00
00
FF
01
00
02

08
01
FC
BC
01
01
01
00
04
A2
00
00
FD
01
00

20
D5
03
AE
01
01
81
1E
00
01
00
00
45
00
00

000000 05 64 08 C4 0A 00 64 00 7A 86 C2 C1 00 0D 0E
000000 05 64 0E C4 0A 00 64 00 A3 ED C3 C2 02 50 01 00
000010 07 07 00 32 4B
000000 05 64 0A 44 64 00 0A 00 F4 3E C1 C2 81 00 00 33
000010 03
000000 05 64 11 C4 0A 00 64 00 80 D1 C4 C3 01 3C 02 06
000010 3C 03 06 3C 04 06 1B 6F
000000
000010
000020
000030
000040

Date Code 20121221

05
02
03
01
00

64
17
05
80
FF

36
0A
01
04
FF

44
0B
6A
05

64
01
04
01

00
C7
07
91

0A
FF
01
05

00
0D
6A
07

05
01
04
01

60
A2
0D
91

C2
01
01
05

E3
DE
C7
09

81
01
1B
01

00
03
BE
EC

08
01
FF
35

20
5A
03
36

SEL Application Guide 2012-15

30

Sample DNP3 Formatted Text With Time Stamp


15:17:04.507
000000 05 64 05 C0 0A 00 64 00 37 68
15:17:04.710
000000 05 64 05 00 64 00 0A 00 B4 C6
15:17:04.757
000000 05 64 14 C4 0A 00 64 00 09 29 C1 C1 01 3C 02 06
000010 3C 03 06 3C 04 06 3C 01 06 62 01
15:17:04.804
000000 05 64
000010 02 17
000020 08 09
000030 01 23
000040 FE 01
000050 FD 22
000060 01 01
000070 01 01
000080 04 00
000090 A2 01
0000A0 00 00
0000B0 00 00
0000C0 70 17
0000D0 48 00
0000E0 DA 22
0000F0 00 01

D7
0A
01
01
02
01
74
01
00
03
BE
00
1E
21
00
CD

44
03
C7
05
00
01
13
01
1A
00
FC
00
02
FF
01
B8

64
01
FF
01
00
01
01
FE
12
76
00
00
00
7F
00
00

00
5A
0B
6C
1D
81
01
56
00
FE
00
00
1B
01
00
00

0A
03
01
FF
01
01
01
14
13
00
00
00
25
00
01
FF

00
05
C7
07
01
01
01
05
32
00
00
00
21
00
00
FF

9E
01
FF
01
01
01
0A
00
00
5C
00
00
FF
01
00

9B
A2
0D
23
01
01
02
00
00
D6
00
00
7F
00
01

C0
D3
01
01
01
01
00
00
06
C7
3E
00
01
00
00

E1
53
BE
09
01
01
00
00
00
FF
17
00
3B
01
00

81
01
C1
01
01
01
06
00
76
00
00
FF
1F
00
28

80
07
A8
5B
01
01
01
00
FE
00
00
FF
01
00
02

08
01
FC
BC
01
01
01
00
04
A2
00
00
FD
01
00

20
D5
03
AE
01
01
81
1E
00
01
00
00
45
00
00

15:17:04.866
000000 05 64 08 C4 0A 00 64 00 7A 86 C2 C1 00 0D 0E
15:17:04.866
000000 05 64 0E C4 0A 00 64 00 A3 ED C3 C2 02 50 01 00
000010 07 07 00 32 4B
15:17:04.929
000000 05 64 0A 44 64 00 0A 00 F4 3E C1 C2 81 00 00 33
000010 03
15:17:09.780
000000 05 64 11 C4 0A 00 64 00 80 D1 C4 C3 01 3C 02 06
000010 3C 03 06 3C 04 06 1B 6F
15:17:09.827
000000 05 64
000010 02 17
000020 03 05
000030 01 80
000040 00 FF

36
0A
01
04
FF

SEL Application Guide 2012-15

44
0B
6A
05

64
01
04
01

00
C7
07
91

0A
FF
01
05

00
0D
6A
07

05
01
04
01

60
A2
0D
91

C2
01
01
05

E3
DE
C7
09

81
01
1B
01

00
03
BE
EC

08
01
FF
35

20
5A
03
36

Date Code 20121221

31

FACTORY ASSISTANCE
We appreciate your interest in SEL products and services. If you have questions or comments,
please contact us at:
Schweitzer Engineering Laboratories, Inc.
2350 NE Hopkins Court
Pullman, WA 99163-5603 USA
Telephone: +1.509.332.1890
Fax: +1.509.332.7990
www.selinc.com info@selinc.com

Date Code 20121221

SEL Application Guide 2012-15

32

2012 by Schweitzer Engineering Laboratories, Inc.


All rights reserved.
All brand or product names appearing in this document are
the trademark or registered trademark of their respective
holders. No SEL trademarks may be used without written
permission.
SEL products appearing in this document may be covered by
U.S. and Foreign patents.

SEL Application Guide 2012-15

*AG2012-15*
Date Code 20121221