Неправильная маска подсети в DHCP-сообщениях

Неправильная маска подсети в DHCP-сообщениях, UniFi Network

Acarbonara

Guest

10.10.2014 18:30:00

У меня проблемы с DHCP-сообщениями на UniFi AP. Вот моя конфигурация:
1. На каждом AP настроено 3 SSID.
2. Каждый SSID назначен на отдельный VLAN и подсеть (192.168.x.0 /24, где x меняется в зависимости от VLAN).
3. Маска подсети у всех — 255.255.255.0.

ПРОБЛЕМА: Когда DHCP-предложения передаются по радиоинтерфейсу AP, маска подсети оказывается 255.255.255.1. Устройство, подключающееся к WiFi, не может выйти в сеть из-за неправильной маски подсети.

ПРОЧИТАЙТЕ: Я уже больше месяца занимаюсь поиском причины:
1. Сделал захват пакетов на DHCP-сервере во время проблемы. Сервер выдаёт правильную маску подсети — 255.255.255.0.
2. Сделал захват пакетов на всех коммутаторах между сервером DHCP и UniFi AP. DHCP-предложения от сервера с правильной маской — 255.255.255.0.
3. Сделал захват пакетов на порту коммутатора, к которому подключён UniFi AP. DHCP-предложения с правильной маской 255.255.255.0.
4. Сделал захват пакетов на беспроводном интерфейсе UniFi AP с помощью tcpdump. Теперь DHCP-предложения содержат неправильную маску подсети — 255.255.255.1.
5. Удалял и создавал заново DHCP-диапазон на сервере. Проблема осталась.

Проблема возникает часто, но нерегулярно: примерно 20-30 минут работает некорректно, потом на несколько часов исчезает.

В приложении — Wireshark-захват на беспроводном интерфейсе UniFi AP (wl0.1) во время возникновения проблемы. Обратите внимание на предложенную маску подсети (Опция 1) в DHCP Offer-сообщениях.

Acarbonara

Guest

03.11.2014 19:37:00

Привет, Xi, я только что прочитал твой пост. Ты пробовал делать захват беспроводного лога БЕЗ одновременного запуска процесса tcpdump? Да, без запуска tcpdump никаких проблем с подключением или назначением IP-адресов не возникает. Ты также упомянул: «При запущенном tcpdump может происходить неожиданное изменение пакетов». Я не видел такого заявления ни на каких форумах или в разделе FAQ от Ubiquiti. Если есть какое-то официальное сообщение, что процесс tcpdump может вызывать манипуляции с пакетами, прошу прощения, что не прочитал его до создания этого тикета. Не мог бы ты прислать мне ссылку, где есть утверждение, что tcpdump на точке доступа может вызывать изменения пакетов WiFi? Спасибо!

Acarbonara Guest	#3 03.11.2014 18:55:00 Вы посмотрели записи?

UI-Team

Guest

03.11.2014 18:48:00

Acarbonara, спасибо за подтверждение. Ты пробовал снять беспроводной лог БЕЗ одновременного запуска tcpdump? Мы на самом деле не ожидаем проблем в таком случае, судя по тому, что наблюдали у себя локально. Когда tcpdump запущен, вполне возможно появление неожиданных манипуляций с пакетами. Спасибо, -Xi

Acarbonara Guest	#5 03.11.2014 18:40:00 Процесс tcpdump работал только во время сбоя. Но да, все три записи (проводная, беспроводная и tcpdump) велись одновременно.

UI-Team Guest	#6 03.11.2014 18:37:00 Acarbonara, спасибо за предоставленные журналы отладки. Хотим уточнить — процесс tcpdump был запущен во время того, как вы снимали лог беспроводного сниффера? Спасибо. -Xi

Acarbonara

Guest

03.11.2014 17:44:00

Как и просили, прикладываю снимки для успешного и неудачного инцидентов. Объяснение:
1. Все файлы в PASS.zip — WiFi-станция успешно получила IP-адрес, и предложенная маска подсети была правильной (255.255.255.0).
2. Все файлы в FAIL.zip — WiFi-станция не получила IP-адрес, потому что предложенная маска подсети была неверной (255.255.255.1).
3. Wired capture — сделан с порта, подключенного к точке доступа (AP). LAN-коммутатор настроен на зеркалирование всего трафика AP (передача/приём) на порт с ноутбуком, на котором запущен Wireshark.
4. Wireless capture — получен с помощью OmniPeek, который перехватывал WiFi-пакеты по воздуху.

В неудачном инциденте есть дополнительный файл — AP capture. Он сделан на беспроводном интерфейсе wl0.3 точки доступа. Подробнее о том, как был выполнен этот захват, смотрите в посте и приложении выше.

MAC-адрес WiFi-станции: 40:6f:2a:42:3e:6d.

Обратите внимание, что все файлы захвата отфильтрованы так, чтобы содержать только трафик к/от WiFi-станции.

Acarbonara

Guest

29.10.2014 13:15:00

Привет, Дэвид и Си! Я приложил инструкции по тому, как я захватываю трафик с UniFi AP на беспроводном интерфейсе. Когда выполняю эти процедуры, сталкиваюсь с проблемой — в DHCP-трафике назначается неправильная маска подсети.

Постараюсь прислать запрошенные захваты к концу дня завтра или в начале следующей недели. Планирую сделать следующее:
1) захватить проводной трафик, идущий к AP, с помощью проводного сниффера на Wireshark. Захват буду делать на ПК, а не с самого AP;
2) захватить беспроводной трафик с помощью OmniPeek (с последующим преобразованием в формат PCAP);
3) начать захват трафика на AP по прилагаемой инструкции;
4) захватить как случай с ошибкой, так и успешный случай.

Ожидаю, что для успешного случая захват трафика на AP делать не буду.

UBNT-DavidQ

Guest

29.10.2014 01:01:00

Привет, @Acarbonara

Мы видим точно ту же проблему, о которой вы сообщаете: tcpdump показывает 255.255.255.1 и это происходит постоянно, а не случайно или периодически. Однако, когда мы делаем беспроводной сниффинг, в эфир действительно выходит правильный адрес — 255.255.255.0.

Лучший способ помочь нам — это сделать захват и на проводной стороне Ethernet, и на беспроводной, и предоставить нам записи как с ошибкой, так и без неё, если это возможно.

Спасибо,
DavidQ

UI-Team Guest	#10 28.10.2014 21:29:00 Спасибо за информацию. Один вопрос: как вы получили лог с беспроводной сети? С помощью tcpdump или перехватом трафика на открытом VAP?

Читают тему (гостей: 1)