Where can I find more information about the tvb_get_guint8( ) function? asked 25 Mar '15, 13:45  Amato_C edited 26 Mar '15, 13:18  Jaap ♦ showing 5 of 7 show 2 more comments |
One Answer:
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 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 |
Tvbuff.h but as the function name implies it fetches a byte from the tvb at offset. What more information are you want?
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.
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.
Should I create a Wireshark bug for this issue?
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.
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.
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.