Wireshark-dev: Re: [Wireshark-dev] [tcpdump-workers] regarding wireless data frames
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.
