Короткий ответ

«Wi‑Fi отваливается» — четыре разных инцидента: нет покрытия (RSSI), грязный канал/ширина, клиент прыгает между точками без нормального roaming (разные SSID, слишком агрессивный access-list), DHCP/VLAN после перехода на другую CAP. Смотрите /interface wifi registration-table (новый стек) или /interface wireless registration-table (старый): reason отключения, сигнал, uptime. Не поднимайте tx-power на максимум первым шагом — усугубите sticky client и воздух.

Если точка не в CAPsMAN — сначала видимость CAP. Если после дисконнекта 169.254 — DHCP.

Симптомы и как отличить

ПаттернСлой
Один клиент, одно местоклиент/драйвер, не радио глобально
Все в 17:00канал, DFS, сосед
При переходе между кабинетамиroaming/coverage hole
Пачка вместе с loop/CPUloop
Только гостевой VLANVLAN/DHCP, не RF

Возможные причины

  1. Перекрытие каналов 2.4 (1/6/11 не соблюдены), ширина 40 МГц на 2.4.
  2. 5 ГГц DFS ушёл в CAC после радара — минуты без эфира.
  3. Слишком высокий min-rate / слишком низкий tx, дыры покрытия.
  4. Две SSID одинаковые с разным ключом или разным VLAN.
  5. Access-list по сигналу отшивает клиента на границе.
  6. DHCP не общий для datapath точек (клиент в другом broadcast).
  7. Питание PoE проседает, точка ребутится (смотрите uptime CAP).
  8. CPU роутера 100% — радио не успевает.

Диагностика

Новый стек:

/interface wifi print
/interface wifi registration-table print
/interface wifi monitor [find] once

Старый:

/interface wireless registration-table print
/interface wireless monitor 0 once

Канал и шум — scan в окно обслуживания, не в час пик без нужды (scan рвёт эфир).

DHCP lease при дисконнекте:

/ip dhcp-server lease print

Uptime точек vs контроллера. Логи wireless/wifi.

Проверьте, не в мосту ли петля: шторм даёт массовые дисконнекты.

Решение

Сценарий A. Покрытие

Карта: замер RSSI клиента на точке в проблемной точке помещения. Цель порядка -65…-70 dBm для данных, не -85. Добавьте CAP, не мощность до потолка. Мощность на 2.4 часто ниже, чем на 5, чтобы клиент не прилипал к 2.4.

Сценарий B. Канал

2.4: 20 МГц, каналы 1/6/11 вручную, не auto в плотной застройке. 5 ГГц: избегайте DFS для офиса, где «минута тишины» неприемлема, либо примите CAC. Не ставьте 80 МГц, если соседи забиты — лучше 40 стабильных.

Сценарий C. Roaming

Одинаковые SSID/PSK/VLAN на всех CAP одного домена. Не смешивайте локальный AP на роутере с другой PSK «почти той же» сетью. FT/802.11r включайте только если стек и клиенты это тянут; кривой 11r даёт обрывы — тестируйте, не включайте «потому что enterprise».

Access-list signal range: слишком жёсткий порог отвалит телефоны в коридоре. Ослабьте или уберите на время теста.

Сценарий D. DHCP после roaming

Все CAP в одном datapath/bridge VLAN с одним DHCP. Local forwarding: VLAN должен доходить до сервера. Manager forwarding: CPU контроллера и нагрузка.

Не factory-reset точки из‑за одного клиента.

Как проверить, что проблема устранена

Прогулка с одним и тем же клиентом по маршруту жалобы: registration не рвётся каждую комнату, lease тот же адрес, ping шлюза 192.168.88.1 без серии timeout. Второй клиент (ноутбук vs телефон). В busy hour канал без постоянных DFS-уходов. Логи без шторма disconnect.

Если не помогло

  • Конкретная модель телефона — драйвер, PMF/WPA3 mismatch. Тест WPA2-PSK AES на время.
  • USB 3 рядом с 2.4 на клиенте.
  • Mesh «усилитель» чужого вендора в той же SSID — уберите.
  • Переполнение клиентов на одном CAP.

Профилактика

  • Планируйте каналы, не auto навсегда.
  • NTP, одинаковые пакеты CAP.
  • Мониторинг числа registration и uptime CAP.
  • Гостевая сеть отдельным VLAN, не отдельным «случайным» DHCP на точке.
  • Журнал канала и ширины (1/6/11 на 2.4, non-DFS на 5) храните вместе с картой CAP, не в памяти «как настроили год назад».

Registration reason, DFS и DHCP после смены CAP

В registration-table смотрите не только RSSI, но и last disconnect reason. lost-connection на границе покрытия — дыра или sticky 2.4. Массовый disconnect в одну секунду на всех CAP — канал/DFS/контроллер/loop, не «один телефон». DFS на 5 ГГц после радара даёт минуты тишины: для офиса, где это неприемлемо, фиксируйте non-DFS каналы.

Прогулка: один клиент, ping 192.168.88.1 каждую секунду. Обрыв без смены lease — радио/roaming. Обрыв со сменой на 169.254 — DHCP/VLAN datapath, идите в сервер DHCP и bridge VLAN. Разные PSK на «одном SSID» в соседнем кабинете дают вечные реконнекты.

Питание: uptime CAP, который сбрасывается пачками, — PoE/кабель, не канал. CPU контроллера при manager forwarding: если NAT и Wi‑Fi на одном слабом CPU, дисконнекты совпадут с часом пик интернета.

Не включайте 802.11r «потому что enterprise» без теста парка клиентов: кривой FT хуже обычного roaming. Access-list по сигналу с порогом -70 отрежет коридор — ослабьте на время замера.

FAQ

Помогает ли скрытый SSID от обрывов?

Нет. Усложняет подключение, не RF.

Band steering обязателен?

Может клеить плохо. Если обрывы начались после steering — выключите для теста.

Почему ночью стабильно, днём нет?

Соседи, плотность клиентов, DFS, CPU. Смотрите время в логах.

Нужен ли отдельный SSID для IoT 2.4?

Часто да: старые платы плохо живут на 5 ГГц и 11r.

tx-power=all rates?

Не крутите, не понимая антенный gain и закон. Сначала канал и плотность точек.

Стоит ли резать TX power на 2.4, если клиенты «липнут» и рвутся в коридоре?

Часто да: слишком громкий 2.4 заставляет телефон игнорировать ближний 5 ГГц, потом связь рвётся на границе. Снижайте 2.4 относительно 5, добавляйте CAP в дыру, не поднимайте 5 до потолка вслепую. Замер RSSI с точки, не «палки» на телефоне. После изменения мощности повторите прогулку с ping 192.168.88.1. Если обрыв совпадает со сменой CAP и 169.254 — это DHCP/VLAN, не эфир: вернитесь к lease и datapath.