Блог

  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");
  

Я знаю, что mac_header находится в нужном месте, потому что я получаю от него mac-адреса, и они правильные, но проблема в том, что с fc он никогда не превышает 255, поэтому всегда левый байт равен нулю

Обновить:

Я думаю, что понял это прямо сейчас, спасибо за guy и ott — для справки вот мой полный пример http://pcap-wireless.blogspot.com/2011/11/post-2-80211-mac-header.html

Процитируем раздел 7.1.1 «Соглашения» стандарта IEEE 802.11-2007:

На рисунках все биты в полях пронумерованы от 0 до k, где длина поля равна k 1 биту. Границы октетов внутри поля могут быть получены путем вычисления разрядных чисел поля по модулю 8. Октеты в числовых полях, длина которых превышает один октет, отображаются в порядке возрастания значимости, от бита с наименьшим номером к биту с наибольшим номером. Октеты в полях длиннее одного октета отправляются на PLCP в порядке от октета, содержащего младшие пронумерованные биты, до октета, содержащего старшие пронумерованные биты.

«Октеты в полях длиннее одного октета отправляются на PLCP в порядке от октета, содержащего младшие пронумерованные биты, до октета, содержащего старшие пронумерованные биты». означает, что поля передаются в порядке младшего конца, а не в порядке большого конца. Следовательно, 16-разрядное поле со значением 0x0080 будет передаваться в виде октета (байта) со значением 0x80, за которым следует октет со значением 0x00.

Это означает, что в шестнадцатеричном дампе записи вы увидите 80 00, но это означает 0x0080, а не 0x8000.

Кстати, обратите внимание, что длина заголовка radiotap не гарантируется в 24 байта; заголовок включает поле длины (с малым порядком окончания), определяющее длину заголовка.

Первые 8 бит fc поля или ноль, когда это запрос на ассоциацию. Но разве вы не пропускаете заголовок, назначая (пакет 24)? Можете ли вы добавить шестнадцатеричный дамп из первых 32 байт пакета?