I don't know how efficient this Lua post-dissector solution is or if indeed it's bullet-proof under all possible corner cases, but through much pain, I was able to get some output that seems to be correct using the iec104.pcap file on the Wireshark wiki that @Chuckc linked above for testing.
Using TShark (Wireshark) 4.3.0 (v4.3.0rc0-2286-ga16241b23f3f), here is some sample output when running tshark -r iec104.pcap -Y "iec60870_asdu.typeid == 36" -q:
16) TypeId: 36
IOA: 11
Float: 0.0
CP56Time: Jul 4, 2013 08:23:04.145000000 Eastern Daylight Time
IOA: 12
Float: 0.0
CP56Time: Jul 4, 2013 08:23:04.145000000 Eastern Daylight Time
IOA: 13
Float: 0.0
CP56Time: Jul 4, 2013 08:23:04.145000000 Eastern Daylight Time
IOA: 14
Float: 0.0
CP56Time: Jul 4, 2013 08:23:04.145000000 Eastern Daylight Time
18) TypeId: 36
IOA: 11
Float: 0.0
CP56Time: Jul 4, 2013 08:23:04.145000000 Eastern Daylight Time
IOA: 12
Float: 0.0
CP56Time: Jul 4, 2013 08:23:04.145000000 Eastern Daylight Time
IOA: 13
Float: 0.0
CP56Time: Jul 4, 2013 08:23:04.145000000 Eastern Daylight Time
IOA: 14
Float: 0.0
CP56Time: Jul 4, 2013 08:23:04.145000000 Eastern Daylight Time
88) TypeId: 36
IOA: 12
Float: 9.8699998855591
CP56Time: Jul 4, 2013 08:24:14.307000000 Eastern Daylight Time
Since this site doesn't seem to allow files of type .lua to be uploaded, and I can't find any setting to change to allow it, I renamed the file with a .txt extension instead, so you will have to rename it back to .lua to test it yourself.
C:\fakepath\iec60870post.txt
(Sample capture (iec104.pcap IEC 60870-5-104 communication log.) available on Wireshark Wiki - IEC 60870-5-104)
For frame 88, it's one set of fields:
Frame 88: 101 bytes on wire (808 bits), 101 bytes captured (808 bits) Ethernet II, Src: ZAT_00:09:05 (00:16:d1:00:09:05), Dst: ASUSTekCOMPU_56:0b:54 (00:22:15:56:0b:54) Internet Protocol Version 4, Src: 10.20.100.108, Dst: 10.20.102.1 Transmission Control Protocol, Src Port: 2404, Dst Port: 46413, Seq: 2245, Ack: 339, Len: 47 IEC 60870-5-104: -> I (73,16) IEC 60870-5-101/104 ASDU: ASDU=10 C_SE_NC_1 ActTerm IOA=12 'set point command, short floating point number' IEC 60870-5-104: -> I (74,16) IEC 60870-5-101/104 ASDU: ASDU=10 M_ME_TF_1 Spont IOA=12 'measured value, short floating point number with time tag CP56Time2a' TypeId: M_ME_TF_1 (36) 0... .... = SQ: False .000 0001 = NumIx: 1 ..00 0011 = CauseTx: Spont ...(more)I was not familiar with these sample captures, but those surely helps as a common reference.
You are correct that frame 16 should return multiple sets of fields (ref. "For each iec60870_asdu.IOA" in my pseudo code) which should result in individual lines of console output from my pseudo code.
If it were easy this similar question would be answered. :-)
When parsing hci log with tshark, how to print only the btcommon.eir_ad.entry.uuid_16 associated with the btcommon.eir_ad.entry.type?
This might be something that WSUG - MATE (shudder, shakes head) could be used for. I'll need to experiment.
Have some ideas for doing with Lua but nothing I'm confident enough in to share. :-)
There cannot be two identical AVPs in the same AVPL
So close with MATE then the wheels fall off - will not extract multiple copies of a field with the same value.
Works great for frame 88 with only one set of values. For 16 and 18, only one copy of float and cp56time are extracted since the values are equal. :-( Back to the drawing board.
Thanks for your interest on this challenge!
I did end up using the "Export Packet Dissections" --> "As JSON...", made sure to check "Packet details" only and select "All expanded" to get a JSON export. Then I managed to create a working, yet brittle, bit of Python code to interpret the JSON-data. Including a pretty specific simple JSON decoder returning a list instead of a dict, so that I finally could use the built-in json.loads() to decode each IOA and return a CSV-list of every typeid==36
Python’s json.load() does return a dict, which causes only the last of identical JSON-keys to be returned. Seemingly a similar limitation as you experienced with MATE. For me this turned out to be a limitation on several levels of the Wireshark JSON export. Firstly, there can be several "iec60870_asdu" in one frame, but even after solving that I missed data ...(more)