This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Unknown bytes in GOOSE packet

0

I can read ALMOST every byte now in the pcap file mentioned in this question, thanks to Guy_Harris.c. All but 5 bytes. 5 bytes.

Frame 2 of this file is a GOOSE package, according to Wireshark. The length is 161 bytes:

01 a0 f4 04 9c 5f 00 a0 f4 04 9c 5f 88 b8 00 00 00 93 00 00 00 00 61 81 88

80 1a (26 bytes) 81 02 23 28 82 18 (24 bytes) 83 0e (14 bytes) 84

08 00 00 00 00 00 00 00 3f 85 01 01 86 03 01 e3 68 87 01 00 88 01 01 89 01

00 8a 01 02 ab 1e 84 09 00 55 55 55 55 55 55 55 55 84 11 00 55 55 55 55 55

55 55 55 55 55 55 55 55 55 55 55

I removed the GOOSE ID so I don't get into trouble.

Now, I have no trouble understanding the first 22 bytes:

01 a0 f4 04 9c 5f from nic

00 a0 f4 04 9c 5f to nic

88 b8 packet type (goose)

00 00 application ID

00 93 PDU Length 0x00000093 or 147

00 00 reserved 1

00 00 reserved 2

but Wireshark doesn't tell me what the next 3 bytes are:

61 81 88 what's this???

before telling me I have a 26 byte Control Block Ref:

80 1a

follow by the time allowed to live 9000 msec

81 02 23 28

Dataset ref:

82 18

84 08 00 00 00 00 00 00 00 3f Event Timestamp: 1970-01-01 00:00.0.00000; Timeequality: 3F

85 01 01 StateNumber: last byte 01 = 1

86 03 01 e3 68 Sequence Number: 01 e3 68 = 123752

87 01 00 Simulation bit: last byte 00 = FALSE,

88 01 01 Config Revision: last byte 01 = 1

89 01 00 Needs commissioning: last byte 00 = FALSE

8a 01 02 Number Dataset Entries: last byte 02 = 2

and now comes 2 bytes Wireshark doesn't say what it is:

ab 1e What's this ????

before displaying the rest of the payload. So what are these 5 bytes?

asked 08 Feb '13, 15:40

ecs1749's gravatar image

ecs1749
21●7●8●11
accept rate: 0%

edited 08 Feb '13, 20:26

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k●3●35●196

2 Answers:

2

The first 14 bytes are specified by the Ethernet specification (IEEE 802.3).

The next 8 bytes are as per Annex C, Figure C. 1 of IEC 61850-8-1 (note that, in that figure, the frames have a VLAN tag, while the frame in your capture has no VLAN tag, so the offsets in the frame are different).

What follows, again as per Annex C, Figure C. 1, is an "APDU", meaning an Application-layer Protocol Data Unit. Section 6.3.2 "A-Profile" of IEC 61850-8-1 says that the specification for the GSE/GOOSE protocol is in Annex A, and that "The presentation layer encoding shall be Basic Encoding Rules as defined in ISO/IEC 8824-1 and ISO/IEC 8825-1 to encode the grammar referenced."

Annex A contains the Abstract Syntax Notation One (ASN.1) syntax of a GSE/GOOSE PDU, which starts with

IEC 61850-8-1 Specific Protocol ::= CHOICE {
    gseMngtPdu     [APPLICATION 0] IMPLICIT GSEMngtPdu,
    goosePdu       [APPLICATION 1] IMPLICIT IECGoosePdu,
    ...}

A GOOSE PDU would thus start with the Basic Encoding Rules (BER) tag for [APPLICATION 1]. The type identifier octet in that tag would, as per the WIkipedia article on BER linked above, have the bits 01 1 00001, for "Application" (01), "Constructed" (1 - a GOOSE PDU is not a primitive BER data type), 0 (00001). That's the 0x61.

Following that are the length octets of the tag. The first octet is 0x81; that has the uppermost bit set, so the length is in the "long form", and the remaining bits are the value 1, meaning that there's one more length octet. That octet has the value 0x88, which is 136, so there are 136 bytes of data in the PDU.

Normally, when dissecting data encoded using ASN.1's Basic Encoding Rules (such as, for example, SNMP or LDAP traffic), people are interested in what's been encoded, not the details of how it was encoded, so, by default, Wireshark does not show the dissection of BER tag information when dissecting BER-encoded packets.

For those cases when people are interested in the details of how BER-encoded information is encoded - for example, if they're trying to investigate a bug in the encoding, or trying to determine what some particular bytes in a packet are - you can turn on a preference to get Wireshark to show the details. Open up Edit -> Preferences, select the "Protocols" list, look for the "BER" protocol, check the "Show internal BER encapsulation tokens" checkbox, and click "OK". Wireshark will then show the gory details of BER tags.

If you want to see what all the bytes are in your GOOSE packet, you will have to do that.

answered 08 Feb '13, 20:24

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k●3●35●196
accept rate: 19%

Your "answer" has been converted to a comment as that's how this site works. Please read the FAQ for more information.

(11 Feb '13, 10:31) grahamb ♦

Sorry, "as per Annex C, Figure C. 1" was a bit confusingly stated.

What I meant was that the next 8 bytes are as per the stuff in that figure following the "Ethertype (see Table C.2)" field.

That figure shows a complete Ethernet packet, with a VLAN header, so it also shows the Ethernet header, as well as a VLAN tag; your packets don't have a VLAN tag, so you won't see the TPID or TCI; instead, what you'll see following the source address is the Ethertype.

"m" is the length of the GOOSE ASN.1-BER-encapsulated packet; see "APDU (of length m)" later in that figure.

(11 Feb '13, 10:53) Guy Harris ♦♦

"The first 14 bytes are specified by the Ethernet specification (IEEE 802.3)".

So, that's bytes 0-13 as per Annex C, Figure C. 1 of IEC 61850-8-1. My TPID is 0x88b8 because my frame doesn't have VLAN tag, or else it would be 0x8100. Do I understand that correctly?

(11 Feb '13, 11:08) ecs1749

"The next 8 bytes are as per Annex C, Figure C. 1 of IEC 61850-8-1 (note that, in that figure, the frames have a VLAN tag, while the frame in your capture has no VLAN tag, so the offsets in the frame are different)."

That would be TCI (2 bytes in my case), Ethertype (2 bytes), APPID (2 bytes), m+8 (2 bytes). But according to Wireshark, I have (no TCI, no Ethertype): APPID (2 bytes), m+8 (2 bytes), reserve 1 & 2 (4 bytes). Then APDU starts. So, what happened to TCI and Ethertype?

(11 Feb '13, 11:08) ecs1749

I understand what you said about the 61 81 88 Octets.

(11 Feb '13, 11:09) ecs1749

My TPID is 0x88b8 because my frame doesn't have VLAN tag, or else it would be 0x8100. Do I understand that correctly?

Not exactly. VLANs work by setting the last 2 bytes of the Ethernet header to 0x8100, so that the frame looks as if it has an EtherType value of 0x8100. Only if it has the value 0x8100 is it called the TPID field (Tag Protocol Identifier); otherwise, it's just the EtherType field.

That would be TCI (2 bytes in my case)

No. As your frame does not have a VLAN frame, it has no TCI, and the two bytes immediately after the source address are the Ethertype, not the TPID.

(11 Feb '13, 11:32) Guy Harris ♦♦
showing 5 of 6 show 1 more comments

0

I have never worked with the GOOSE protocol, but for the fun of it I tried to reverse engineer it a bit. As far as I can tell those bytes are probably a type and length indicator. In the sample trace I got from http://wiki.wireshark.org/Protocols/IEC61850GOOSEGSE there are many decoded fields in the "allData section" that have "gaps" when trying to match bytes to decoded value, and these are seemingly always type and length of the value that is shown.

So I guess that is what it is; the other thing I found in the specs I googled for was that there may be padding in some cases, but I haven't tried to verify this. Padding bytes may be arbitrary bytes, so it is futile to try to make some sense of them.

answered 08 Feb '13, 16:41

Jasper's gravatar image

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

As far as I can tell those bytes are probably a type and length indicator

Yes - GOOSE uses ASN.1 BER, as per my answer to this question, so, yes, they're type/length indicators.

(08 Feb '13, 20:25) Guy Harris ♦♦

But what about that ab 1e? These are the leading bytes of the Data block.

01 a0 f4 04 9c 5f 00 a0 f4 04 9c 5f 88 b8 00 00 00 93 00 00 00 00 61 81 88 80 1a (26 bytes) 81 02 23 28 82 18 (24 bytes) 83 0e (14 bytes) 84 08 00 00 00 00 00 00 00 3f 85 01 01 86 03 01 e3 68 87 01 00 88 01 01 89 01 00 8a 01 02

ab 1e<<<<< 84 09 00 55 55 55 55 55 55 55 55 84 11 00 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55

(11 Feb '13, 11:24) ecs1749

They're probably ASN.1 BER tag information. I spent a lot of time going through the first 3 bytes of the APDU to indicate what they are, and to check that the packet is, as I expected, using ASN.1 BER. I will NOT do any more such analysis; that's the sort of analysis that is best done by a program, not a human, and you already have a program that can do that analysis - it's called "Wireshark". As I already said in my answer, if you set a Wireshark preference, it will show you the BER tag information; the answer says how to do that. If you want to know what those bytes are, set that pref.

(11 Feb '13, 11:35) Guy Harris ♦♦

Sorry, I forgot to mention that I did turn on BER as instructed. Still no info about these 2 bytes. I appreciate greatly about the help you offered to this point.

I will read further about the ASN.1 BER.

Thanks again.

(11 Feb '13, 12:26) ecs1749

Oh, my bad. I thought 1e is 31. "BONK". 1e is 30. So, it's total number of bytes inn the Data block. That's why its ab 1e.

(11 Feb '13, 12:41) ecs1749