Интерпретация байтов управления кадрами в трассе 802.11 Wireshark

У меня есть захват Wi-Fi (.pcap), который я анализирую и столкнулся с тем, что представляется мне несоответствием между спецификацией 802.11 и интерпретацией данных Wireshark. В частности, я пытаюсь разделить это 2-байтное поле управления 802.11 Frame Control.

Взято из http://www4.ncsu.edu/~aliu3/802.bmp, формат подполей поля управления кадрами выглядит следующим образом:

И ниже приведена крышка экрана Wireshark пакета, которая меня смутила:

Итак, как показано на снимке экрана Wireshark, часть флагов (последние 8 бит) поля управления кадрами равна 0x22, что отлично. То, как версия/тип/подтип 0x08 совпадает с описанием Wireshark фрейма, - это то, что меня смутило.

0x08= 0000 1000b, который, как я думал, переводится в Версию = 00, Type = 00 (который, как я думал, означает управление не фреймом данных) и Subtype = 1000 (который, как я думал, будет рама маяка). Поэтому я ожидал бы, что этот кадр будет рамкой управления и, более конкретно, фреймом маяка. Однако Wireshark сообщает об этом как о кадре данных. Второе, что меня путает, - это то, где Wireshark даже тянет 0x20 из строки Type/Subtype: Data (0x20).

Может ли кто-нибудь уточнить мою интерпретацию спецификации 802.11 spec/Wireshark для меня и почему эти два несовместимы?

Ответ 1

Кадр данных в вашем примере равен 0x08 из-за макета этого байта управления кадрами (FC). 0x08 = 00001000 - Первые 4 бита (0000) являются подтипом. 0000 является подтипом этого кадра - Следующие 2 бита (10) - это тип, который равен 2 десятичным и, следовательно, кадру типа данных - Последние 2 бита (00) - это версия, которая равна 0

В приведенной ниже таблице представлено шестнадцатеричное значение байта типа подтипа FC для нескольких типов кадров. Сравнение данных QoS с нормальным фреймом данных может действительно помочь получить этот патч. Имейте в виду, что у таблицы может быть ошибка или две, так как я просто взбивал ее.

Вы правы, что 1000 - это маяковый кадр, вы просто смотрели на неправильные биты.

У вас есть заголовок radiotap, вы можете получить представление dec такого типа, как это описано в API pcap:

int type = pkt_data[20] >> 2;

Ответ 2

Это обычная ошибка, и она несколько раз укусила меня.

Это зависит от порядка байтов.

Когда у вас есть многобайтовое число для представления, возникает вопрос о том, какой бит вы ставите/отправляете первым?

Естественный (человеческий) порядок байтов состоит в том, чтобы перенести большую часть сначала, затем меньшие части после него, слева направо, также называемые Big Endian. Обратите внимание, что биты в каждом байте никогда не ошибаются с точки зрения программистов.

например. 1234 decimal требует 2 байта, 04D2 hex. Вы пишете/отправляете 04 D2 или D2 04? Первый - Большой-Endian, второй - Маленький-Endian.

Чтобы смутить его больше, задействованные механизмы могут использовать разные байтовые заказы.

В этом случае порядок байтов сети (в байтовом порядке), порядок байтов архитектуры (может быть разным для каждой архитектуры процессора), а данные могут быть в буфере, поэтому он будет меняться в зависимости от того, читаете ли вы буфер сверху вниз или снизу вверх.

Это не помогает объяснению того, какие биты делают то, что может быть "назад", как в вашем исходном сообщении.