Re: [tcpdump-workers] regarding wireless data frames

[Guy Harris <guy () alum mit edu>]

On Mar 8, 2012, at 4:47 PM, abhinav narain wrote:

> I have seen tcpdump,wireshark both just print packet contents till mac
> header in monitor mode.
> In case of normal wireless interfaces (wlan0), they follow a different
> execution path.

No, it's not based on the type of interface, or the mode of the interface.  It's based on whether the 802.11 payload 
has been decrypted or not; if you're capturing in monitor mode most frames are probably encrypted, but if you're not 
capturing in monitor mode and seeing only frames to or from your machine, they're probably decrypted.

> Can someone tell me what should I expect in the the frame after
> ieee80211_hdr (which comes after the radiotap header)  ?

Yes.

First of all, if the Protected Frame field bit is set (and the adapter or driver hasn't decrypted the packet but left 
that bit set), what follows the 802.11 header is a bunch of encrypted data, which can only be decrypted if you have 
enough information to decrypt it (which, for the non-enterprise version of WPA, means you need the password for the 
network *and* the initial setup frames):

        7.1.3.1.8 Protected Frame field
        The Protected Frame field is 1 bit in length. The Protected Frame field is set to 1 if the Frame Body field 
contains information that has been processed by a cryptographic encapsulation algorithm. The Protected Frame field is 
set to 1 only within data frames and within management frames of subtype Authentication. The Protected Frame field is 
set to 0 in all other frames. When the Protected Frame field is set to 1, the Frame Body field is protected utilizing 
the cryptographic encapsulation algorithm and expanded as defined in Clause 8. The Protected Frame field is set to 0 in 
Data frames of subtype Null Function, CF-ACK (no data), CF-Poll (no data), and CF-ACK+CF-Poll (no data) (see 8.3.2.2 
and 8.3.3.1, which show that the frame body must be 1 octet or longer to apply the encapsulation).

What the decrypted data (if the frame was encrypted) or the unencrypted data (if the frame wasn't encrypted) is then 
depends on the type and subtype fields.

> According to my knowledge, I assume if the control frame bit with
> Is it an llc header with a general format :
> struct llc_hdr {
>  uint8 dsap;
>  uint8 ssap;
>  struct {
>    uint8 ui;
>    uint8 org_code[3];
>    uint16 ether_type;
>  } snap;
> };

Well, if the type is a data frame, then the payload, *once it's been decrypted if it was encrypted*, begins with an 
802.2 LLC header.  That's not determined by a single bit, but by a 2-byte type field (and a 4-byte subtype field, as 
some data frames have no data).

802.2 headers don't necessarily have an organization code or protocol ID field - that's the case only for SNAP frames, 
where the DSAP and SSAP are 0xAA - and, for SNAP frames, the protocol ID field is an Ethernet type only if the 
organization code is 00:00:00.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe