Wireshark-bugs: [Wireshark-bugs] [Bug 9909] Buildbot crash output: fuzz-2014-03-20-27222.pcap
Comment # 22
on bug 9909
from Guy Harris
(In reply to comment #21)
> (In reply to comment #17)
> > The long answer is the isDMG is only supposed to be true if the packet was
> > running in the 802.11ad frequency, which EAPOL wouldn't be. (it only runs on
> > Ethernet frames, apparently)
>
> Nope. 802.1X might originally have been intended for Ethernet, but I
> suspect the most common use is on 802.11 LANs these days with WPA/WPA2.
>
> However, given that it's 802.1X, not 802.11X, it seems odd that it's calling
> back to the 802.11 dissector. I'll have to read the 802.1X spec and see how
> it works with various LAN technologies and see if that can be improved.
802.11i-2004 says in section 8.5.2 "EAPOL-Key frames"
j) Key Data. This field is a variable-length field that is used to include
any additional data required for the key exchange that is not included in the
fixed fields of the EAPOL-Key frame. The additional data may be zero or more
information element(s) (such as the RSN information element) and zero or more
key data encapsulation(s) (KDEs) (such as GTK(s), STAKey(s), or PMKID(s)).
Information elements sent in the Key Data field include the Element ID and
Length subfields. KDEs shall be encapsulated using the format in Figure 43w.
...
The Type field shall be set to 0xdd. The Length field specifies the
number of octets in the OUI, Data Type, and Data fields. The order of the OUI
field shall follow the ordering convention for MAC addresses from 7.1.1.
0xdd = 221, and 802.11-2012 Table 8-54 "Element IDs" says that an element ID of
221 is for "vendor-specific" information.
So I guess EAPOL-Key frames *for 802.11i* do have a set of 802.11 IEs in the
Key Data field.
You are receiving this mail because:
- You are watching all bug changes.
