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 <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
