wifi - Ethernet II and Data following 802.11 Data frame? -

i watching several wifi captures in wireshark , bumped 2 specimens had never seen before. first of all, thought ieee 802.11 data frame followed llc header (802.2), provided frame contained data. have 2 wireshark captures showing otherwise !

first one, can see ethernet ii header following wifi header :

now that's first thing don't understand. how interface supposed know, when reading 802.11 data header, going ethernet ii following ? there no field in 802.11 header specifying what's coming next.

second "raw data" directly following wifi header.

same question before, how supposed know data following, , not llc ?

first question:

to quote comment in wireshark 802.11 dissector:

  /* guess bridges take netware ethernet_802_3 frames,      802.3 frames (with length field rather      type field, no 802.2 header in payload),      , stick payload 802.11 frame.  i've seen      captures show frames of sort. 

there no field in header says "this bridged netware ethernet_802_3 frame", wireshark has use heuristic. heuristic "if first 2 bytes of payload not both 0xaa, first 6 bytes of payload equal destination mac address, , next 6 bytes of payload equal source mac address, bridged netware ethernet_802_3 frame", in case calls ethernet dissector. because heuristic, is, of course, not guaranteed correct answer time.

ieee std 802.11-2012 says, in section 5.1.4 "msdu format":

this standard part of ieee 802 family of lan standards, , such msdus llc pdus defined in iso/iec 8802-2: 1998. in order achieve interoperability, implementers recommended apply procedures described in iso/iec technical report 11802-5:1997(e) (previously known ieee std 802.1h-1997 [b21]), along selective translation table (stt) handles few specific network protocols, specific attention operations required when passing msdus or lans or operating system components use ethernet frame format. note such translations may required in sta.

"iso/iec 8802-2: 1998" ansi/ieee std 802.2, 1998 edition, says payload should begin 802.2 header. @ least read ieee std 802.1h-1997, ethernet frames without 802.2 header should translated snap frames, using ethernet type value, when bridged lan using 802.2, such 802.11 lan. guess, since netware ethernet_802_3 frames don't have valid 802.2 llc header and don't have type field (they have length field; think that, don't have 802.2 header following ethernet header, means technically aren't valid ethernet frames), aren't covered specifications in question, it's not technically protocol error put ethernet packet, starting ethernet header, data field. presumably packets sent bridges, under assumption bridge knows how right thing.

second question:

the common reason see "data" after 802.11 header packet in question encrypted (wep or wpa/wpa2) , wireshark doesn't have password network (and, wpa/wpa2 personal/pre-shared key mode, doesn't have initial eapol handshake in capture; decrypting in enterprise/802.1x mode not supported).

are capturing on "protected" (wep or wpa/wpa2) network?