OpenWrt: падение скорости Wi‑Fi (TX) — диагностика и решение

Падение скорости Wi‑Fi OpenWrt после перемещения и повторного ассоциирования чаще всего связано не с уровнем сигнала, а с поведением драйвера, агрегацией/блок‑ACK, энергосбережением (WMM/U‑APSD/SMPS) или фоллбэком ширины канала/режима (VHT→HT). Для диагностики Wi‑Fi OpenWrt собирайте iperf3‑замеры в обе стороны, iw dev wlan0 station dump/iw phy/iw survey, а также dmesg и logread; по шагам пробуйте фиксировать канал/htmode, отключать U‑APSD/WMM, тестировать без VHT и собирать логи для баг‑репорта по mt76/mediatek.

Содержание

• Падение скорости Wi‑Fi в OpenWrt — что это и как проявляется
• Репродукция проблемы и обязательные измерения (iperf3, направление трафика)
• Диагностика радиоинтерфейса — какие команды и что смотреть
• Какие параметры включить/отключить: пошаговые эксперименты
• Продвинутые проверки: логи драйвера, монитор‑снимки и баг‑репорт
• Контрольные тесты и чек‑лист для подтверждения исправления
• Источники
• Заключение

Падение скорости Wi‑Fi в OpenWrt — что это и как проявляется

Симптомы вы описали типичные: при первой ассоциации — VHT, 80 MHz, MCS8–9 и сотни Мбит/с; после перемещения и возвращения — RSSI остаётся сильным, но клиент показывает MCS0/20 MHz и скорость ~7 Мбит/с. Что это значит простыми словами? MCS и ширина канала — результат непрерывной адаптации по качеству канала (SNR, PER, retries) и по соглашению между клиентом и AP. RSSI показывает величину, но не полную картину (интерференция, ошибки ACK, проблемы с блок‑ACK/агрегацией или баг драйвера могут сделать RSSI «ложным» индикатором).

Частые причины:

• Ошибка/регресс в драйвере (например, mt76/mediatek) или прошивке — после роуминга часть состояний остаётся некорректной.
• Проблемы с A‑MPDU/AMSDU или block‑ACK — downstream пакеты не подтверждаются, rate control уходит в минимальные скорости.
• WMM / U‑APSD / power save у клиента или некорректная реализация на AP — AP буферизует/не доставляет даунлоад.
• Автопереключение ширины/DFS/регулятор — канал или ширина меняются без явного уведомления.
• Шейпинг/QoS/SQM или offloading в сетевом стеке — иногда влияет на видимую asymmetry, но редко меняет MCS.

Репродукция проблемы и обязательные измерения (iperf3, направление трафика)

Прежде чем менять настройки — повторите воспроизведение и зафиксируйте показатели.

1. Установите/запустите iperf3 на роутере и на клиенте (или используйте мобильное приложение).

• На роутере (сервер):

iperf3 -s

• На клиенте: прямой тест (upload клиента → AP):

iperf3 -c <router_ip> -t 30 -i 5 > /tmp/iperf-up.log

обратный тест (download клиента ← AP):

iperf3 -c <router_ip> -R -t 30 -i 5 > /tmp/iperf-down.log

Подробности по iperf3: https://iperf.fr/iperf-doc.php

2. Снимите до и после состояния радиосвязи:

• до деградации и после:

iw dev wlan0 link
iw dev wlan0 station dump

Сравните поля tx bitrate, rx bitrate, tx retries и tx failed.

3. Во время деградации держите логи:

• Логи ядра и system:

logread -f
dmesg -w

Фиксируйте время события — это поможет сопоставить dmesg с падением скорости.

Диагностика радиоинтерфейса — какие команды и что смотреть

Набор команд, который даёт факты (выполните на роутере):

• Информация об ассоциации:

iw dev wlan0 station dump

что смотреть: signal, tx bitrate, rx bitrate, tx retries, tx failed, connected time.

• Краткие сведения о link:

iw dev wlan0 link

• Аппаратные возможности и текущие режимы:

iw phy0 info
iw list

• Нагрузка на канал / шум:

iw dev wlan0 survey dump

смотрите busy/ noise/ channel usage — высокая загрузка может привести к fallback.

• Регулятор (ограничения мощности/DFS):

iw reg get

• Конфиг радио/SSID:

cat /etc/config/wireless
uci show wireless

• Проверка ошибок драйвера:

dmesg | grep -i mt76
dmesg | grep -i firmware
logread | grep -i hostapd

Что именно искать в выводе:

• Резкий рост tx retries или tx failed → проблемы с доставкой (ACKs).
• Переход VHT80 → 20 MHz или MCS9 → MCS0 → явно видно в station dump.
• Сообщения об ошибках firmware/firmware crash/reset/watchdog → баг драйвера.
• DFS / radar detection в dmesg → автоматический фоллбэк ширины/канала.
• High channel busy → внешняя интерференция.

Подробнее о командах iw и их значениях: https://wireless.wiki.kernel.org/en/users/documentation/iw
Удобный обзор инструментов OpenWrt: https://openwrt.org/docs/guide-user/network/wifi/iwinfo

Какие параметры включить/отключить: пошаговые эксперименты

Делайте изменения по одному пункту и тестируйте iperf3/iw до/после.

1. Фиксация канала и htmode (убираем автоматические переключения)

uci set wireless.radio0.channel='36'
uci set wireless.radio0.htmode='VHT80'
uci set wireless.radio0.txpower='20' # подберите в рамках регдома
uci commit wireless
wifi

Задача: исключить автопереключение/DFS.

2. Отключение VHT (проверка, связана ли проблема с 802.11ac)

uci set wireless.radio0.htmode='HT40' # или 'HT20' для теста
uci commit wireless
wifi

Если проблема исчезает — дело в VHT/driver/агрегации.

3. Отключение WMM / U‑APSD на время теста (временный тест)

• В UCI (если интерфейс поддерживает):

uci set wireless.@wifi-iface[0].wmm='0'
uci commit wireless
wifi

Внимание: отключение WMM может резко уменьшить производительность и повлиять на VoIP; это только для диагностики. Попросите клиента отключить энергосбережение Wi‑Fi (тест).

4. Проверить и включить disassociation по низким ACK (чтобы «сбросить» застрявшие клиенты)

• В hostapd можно включить disassoc_low_ack=1. В OpenWrt это иногда можно задать как опцию wifi-iface; если нет — можно прямо править конфигурацию hostapd (только для тестов). Это заставит AP разрывать «плохие» соединения, после чего клиент заново ассоциируется корректно.

5. Изменить txpower (иногда слишком высокая мощность создаёт самосмешение)

uci set wireless.radio0.txpower='16'
uci commit wireless
wifi

6. Отключение SQM / QoS / offloading

• Отключите SQM и hardware flow offloading (если включены) — это исключит влияние сетевого стека:

/etc/init.d/sqm stop # если установлено
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter # пример, проверьте настройки вашей системы

7. Если есть подозрение на агрегацию — временно понизьте режим (см. пункт 2) или тестируйте с клиентом, у которого можно отключить агрегирование (чаще доступно на Linux-клиенте).

После каждого изменения — обязательный набор:

• iperf3 обе стороны;
• iw dev wlan0 station dump;
• dmesg/logread (срезы времени).

Продвинутые проверки: логи драйвера, монитор‑снимки и баг‑репорт

Если простые меры не помогают — собирайте развёрнутые артефакты для анализа или для открытия issue:

Что собрать:

• uname -a (версия ядра)
• cat /etc/os-release / версия OpenWrt/ImmortalWrt
• lsmod и список загруженных модулей (mt76, mac80211 и т.д.)
• dmesg полный (до/во время/после) — особенно grep по имени драйвера
• logread полный
• iw dev wlan0 station dump (до/во время/после)
• iw phy0 info, iw dev wlan0 survey dump
• конфиг /etc/config/wireless
• iperf3 логи (up и down)
• если возможно — дамп в монитор‑режиме (pcap) с отдельного устройства для анализа retransmits/ack: захват в Wireshark/aircrack‑tools.

Инструменты для захвата/анализа:

• hostapd документация: https://w1.fi/hostapd/
• захват в монитор‑режиме и анализ в Wireshark: https://www.wireshark.org/

Дальше — открывайте issue в репозитории драйвера/прошивки (например, upstream mt76 или OpenWrt пакет), прикрепляйте все логи и ясное описание воспроизведения. Чем конкретнее временные метки и набор команд — тем быстрее разработчик локализует проблему.

Контрольные тесты и чек‑лист для подтверждения исправления

После правки/экспериментов пройдитесь по чек‑листу:

• [ ] iw dev wlan0 station dump показывает требуемый tx bitrate/rx bitrate и MCS не падает при перемещении.
• [ ] tx retries и tx failed остаются низкими в течение длительного теста.
• [ ] iperf3: download и upload соответствуют ожидаемым скоростям для MCS/width.
• [ ] В dmesg нет ошибок firmware/driver/reset в момент деградации.
• [ ] Канал и ширина не фоллбэчат из‑за DFS или автоматических настроек.
• [ ] Если проблема исчезла при отключении VHT/агрегации — документируйте это как подсказку для разработчиков драйвера.

Если после всех тестов проблема остаётся воспроизводимой на нескольких клиентах — это сильный признак багa драйвера/прошивки (mt76/mediatek). Тогда единственный рабочий путь — собрать логи и открыть баг‑репорт.

Источники

• OpenWrt: Wi‑Fi руководства и iwinfo — https://openwrt.org/docs/guide-user/network/wifi/iwinfo
• OpenWrt: общие рекомендации по беспроводной сети — https://openwrt.org/docs/guide-user/network/wifi/README
• iw (Linux wireless toolset) — https://wireless.wiki.kernel.org/en/users/documentation/iw
• iperf3 документация — https://iperf.fr/iperf-doc.php
• hostapd — https://w1.fi/hostapd/
• Wireshark — https://www.wireshark.org/

Заключение

Проблема падения скорости Wi‑Fi OpenWrt при возвращении в прежнее место чаще связана с драйвером/агрегацией, энергосбережением или автоматическими переключениями ширины/режима, а не с уровнем RSSI. Ключ к решению — последовательная диагностика: iperf3 (оба направления), iw dev ... station dump/phy/survey, dmesg/logread; затем поочерёдные тесты — фиксация канала/htmode, отключение WMM/U‑APSD, отключение VHT/агрегации для проверки и сбор полных логов для баг‑репорта. Если после всех экспериментов проблема воспроизводится на нескольких устройствах, соберите набор логов (см. чек‑лист) и откройте issue по драйверу — это наиболее реалистичный путь к стабильному исправлению.