Wireshark · Wireshark-dev: Re: [Wireshark-dev] regarding the structure of data packets

[Guy Harris <guy@xxxxxxxxxxxx>]

On Mar 13, 2012, at 4:20 PM, abhinav narain wrote:

> this is the packet dump of first  40 bytes,starting from mac header.
> 
> 88 41 2c 00 c4 3d c7 9d e1 44 00 19 d2 85 d1 67 c4 3d c7 9d e1 42 30 f0 00 00 2b 4f 00 20 00 00 00 00 aa aa 03 00 00 00 08 00
> 
> first four bytes are control bits and duration.

00001000 has a type field of 2

88 41 is the control bits, so that's

	1000 1000 0100 0001

which is:

	Protocol Version: 00
	Type: 10
	Subtype: 1000

	Order: 0
	Protected frame: 1
	More data: 0
	Pwr Mgt: 0

	Retry: 0
	More Frag: 0
	From DS: 0
	To DS: 1

so that's a QoS data frame going to the AP.	

> next are the mac addresses.
> c4 3d c7 9d e1 44
> 00 19 d2 85 d1 67 
> c4 3d c7 9d e1 42
> seq control
> 30 f0
> 
> I don't understand what to get for 10 bytes following it before I can check for aa aa, the llc header values. 

So, since this is a QoS frame, the next two bytes after the Sequence Control field are the QoS Control field: 00 00.

> tcpdump code, also increments by 26 bytes

That's the 2-byte frame control field, the 2-byte duration field, 3 6-byte MAC addresses, a 2-byte sequence control field, and a 2-byte QoS field.

> and calls llc print with packet pointer at the byte which is 26th from the start of the mac header, but I don't find it to work here as there are clearly unknown bytes before llc header can be read, which I don't know how to get meaning of.
> 
> After the 26 bytes mac header length, I had to increment the pointer by 8 bytes more to point to aa aa (LLC header) .
> I don't understand what these 8 bytes are ? and how to interpret them.
> 
> I am working on OpenWrt platform and using recvfrom on a  raw socket to get the packets.

Well, that's a protected frame, but it appears to have a decrypted SNAP header, so it appears that either the hardware or the driver is handing decrypted packets to you with the "Protected frame" bit set.

As it's a protected frame, it was presumably using WEP or WPA/WPA2.  See

	http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

for information on WEP and

	http://en.wikipedia.org/wiki/Wi-Fi_Protected_Access

for information on WPA and WPA2.

If it's WEP, then, according to IEEE Std 802.11-2007 section 8.2.1.2 "WEP MPDU format", the payload, before decryption, starts with a 4-byte IV, followed by the encrypted frame body, followed by a 4-byte ICV.

If it's WPA with TKIP, then, according to section 8.3.2.2 "TKIP MPDU formats", the payload, before decryption, starts with a 4-byte IV/KeyID, followed by a 4-byte Extended IV, followed by the encrypted frame body, followed by an 8-byte MIC, followed by a 4-byte ICV.

If it's WPA with CCMP, then, according to section 8.3.3.2 "CCMP MPDU format", the payload, before decryption, starts with an 8-byte CCMP Header, followed by the encrypted frame body, followed by an 8-byte MIC.

Perhaps you're on a WPA network using TKIP or CCMP and you're getting from the hardware the IV/KeyID and Extended IV, or the CCMP Header, followed by the *decrypted* frame body.  (WEP is rather weak - see the Wikipedia article in question - so the network is probably using WPA or WPA2.)

Perhaps this is documented somewhere in the Linux documentation, or perhaps it isn't.  I don't know.