← На главную

Победил липкие клиенты на OpenWRT с usteer и 802.11k

26.05.2026 16:41 · hackernews

Несколько месяцев назад автор обновил домашнюю сеть на OpenWRT, развернув четыре «тупых» точки доступа с 2.5GbE-магистралью. Но одна проблема осталась — роуминг. iPhones, iPads и MacBooks отказывались переключаться между AP, хотя 802.11r/k/v были включены и логи показывали auth_alg=ft.

Проблема была в двух вещах: не стояло демона управления (usteer), и список соседей rrm_nr_list был пуст. Клиенты сами решали, когда переключаться, и обычно висели на дальней точке до -90 dBm. Автор установил usteer и его LuCI-оболочку на все AP. Демон заработал, AP начали обмениваться данными о клиентах.

Но 802.11k не работал — hostapd не отдавал neighbour reports. Выяснилось, что не хватает пакета static-neighbor-reports. После установки автор сгенерировал per-band списки соседей. Важный нюанс: отчёты строго разделены по диапазонам. 2.4GHz радио рекламируют только 2.4GHz соседей, 5GHz — только 5GHz. Смешивать нельзя — у сетей разные SSID и настройки безопасности (WPA2 для IoT на 2.4GHz против WPA3/SAE на 5GHz).

После настройки каждый AP получил по три соседа на радио, usteer взял под контроль стеринг, а hostapd начал раздавать 802.11k данные. Результаты по 2.4GHz предсказуемо слабые — диапазон всё так же зашумлён соседскими устройствами. А вот на 5GHz изменения заметные: битрейт между двумя AP сместился логично, клиенты стали подключаться к правильным точкам. Главное — исчезли «липкие» клиенты с сигналом около -90 dBm. Есть один сбой FT: Missing required pairwise in pull response from a peer AP, но он единичный.

Автор доволен. Никакого облачного управления, никаких вендорных протоколов — чистый OpenWRT, collectd/Graphite с метриками и конфиг в локальном Gitea. Когда сеть глючит, всегда можно залезть ssh и понять, что пошло не так.

Читать оригинал →