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

19

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

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

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

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

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

Разница во времени между этими двумя кадрами составляет 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

Скриншот: Скриншот

olamotte
источник
Хороший вопрос ... К вашему сведению, в США 802.11b / g каналы 1, 6 и 11 являются единственными неперекрывающимися каналами
Майк Пеннингтон,
@MikePennington спасибо за подтверждение.
olamotte
2
Вы специально заставляете устройство отправлять только зонды на 5 канале? В противном случае устройство будет проверять все каналы и прослушивать ответы по этим каналам (менее 100 мс). Я могу только думать, что это будет причиной, по которой вы получаете ответы на 6 канале. (Это произойдет, даже если ваша карта настроена на использование определенного канала, просто как работает зондирование)
Artanix
@Artanix Я понимаю, что карта отправляет тестовые запросы на каждый канал, но делает это по очереди, и я вижу их: мне интересно, не пропустил ли я какие-то пакеты во время захвата. Я буду загружать скриншот экрана Wireshark.
olamotte
Довольно интересно. Задержка между каналами не так велика, но если она определенно происходит так, как вы предлагаете. Тогда я бы сказал, что вы ответили на свой вопрос как «да»;) У меня пока нет беспроводной карты, которая работает с wireshark, поэтому я не могу проверить себя.
Artanix

Ответы:

6

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

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

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

BatchyX
источник
Так что это проблема избирательности: спасибо, что поделились своим опытом с этим явлением.
olamotte
Наконец, я нашел объяснение в белой книге 2004 года Девина Акина под названием «Защита от пульсаций в ERP 802.11 WLAN». Продемонстрирована способность точки доступа на канале 1 прослушивать маяки от точки доступа на канале 11. См. На стр. 5; cwnp.com/cmsAdmin/uploads/… Я до сих пор не понимаю, почему точка доступа может принимать сигнал так далеко в полосе частот ...
olamotte
@olamotte: Это просто сдвиг частоты 50/2412 = 2% ...
BatchyX
@BachyX И я согласен с вами, эти 50 МГц терпимы. Мой вопрос касается решения о прослушивании (интерпретировать / обрабатывать) сигналов, которые не транслируются на канале, на котором настроено устройство. Автоматический выбор канала для точки доступа для работы не нуждается в этом IMO.
olamotte
6

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

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

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

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

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

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

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

YLearn
источник
Я собираюсь попытаться воспроизвести настройки и посмотреть, что произойдет. Я использовал airodump-ng с опцией канала, может ли быть молчаливая ошибка, которая не говорит мне об этом. Я согласен, я не должен видеть запросы зондирования на других каналах, но, поскольку устройства очень близко друг к другу (несколько дюймов) в моем офисе, я нахожу это странным. Я проверю еще раз. Пока из вашего ответа я понимаю, что APS отвечают только по назначенному каналу и не рекламируют себя на соседних каналах. Благодарю.
olamotte
Может быть возможным иметь сценарий, который вы предоставляете (каналы перекрываются, и некоторый трафик будет понятен там, где перекрываются поднесущие), однако ваш захват (если он находится на одном канале) не должен указывать на захват на двух каналах.
YLearn
Я предоставил параметры airmon-ng, которые я ввожу ... Обвинение в программном обеспечении кажется немного легким, и я переформулировал свой первоначальный вопрос: повторяется ли это поведение 1), может ли кто-то с работающим устройством попытаться наблюдать это 2), указанное где-то в ссылки 802.11? Не смог найти это сам.
olamotte