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.
