Wiresharking IEC

Some basic filters for analysing wireshark logs in case of IEC protocols.

IEC60870-5-104

If you use some port other than 2404, then Wireshark will not automatically detect the correct protocol. In this case,

1. select a IEC104 packet from the captured packets list,
2. go to Analyse -> Decode as
3. In the transport tab, select TCP : both ports and protocol 104apci
   

Dispaly packages with TCP length>0 (no ack messages)

tcp.len>0

IEC104 packages

104apci

IEC104 packages (without testframes, S-packets etc)

104asdu

Packets involving 192.168.0.111

ip.addr==192.168.0.111

TCP port 2404

tcp.port==2404

Information object address 401

 104asdu.ioa == 401 

Spontaneous events (COT==3)

104asdu.causetx == 3

Command messages (COT 6, 7, 10)

104asdu.causetx == 6  //Activation
104asdu.causetx == 7   //Confirmation
104asdu.causetx == 10   //Termination

Testframe messages

104apci.utype == 0x10   //Activation
104apci.utype == 0x20   //Confirmation

S-Type messages

104apci.type == 0x01

General Interrogation commands

104asdu.typeid == 100   //Global, Group1...Group16
104asdu.qoi == 20       //Global
104asdu.qoi == 21       //Group1
104asdu.qoi == 35       //Group15
                        Do not use Group 16 GI with Martem devices. This is reserved.

Clock syncronisation commands

104asdu.typeid == 103

Show IEC104 measurements with value "0"

IEC104asdu.normval == 0

IEC61850 and Wireshark basics

MMS: Manufacturing Message Specification GOOSE: Generic Object Oriented Substation Events

Filter IEC61850 packets

 mms 

Display packets involving TCP port 102

tcp.port==102

Display messages containing domain ID "VampRelay"

mms.domainId == "VampRelay"

Display messages containing item ID "VI1GGIO137$CO$SPCSO$Oper" (VI1 control command)

mms.itemId == "VI1GGIO137$CO$SPCSO$Oper"

Display messages containing control commands (Service request 5 = write)

mms.confirmedServiceRequest == 5

Dispaly packets containing message "success" (response to command message)

mms.Write_Response_item == 1

Wireshark capture side-by-side with console.log

Case study: GW6e connects with Vamp255 device over IEC61850. RTU initializes communication, sends GI, executes a SBO command and receives a report (spontaneous) about change of LN state.

Step1. RTU starts connecting to the IED with a TCP-handshake (3-way handshake):

6	2015-08-06 10:29:59.943110	10.0.0.104	172.16.1.3	TCP	74	56642→102 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=2023 TSecr=0 WS=64
7	2015-08-06 10:30:02.443727	172.16.1.3	10.0.0.104	TCP	60	102→56642 [SYN, ACK] Seq=0 Ack=1 Win=2047 Len=0
8	2015-08-06 10:30:02.443952	10.0.0.104	172.16.1.3	TCP	54	56642→102 [ACK] Seq=1 Ack=1 Win=5840 Len=0

Step2. COTP (Connection Oriented Transport Protocol) connect request (CR) and connect confirmation (CC):

9	2015-08-06 10:30:02.444413	10.0.0.104	172.16.1.3	COTP	76	CR TPDU src-ref: 0x0001 dst-ref: 0x0000 (PDU Type: CR Connect Request (0x0e))
10	2015-08-06 10:30:02.539805	172.16.1.3	10.0.0.104	TCP	60	102→56642 [ACK] Seq=1 Ack=23 Win=2025 Len=0
11	2015-08-06 10:30:02.739731	172.16.1.3	10.0.0.104	COTP	76	CC TPDU src-ref: 0x0002 dst-ref: 0x0001 (PDU Type: CC Connect Confirm (0x0d))

Step 3. MMS CONNECT and ACCEPT

 
13	2015-08-06 10:30:02.740616	10.0.0.104	172.16.1.3	MMS	244	initiate-RequestPDU (ISO 8327-1 OSI Session Protocol -> SPDU Type: CONNECT (CN) SPDU (13)) MMS-> servicesSupportedCalling: list of services
15	2015-08-06 10:30:03.225870	172.16.1.3	10.0.0.104	MMS	212	initiate-ResponsePDU (ISO 8327-1 OSI Session Protocol -> SPDU Type: ACCEPT (AC) SPDU (14))

After successful MMS connection, RTU will write to console.log:

 
2015-08-06 10:30:03.227 [INFO] Gateway.Port14 - ASSOCIATE ok for 172.16.1.3 0