Проблема с сетью 2.4G - Форум UBIQUITI.RU

Проблема с сетью 2.4G, UniFi Network

AndrewG4425

Guest

07.01.2026 00:32:00

У меня UDM Pro Max и две точки доступа E7. Использую функцию IOT-сети для совместимости с 2.4 ГГц. Большинство моих 2.4-гигагерцевых устройств постоянно испытывают проблемы с подключением или переподключением. Сеть 5 ГГц работает без проблем. Раньше у меня был просто роутер ASUS с таким же количеством устройств — и никаких проблем. Всё прошивки обновлены. Использую Channel AI для управления каналами, плотность точек доступа показывает «хорошо». Тестировал на разных IoT-устройствах: выключателях, розетках и т.д. — они либо вообще не подключаются, либо подключаются, потом отваливаются и больше не переподключаются. Сигнал везде хороший. Когда подключаюсь с айфона, он тоже еле цепляется к 2.4 ГГц, а когда цепляется — интернет не работает. Я читал, что у Unifi давно известные проблемы с 2.4 ГГц, и ни разу не видел решения. Скажите, что решение есть, и я не потратил тысячи баксов на целую Ubiquiti «домашнюю лабораторию», когда обычный потребительский роутер подошёл бы мне больше.

pgrey Guest	#2 10.04.2026 20:23:00 Моя ставка на свитч не от Unifi. Попробуй временно завести проблемную точку доступа в меш или прокинуть длинный кабель в обход (управляемого?) свитча — держу пари, это решит проблему (со стороны Unifi).

AndrewG4425

Guest

09.04.2026 19:22:00

Я удалил старый VLAN и создал новый, как было предложено, на 192.168.99.0/24 — оказалось, проблема конкретно связана с двумя моими AP, а на другой её нет. Между рабочей и той, к которой устройства не могут подключиться, есть только два отличия: 1) у рабочей AP меньше загруженность на 2.4 ГГц; 2) она напрямую подключена к моему коммутатору — проблемные AP имеют между собой не-UniFi L3-коммутатор. Так что дело должно быть в одном из этих двух факторов, а не в каких-то настройках VLAN.

pgrey

Guest

09.04.2026 17:50:00

Я бы также предложил начать с новой IoT VLAN (хотя бы для начала/теста) и одного клиента. Если всё сработает как надо, переноси устройства ПО ОДНОМУ (правила, ограничения и т.д.) и наблюдай за этим клиентом. После того как заработает, добавьте ещё одно устройство, и если всё в порядке, переноси все остальные. Кажется, что это много работы, но на деле времени уйдёт, по моему опыту, ГОРАЗДО меньше, чем если ты будешь рыскать по старой конфигурации и в итоге выяснишь, что там засела какая-то странная UI-шная фича, которую чертовски сложно найти и удалить.

AndrewG4425

Guest

09.04.2026 08:02:00

Мой UDM Pro — DHCP-сервер для всех VLAN. Но тут я подумал: мой нижний AP подключён напрямую к UDM Pro, и устройства работают безотказно. А верхний AP подключён через ещё один управляемый коммутатор, и именно он постоянно глючит. Подозреваю, что дело в том, что он мешает тегированию VLAN — сначала это не пришло в голову, потому что 18 из 20 устройств на верхнем AP работают, и только у нескольких случаются таймауты DHCP. Если бы была проблема с тегированием VLAN, ни одно бы не работало. Когда я привязываю эти устройства к нижнему AP, проблема исчезает. Убираю привязку — они переключаются на верхний, и проблема возвращается.

AndrewG4425

Guest

09.04.2026 06:39:00

Объяснение от Claude: Не знаю, правда ли это, но на сегодня я сдаюсь. Пойду спать и буду размышлять, стоила ли эта домашняя лаборатория Unifi потраченных $2k+ и часов времени, которых у меня нет, когда мой роутер Asus справлялся со всеми этими устройствами и никогда не создавал проблем.

AndrewG4425

Guest

09.04.2026 06:10:00

Устройства с таймаутами DHCP не отображаются в pcap, в pcap вообще не было никаких DHCP-данных. К тому же, мой iPhone подключается. Некоторые умные выключатели подключаются, некоторые — нет с этой проблемой, они одной модели в одной сети, у одних есть эти проблемы, у других — нет. Я заметил, что это обычно всегда происходит от моей верхней точки доступа E7, а от нижней точки доступа E7 такого не бывает.

skitahoe Guest	#8 09.04.2026 04:57:00 Есть ли включенный DHCP-сервер в этой отдельной VLAN? (Я всё это время предполагал, что он есть.)

AndrewG4425

Guest

09.04.2026 04:47:00

Странно, но проблема с таймаутом DHCP происходит только на сети 2.4G IOT WiFi, на основной сети такого нет. Но я пытаюсь сделать отдельный изолированный VLAN для IOT. Однако даже после отключения изоляции (что убрало правила файрвола) и отключения оптимизации для IOT проблема осталась. Единственное отличие сети IOT WiFi от основной — она просто находится в другом VLAN.

skitahoe

Guest

#10

09.04.2026 04:38:00

Что показывает трассировка пакетов MAC-адреса этого хоста? Она должна показывать DHCP-запросы от хоста на широковещательный адрес; было бы полезно посмотреть, что происходит с этого шага и далее.На новой сети IOT такая же проблема (тайм-аут DHCP) возникает и с iPhone, и с ноутбуком?

AndrewG4425 Guest	#11 09.04.2026 04:20:00 Сделал это, устройства переподключились к новой IoT-сети, тайм-ауты DHCP всё ещё происходят.

skitahoe

Guest

#12

24.02.2026 19:57:00

Да. Отсутствие трафика с его MAC-адреса указывает на то, что он не подключился к сети. ARP-запросы намекают мне, что где-то неверная маска подсети. В исходном посте написано: То есть iPhone не может выйти в интернет, когда он подключён к той же проблемной IoT-сети? Моё предложение — начать с нуля. Снесите всю текущую конфигурацию IoT: VLAN, имена сетей и всё остальное. Перезагрузите UDM. Создайте новую IoT-сеть и смело используйте старый WiFi SSID и пароль (чтобы не переподключать устройства). Внутри назовите VLAN «IOT2» и назначьте ему VLAN #99. Выдайте подсеть 192.168.99.0/24 (да, с «/24»), а UDM получит 192.168.99.1. Настройте пул DHCP для IOT2 с 192.168.99.10 по .254. Добейтесь, чтобы iPhone работал в этой сети. Затем перезагрузите одно IoT-устройство и запустите трассировку, чтобы увидеть, как оно подключается к новой сети IOT2.

AndrewG4425

Guest

#13

24.02.2026 19:26:00

Я запустил захват пакетов на своей IoT VLAN через GUI и с помощью AI выцепил нужные строки. Устройство с проблемой — HS220 (192.168.2.219 / 98:da:c4:04:63:90). Так есть идеи, почему у меня постоянные таймауты DHCP, или решение?
--- ARP-ЗАПРОСЫ для 192.168.2.219 (0 ответов получено) ---
2026-02-23 19:21:17.937 ARP, Запрос кто-имеет 192.168.2.219 сообщи 192.168.2.1
2026-02-23 19:21:19.015 ARP, Запрос кто-имеет 192.168.2.219 сообщи 192.168.2.1
2026-02-23 19:21:20.053 ARP, Запрос кто-имеет 192.168.2.219 сообщи 192.168.2.1
... [повторяется каждые ~8 секунд в течение всего 5-минутного захвата — всего 24, 0 ответов]
--- РАБОЧИЙ HS220 ДЛЯ СРАВНЕНИЯ (192.168.2.254 / 3c:84:6a:e6:ec:5b) ---
2026-02-23 19:22:07.093 ARP, Запрос кто-имеет 192.168.2.254 сообщи 192.168.2.1
2026-02-23 19:22:07.101 ARP, Ответ 192.168.2.254 находится по адресу 3c:84:6a:e6:ec:5b ✅
--- ДЕЯТЕЛЬНОСТЬ DHCP (весь захват) ---
[Нет DHCP от 98:da:c4:04:63:90 — только не связанное устройство 192.168.3.145]
--- ИТОГ ---
ARP-запросы к 192.168.2.219: 24
ARP-ответы от 192.168.2.219: 0
DHCP DISCOVER от 98:da:c4:04:63:90: 0
Любой трафик от 98:da:c4:04:63:90: 0
Вывод: Устройство вообще не присутствует в IoT VLAN (br2).

skitahoe Guest	#14 23.02.2026 21:56:00 Захвати пакеты, чтобы понять, что происходит с DHCP: sudo tcpdump -D, чтобы определить номер интерфейса, затем: sudo tcpdump -i INTERFACENUMBER -n -s 1500 -vv port bootpc or port bootps (DHCP использует те же два порта, что и BOOTP).

pgrey Guest	#15 23.02.2026 19:16:00 Попробуй внутренний DHCP-сервер UDM, чтобы посмотреть, что произойдёт в этом сценарии?

AndrewG4425 Guest	#16 22.02.2026 03:25:00 Моя проблема явно связана с DHCP, но, похоже, дело не в пуле адресов. На этом скриншоте видно, что ошибки подключения всегда связаны с DHCP А на этом — что в пуле ещё полно места Есть ещё идеи? Может, скинуть какие-то настройки, которые помогут разобраться?

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