tcpdump не отображает RSSI

Question

Я отслеживаю тестовые запросы Wi-Fi через tcpdump в Debian и пытаюсь перехватить RSSI (уровень сигнала) каждого элемента тестового запроса. В настоящее время выходные данные из tcpdump для каждого тестового запроса выглядят так:

09:13:17.663057 BSSID:Broadcast DA:Broadcast SA:04:fe:31:67:32:a0 (oui Unknown) Probe Request () [1.0 2.0 5.5 11.0 Mbit]

Отсутствует сила сигнала и некоторые другие элементы.

Используя другую машину с той же версией tcpdump/libpcap и теми же аргументами tcpdump, выходные данные включают мощность сигнала (показано ниже)

09:14:51.673753 6.0 Mb/s 2412 MHz 11g -71dB signal antenna 1 BSSID:Broadcast DA:Broadcast SA:b2:b2:b2:b2:b2:b2 (oui Unknown) Probe Request (11n-AP) [1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 Mbit]

Может кто-нибудь объяснить, почему RSSI отсутствует в полезной нагрузке данных на первом устройстве и есть ли способ перехватить его?

В ответ на запрос @Spiff приведен шестнадцатеричный дамп одного из захватов пакетов.

12:44:40.226564 BSSID:Broadcast DA:Broadcast SA:00:1e:8f:93:3f:60 (oui Unknown) Probe Request (pagefarm) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
        0x0000:  4400 0000 9000 0000 7261 3000 0000 0000  D.......ra0.....
        0x0010:  0000 0000 0000 0000 4400 0100 0000 0400  ........D.......
        0x0020:  c79d 0300 4400 0200 0000 0000 0000 0000  ....D...........
        0x0030:  4400 0300 0000 0400 0300 0000 4400 0400  D...........D...
        0x0040:  0000 0400 b1ff ffff 0000 0000 0000 0000  ................
        0x0050:  0000 0000 4400 0600 0000 0400 0000 0000  ....D...........
        0x0060:  4400 0700 0000 0400 0000 0000 4400 0800  D...........D...
        0x0070:  0000 0400 0200 0000 4400 0900 0000 0000  ........D.......
        0x0080:  0000 0000 4400 0a00 0000 0400 3500 0000  ....D.......5...
        0x0090:  4000 0000 ffff ffff ffff 001e 8f93 3f60  @.............?`
        0x00a0:  ffff ffff ffff 4022 0008 7061 6765 6661  ......@"..pagefa
        0x00b0:  726d 0108 0204 0b16 0c12 1824 0301 0332  rm.........$...2
        0x00c0:  0430 4860 6c                             .0H`l

Answer 1

[Обновлено со всеми выводами из нашего поиска неисправностей.
Спасибо tcpdump/libpcap/Wireshark, сопровождающему экстраординарного Гая Харриса.]

tcpdump распознает только тип канала передачи данных заголовка радио-метки "Radiotap" (он же LINKTYPE_IEEE802_11_RADIOTAP , он же DLT_IEEE802_11_RADIO) для режима мониторинга 802.11.

IEEE802_11_RADIO DLT указывает плате / драйверу добавлять в каждый полученный кадр дополнительный "поддельный" заголовок, полный метаданных радиосвязи. Это то, что не передавалось в битах в эфире, а вместо этого считывалось из состояния радио во время получения этого кадра. Эта информация включает в себя RSSI, канал, на который настроено радио, скорость передачи данных / MCS пакета и, возможно, многое другое.

Если ваша карта и драйвер поддерживают Radiotap, вы можете указать, что вы хотите захватить в этом режиме, добавив -y IEEE802_11_RADIO к аргументам tcpdump . Вы можете получить список поддерживаемых типов каналов передачи данных для вашего интерфейса ra0 с помощью tcpdump -i ra0 -IL или, возможно, с помощью tcpdump -i ra0 -D . Обратите внимание, что DLT режима монитора могут не отображаться, если вы не включите -I для указания режима монитора. Также обратите внимание, что добавление -I для перевода интерфейса в режим монитора может работать не на всех системах, поэтому вам может потребоваться использовать airmon-ng в программном пакете с открытым исходным кодом aircrack-ng чтобы включить режим мониторинга.

Похоже, что драйвер / чипсет Ralink на нерабочем компьютере не поддерживает заголовки Radiotap. По-видимому, он поддерживает только устаревший формат заголовка Prism и менее известный вариант заголовков Prism.

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

Если подтверждено, это означает, что ваши варианты сводятся к таким вещам, как:

• Обновите драйвер на нерабочем компьютере, чтобы он совпадал с драйвером на рабочем компьютере. Судя по всему, драйвер на рабочей машине поддерживает заголовки Radiotap. Поскольку вы говорите, что обе машины имеют одинаковую модель USB-адаптер Wi-Fi, мы надеемся, что оба адаптера действительно имеют одинаковый набор микросхем Wi-Fi внутри, так что лучший драйвер будет работать.
• Используйте Wireshark (или включенный инструмент командной строки tshark), чтобы выполнить захват пакетов в режиме мониторинга на машине с проблемой. Wireshark и tshark должны знать, как анализировать различные заголовки Prism, которые поддерживает "плохой" драйвер.
• Захватите заголовки канального уровня с помощью tcpdump и самостоятельно проанализируйте RSSI варианта заголовка Prism. Скорее всего, это будет SInt32 с прямым порядком байтов по смещению 0x44 (десятичное значение 68). Было бы более надежно найти последовательность 4400 0400 0000 0400 а затем взять следующие 4 байта и считать их SInt32. В вашем примере захваченного заголовка значение RSSI выглядит следующим образом: b1ff ffff . Это было бы 0xffffffb1 , которое представляет собой представление целого числа со знаком 32-разрядного двоичного числа со знаком -79, которое является допустимым RSSI для слабого, но все еще работоспособного уровня сигнала.
• Используйте tcpdump для записи в файл на проблемном компьютере, но затем проанализируйте их, используя Wireshark или tshark на другом компьютере.
• и т.п.