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

tvb_get_guint8( ) function / EAPOL message number

0

Where can I find more information about the tvb_get_guint8( ) function?

asked 25 Mar '15, 13:45

Amato_C's gravatar image

Amato_C
1.1k142032
accept rate: 14%

edited 26 Mar '15, 13:18

Jaap's gravatar image

Jaap ♦
11.7k16101

Tvbuff.h but as the function name implies it fetches a byte from the tvb at offset. What more information are you want?

(25 Mar '15, 13:52) Anders ♦

I was able to determine that the tvb_get(tvb,offset) function tells Wireshark the length of the data to highlight in the hex display window with tvb starting at the beginning of the data passed to the dissector and the offset parameter is the location in bytes within the dissector. However, I was unable to answer my original question.
I believe that Wireshark is not labeling the EAPOL key messages correctly when WPA Key descriptors are used. Please see capture at: https://drive.google.com/file/d/0B9Lstpa35JuGVzRibmYyazhFeUE/view?usp=sharing

Please refer to packets #9 and #11. They are both labelled as Message 4 of 4. However, packet #9 should be Message 2 of 4. I tried to determine what was causing the error. I found the dissectors-packet-ieee80211.c file and investigated lines 18327 through 18345. The dissector is using the following to distinguish between Message 2 and Message 4: counter = tvb_get_guint8(tvb, offset+11) So why does the capture show both packet #9 and packet#11 as Message 4? Message 2 should not have counter set - refer to line 18336 in the dissector file.

(26 Mar '15, 08:26) Amato_C

It looks to me to be a dissector bug in that it simplistically expects the first byte of the 8 byte replay counter to be 0 for message 2 and non-zero for message 4. IIUC the spec says simply that the replay counter should be incremented by the Authenticator, i.e. message 4 should have a replay counter that is 1 more that that in message 2.

(26 Mar '15, 09:52) grahamb ♦

Should I create a Wireshark bug for this issue?

(26 Mar '15, 10:25) Amato_C

Yes, although I'm uncertain if the replay counter should always be set to 0 for the first message, but I think that's unlikely as it then doesn't have much point in being there.

(26 Mar '15, 10:32) grahamb ♦

I agree about the counter being 0. However, the logic should determine the counter values in Message 2 and Message 4. Then determine the message type where counter for Message 2 < counter for Message 4.

(26 Mar '15, 10:43) Amato_C

This error has already reported. Please refer to bug #10557. It was originally reported in October 2014 as a possible driver issue. However, it appears to be a dissector issue.

(26 Mar '15, 10:53) Amato_C
showing 5 of 7 show 2 more comments

One Answer:

1

Bug #10557 (EAPOL key message #2 is incorrectly labeled as Message 4 of 4 when WPA Key descriptors are used) is resolved.

answered 02 Apr '15, 10:28

Amato_C's gravatar image

Amato_C
1.1k142032
accept rate: 14%

What is the logic for wireshark to flag EAPOL packet as 1/2/3/4 of 4th packet? There is no such flag as such carried in packet.

(03 Apr '15, 11:27) Ramprasad

It depends whether the key descriptor is defined as WPA (0xFE) or RSN (0x02). New wireless routers/AP's should be utilizing RSN. In that case, the Key Information field within the 802.1X Authentication has certain parameters that define an EAPOL message as 1, 2 ,3 or 4. You can refer to the IEEE 802.11-2012 specification (sections 11.6.6.2 through 11.6.6.5) for these settings. You can download spec from IEEE website.

(03 Apr '15, 12:34) Amato_C