Question

 struct mgmt_header_t {
    u_int16_t   fc;     /* 2 bytes */
    u_int16_t   duration;   /* 2 bytes */
    u_int8_t    da[6];      /* 6 bytes */
    u_int8_t    sa[6];      /* 6 bytes */
    u_int8_t    bssid[6];   /* 6 bytes */
    u_int16_t   seq_ctrl;   /* 2 bytes */
};

void my_callback(u_char *args, const struct pcap_pkthdr *header, const u_char *packet)
{
    //printf("********* New Packet Arrived *********\n");
    //printf("Jacked a packet with length [%d]\n", header->len);    

    struct mgmt_header_t *mac_header = (struct mgmt_header_t *) (packet+24);
    if (mac_header->fc > 255 )
        printf("comon");

I know the mac_header is in the right place because i’m getting the mac addresses from it and they are correct but the problem is with fc it’s never greater than 255 so always the left byte is zero

UPDATE:

---

I think i got it right now thanks for guy and ott–
for reference here’s my complete example http://pcap-wireless.blogspot.com/2011/11/post-2-80211-mac-header.html

Answer 1

To quote section 7.1.1 “Conventions” of IEEE Std 802.11-2007:

In figures, all bits within fields are numbered, from 0 to k, where the length of the field is k + 1 bits. The octet boundaries within a field can be obtained by taking the bit numbers of the field modulo 8. Octets within numeric fields that are longer than a single octet are depicted in increasing order of significance, from lowest numbered bit to highest numbered bit. The octets in fields longer than a single octet are sent to the PLCP in order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits.

“The octets in fields longer than a single octet are sent to the PLCP in order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits.” means that the fields are transmitted in little-endian order, not big-endian order. Therefore, a 16-bit field with the value 0x0080 would be transmitted as an octet (byte) with the value 0x80 followed by an octet with the value 0x00.

This means that in the Wiretap hex dump, you’ll see 80 00, but that means 0x0080, not 0x8000.

BTW, note that a radiotap header is not guaranteed to be 24 bytes long; the header includes a (little-endian) length field specifying how long the header is.