Можно ли ответить на пробный запрос на другом канале?

Я наблюдаю за трафиком 802.11 в моей сети, и особенно за активным зондированием со своего смартфона. Я отправляю запросы зондов для определенных скрытых идентификаторов SSID, но также и для запроса неконтролируемых зондов, который должен раскрыть сети, соответствующие возможностям, заявленным моим устройством.

Я нахожусь в Европе, поэтому мы используем больше каналов, чем в США, я думаю (верно?), И поэтому они перекрываются.

Как и ожидалось, сканирование происходит по разным каналам по очереди, но меня удивляет следующее поведение:

На ненаправленный пробный запрос, отправленный на канале 5, отвечает точка доступа на канале 6. Является ли это совершенно нормальным поведением, то есть определено ли оно где-нибудь в официальных спецификациях?

РЕДАКТИРОВАТЬ: Здесь содержится содержание запроса и ответа зонда, я основываю свое предположение на наборе параметров DS: текущий канал.

Разница во времени между этими двумя кадрами составляет 4 мс, и я не наблюдал никакой другой активности на волнах в течение этого периода времени.

РЕДАКТИРОВАТЬ: Вот команда, которую я запускаю с airodump-ng 1.0 airodump-ng -c 6 mon0

и инструмент захвата показывает маяки, идущие от точек доступа на канале 2–9. Для меня это означает, что airodump принимает все пакеты, видимые в диапазоне частот, без отклонения их в соответствии с текущим параметром канала, имеет смысл по соображениям производительности.

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

РЕДАКТИРОВАТЬ 1:

Является ли это поведение 1) повторяющимся, может кто-нибудь с работающим устройством попытаться это наблюдать? 2) указано где-то в ссылках 802.11? Не смог найти это сам.

РЕДАКТИРОВАТЬ 2:

Спасибо всем, кто пытался повторить эту настройку. Вот моя последняя попытка получить объяснение этому. Мне нужно двигаться дальше: P Вот точный порядок, в котором я делал вещи.

root@mymachine:~# iwconfig :: no mon interface, wlan0 is managed, not associated, and on channel 6: 2.437GHz
root@mymachine:~# airmon-ng start wlan0 6 :: mon0 created, set on channel 6: 2.437GHz

Это подтверждается позже другим iwconfig. (на sidenote, я могу изменить канал wlan0, и mon0 остается независимым.)

root@mymachine:~# airodump-ng mon0 --channel 6 -w out --output-format pcap :: start a capture on channel 6, write to a file. 

Наблюдение: airodump-ng не отображает никаких изменений в канале, верхний левый угол зафиксирован на числе 6. Однако маяки наблюдаются на каналах со 2 по 11 ... -> Очевидно, нет избирательности и передача аргументов обоим airmon-ng и airodump-ng кажутся бессмысленными.

Соблюдается:
ЧИПСЕТ Intel 4965 драйвер iwlwifi ЧИПСЕТ
Atheros AR 9271 драйвер ath9k

Скриншот:

Что происходит, так это то, что ваше беспроводное устройство, даже если оно настроено на канал 6 (2437), также имеет небольшую вероятность получения кадров из соседних каналов, таких как каналы 5 и 7. и даже дальше (с меньшей вероятностью).

Это сильно зависит от используемого беспроводного интерфейса. Худшее радио, которое я обнаружил, было USB-адаптером на основе AR9170, который мог выбирать трафик на канале 1 при переключении на канал 6. Некоторые другие интерфейсы (например, AR9280) не имеют этой проблемы, или она значительно снижена.

PS: AR9271 поддерживается не драйвером ath9k, а драйвером ath9k_htc. Поскольку эта карта является естественным преемником AR9170, я не удивлен, что у вас возникла та же проблема.

Беспроводные захваты не совпадают с проводными захватами. В проводном захвате вы просто выбираете свой интерфейс и начинаете захват кадров.

При беспроводном захвате вы выбираете свой адаптер, но затем вам также нужно выбрать, будете ли вы контролировать один канал или сканировать несколько (или все) каналов. У обоих есть свои преимущества, и нужно понимать, когда их использовать.

В вашем примере, поскольку вы осуществляете захват на двух разных каналах, либо вы используете два разных устройства захвата, либо вы снимаете во время сканирования каналов, но я предполагаю, что вы сканируете. Это означает, что он останавливается на одном канале в течение некоторого периода времени, захватывает трафик и затем переходит на следующий.

Итак, вот как я вижу это, скорее всего, разыгрывается:

1. Устройство захвата начинает мониторинг на 5 канале.
2. Клиентское устройство отправляет запрос зондирования по каналу 5.
3. Клиентское устройство переходит на канал 6 и отправляет пробный запрос.
4. Устройство захвата перемещается на канал 6 и начинает мониторинг.
5. AP отправляет тестовый ответ по каналу 6.

В конце концов, ваш захват получает тестовый запрос на канале 5, а затем тестовый ответ на канале 6.

Каждый инструмент беспроводного захвата, который я использовал, позволит вам выбрать один канал для мониторинга. Я подозреваю, что если вы установите для этого канала 5, вы получите тестовые запросы без ответов. Если вы установите этот канал на канал 6, вы увидите как тестовые запросы, так и ответы.