Re: regarding the structure of data packets

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

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.
___________________________________________________________________________
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