Padavan
-
Posts
458 -
Joined
-
Last visited
-
Days Won
26
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Padavan
-
-
По логу очень похоже на блокирование ответного Eth порта, который смотрит в синий WAN порт.
ЦитатаОбратно аппарат оживает только после перезагрузки.
Если возникнет похожая ситуация, для проверки предположения удалите Eth кабель из синего порта на 5..10 секунд и подключите на место. Если проблема решится именно таким образом (без перезагрузки), значит ответный порт встал на паузу и больше не смог принимать пакеты, что вызвало затор и остановку очередей в роутере. В данной ситуации возможно поможет отключение FlowControl на GigabitEthernet1 интерфейсе.
-
1
-
-
У меня сейчас на руках Mi6 (на старой стоковой прошивке), перепроверил текущую прошивку Giga3, с Mi6 всегда коннектится на 2SS, линк 130..144 в 2.4 (867 на 5). Переподключился несколько раз, в том числе к гостевой. При этом до применения workaround там то же самое было, коннектился в 1SS всегда, на любом бэнде.
Непонятно пока почему OnePlus 5 первый раз коннектится на 2SS, а при последующих подключениях (с ваших слов) со стороны AP опять уходит в 1SS. В ваших настройках никаких проблем не вижу, однако selftest не покажет причину, нужно снимать 802.11 Radiotap заголовки во время подключения (например через Wireshark).
Я думаю вам есть смысл подождать обновление прошивки для OnePlus, так как на Mi6 уже вышла прошивка, которая может работать в 2SS без workaround-а. Тем более что 5ГГц теперь коннектится в 866. Надеюсь это будет быстрее, чем мы найдем OnePlus 5.
-
Цитата
К 2,4 ГГц стало подключаться, к 5 ГГц так и не подключается.
Подтверждаю, только здесь баг в логике NDM, интерфейс rai1 выпал из бриджа br1. Соответственно проблема с любыми клиентами, а не с сабжем.
Спасибо за замечание.
-
1
-
-
Пока не могу подтвердить, за 2 суток тестирования ни разу не было. Да и маловероятно, так как MT7628 и MT7602 очень разные чипы, драйверы к ним сильно различаются. Поэтому враз оба не могли умереть. Workaround никак не влияет на работоспособность самого драйвера, он лишь затрагивает ответ probe response (при подключении) чтобы клиент не отключал 2SS.
-
Я протестировал все чипы, начиная от RT5392, все работают с Q835 в 2SS адекватно, за исключением MT7628, с ним есть какая-то нестыковка, MT7628 в паре с Q835 в 2SS постоянно ретрейнит линк со 144 до 1, и так по кругу. При этом в 1SS все ровно. -
Web отображает текущее состояние из драйвера, проверьте, при передаче данных оно должно крутиться. После коннекта у вас там должно загореться 144, затем возможно начнет меняться, но это уже работа rate_ctl, который в реальном времени подстраивает линк на основании BER/SNR/RSSI.
-
2
-
-
Цитата
С 2.4 ГГц проблема сохранилась
Не совсем так. Подключается с обоих сторон как 2SS, только со стороны AP линк постоянно гуляет - rate_ctl его постоянно подкручивает из-за каких-то проблем совместимости, надеюсь с этим со временем разберемся..
144 - это нормально, так как клиент залочен на 20МГц в 2.4. Без текущего workaround-а коннектилось всегда на 72 (1SS) с обоих сторон.
-
2
-
-
Проблема общая, как для Mi6, так и для сабжа (оба на Qualcomm 835), особенность клиентского драйвера, клиент подключается всегда как 1T1R к любым AP на базе Ralink/MTK (включая старые устройства). Разбираемся.
-
2
-
-
-
Все-же неплохо бы получить кусок лога перед возникновением дедлока, так как "точно такая-же" может быть совсем из другой оперы.
В первом случае виден дедлок, предположительно после срабатывания пинг-чекера, во время закрытия PPTP соединения. Однако данных в логе мало, хотелось бы видеть побольше строк до появления дедлока.
-
Так, уже теплее. Тут просматриваются 2 варианта исхода:
- пока не отключится "проблемный" клиент
либо:
- один из клиентов до этого покинул AP не попрощавшись (не отослав DEAUTH фрейма). В этом случае на AP остается в списке фантомный клиент (ака мертвая душа), до тех пор, пока AP его не отстрелит по неактивности (300 секунд) или по порогу ретрансмитов (в случае если для этого клиента в TX ринг попали пакеты). В этом случае в логе будет характерное сообщение "client xx:xx:xx:xx:xx:xx is age out and disassociated", после чего работа сразу восстановится.-
1
-
-
Quote
в момент первого отвала точку доступа знатно трясло: по inSSiderу, мощность передатчика падала до -90dBm
Если более на чем на одном клиенте в этот момент виден одинаковый и значительный провал уровня от AP (на > 20dBm) на длительное время, это больше похоже на аппаратную неисправность. Тем не менее, такое может произойти и от конфликта с определенным клиентом, в этом случае генерация маячков может просто затухнуть на некоторое время.
-
Dhampir113
Немного проясню ситуацию. Wireless чипы RT3x9x/5x9x давно сняты с производства, компания МТК, поглотившая Ralink не занимается поддержкой Wireless драйверов для RT линеек уже давно. Официальных обновлений драйверов для этих чипов нет и не будет. Нам своими силами приходится заниматься бекпортированием различных фиксов из старших линеек. Как например в 2.10.A.2.0-0 включен патч проверки BSSID при получении DEASSOC фрейма, это исправление вошло ранее во все новые линейки чипов, а недавно нами портировано и в RT539x линейку.
Если есть какая-то проблема и она у нас не воспроизводится, исправить ее невозможно, до тех пока мы сами ее не воспроизведем. Поэтому стОит отнестись с пониманием что ситуация ваша не массовая, в большинстве случаев проблем нет и RT5392/3593 работают в 11n. Подобные проблемы воспроизвести крайне сложно, так как нужно воссоздать определенный набор клиентов. Причем и это не гарантия воспроизведения.
В сухом остатке - не стоит ждать для старых устройств кардинальных изменений по Wireless. Только исправлений для проблем, которые мы смогли воспроизвести, отладить и найти причину.
-
Для начала неплохо выяснить, подключение какого клиента ведет к данной проблеме. Т.е. вам нужно разрешить 11n и постепенно подключать клиентов. Скорее всего подключение одного из клиентов будет приводить к таким последствиям. -
IgaX
В 3.0.5.0 драйвере еще с год назад было динамическое управление TxBurst в зависимости от количества подключенных клиентов (фича MULTI_CLIENT_SUPPORT). После 3 подключенных клиентов TxBurst отключится, если <= 2, то включится. Это все актуально, если tx-burst включен в профиле. Сейчас это в 2.09 работает железобетонно, ранее был небольшой изъян в стоковой логике драйвера, о чем я писал выше.
В сухом остатке - если вас не смущает более низкая скорость в Ookla SpeedTest на прием (если провайдер юзает шейпинг), то можно включать tx-burst смело, он него есть всегда профит, ну а при 3 и более клиентах он динамически отключится, чтобы более аккуратно требовать ACK-и от клиентов.
-
1
-
1
-
-
ydzhus
Для получения максимальной скорости с Wireless в локалке вам необходимо включить tx-burst на 5ГГц интерфейсе. Включается через CLI так
interface WifiMaster1 tx-burst system configuration save
В 2.08 живет стоковый баг в драйвере, который может реально включить TxBurst даже если он отключен в настройках. В 2.09 это поправлено, поэтому если tx-burst не включен в настройках, драйвер его не включит никогда.
При включенном TxBurst я стабильно получаю с Ultra2 2.09.A.8.0-0 ~41МБ/с (с пиками до 42МБ/с) при чтении с NTFS раздела USB3 драйва. Клиент - Intel AC 8260. Это по Win10 метеру в проводнике. В Диспетчер задач на сетевом интерфейсе прием плавает от 340 до 366 Mbps. Есс-но на линейном чтении большого не фрагментированного файла.
Принудительное включение/выключение ED-CCA на 5ГГц не оказывает заметного влияния.
-
1
-
-
ydzhus
WAN включать/отключать нет смысла особого, если никто в этот момент не тянет с инета. Отключать имеет смысл только лишь для получения более чистых результатов, чтобы CPU не был загружен посторонними делами.
SMB fastpath работает в 2.09 автоматически, отключается только если сделан проброс TCP портов 445 или 139 из WAN (вручную или через UPnP). SMB fastpath дает разгрузку CPU с любого интерфейса на локальном SMB трафике (по сути сервинг с USB портов). Его результат всегда положительный, никаких исключений.
Сейчас занимаюсь как раз тестированием USB3 на U2.
IgaX
PPE hardware отключать смысла нет, hw_nat и wireless драйверы собраны без внешнего оффлоада, поэтому результат заранее известен - никакой разницы не будет. PPE software - тот да, но он работает на транзитном трафике WAN <-> LAN и WAN <-> WiFi. На локальном, а также на LAN <-> WiFi, также разницы не будет.
-
ALL
Для подавляющего большинства пользователей данный параметр трогать не нужно, он приглушает входное усиление на прием (ограничивает максимальный гаин). 0 - не менять, штатное значение.
Актуально для G3/U2 (2.4 и 5) и Air/Extra2 (только 5), когда в эфире присутствует сильная специфическая помеха, которая приводит к исчезновению AP в эфире (пропадают маячки). Если у вас с этим нет проблем, данное значение трогать не нужно, оно только ухудшит слышимость от удаленных клиентов.
-
3
-
-
Roman_Petrov
В 2.09.A.8.0-0 возвращен AGC VGA в значение по умолчанию, каким он был с лета 2016. Только теперь есть команда CLI, которой можно его зажать, у кого наблюдается проблема с пропаданием маяков при специфической помехе.
Если у вас фабричный RU, то ED-CCA был выключен. Как ранее, так и сейчас.
Тестировать от провайдера скорости через спидтест - неблагодарное занятие. Сегодня 150, завтра 300. На ростелеке без проблем стреляет до 300, но время от времени результаты сильно разные. Тестировать надо на локальном трафике, с адаптерами 11ac 2T2R в прямой видимости дает без проблем до 55МБ/с, если тянуть с LAN на WiFi. Тут все примерно постоянно, никаких подземных стуков. Иначе черную кошку можно долго искать в темной комнате. Повторюсь, я не вижу никакой регрессии с лета 2016.
Нужно только проверить кейз от ydzhus, где сервинг с локального USB3 накопителя.
-
1
-
-
ED-CCA (Energy Detector) является обязательным во многих странах. Если ED-CCA активен, то AP значительно замедляет передачу порций данных, если в спектре обнаруживается высокий уровень False CCA.
Это касательно изменений по Wireless драйверу. Я пересмотрел все изменения, больше никаких изменений по радиотракту не было.
ED-CCA всегда был раньше, но включался/выключался на каждом диапазоне по коду региона, заданному в Web. Сейчас также включается/выключается, но по коду региона, прошитому на фабрике.
Я соберу тестовый стенд с вашим кейзом и проверю в том числе влияние ED-CCA. Но сегодня уже не успею (до публикации драфта). -
ydzhus
Начиная с 2.09.A6, NDM включает ED-CCA по коду региона, прошитому на фабрике. А не по коду региона в Web интерфейсе. Иными словами, если у вас прошито RU, то ED-CCA не будет задействована, а если например UA - то будет.
-
У вас какой код региона?
Начиная с 2.09.A6, NDM включает ED-CCA по коду региона, прошитому на фабрике. А не по коду региона в Web интерфейсе. Иными словами, если у вас прошито RU, то ED-CCA не будет задействована, а если например UA - то будет.
-
1
-
-
19 minutes ago, iggo said:
Но хочу обратить внимание разработчика на постоянно пляшущую скорость в вэб интерфейсе роутера Giga III на закладке "Клиенты WiFi" и "Список устройств домашней сети". Естественно пляшет в меньшую сторону. В свойствах соединения Windows и в утилите адаптера в это время скорость согласования держится железобетонно в норме - 867 Мбитс.
Пояснение, для понимания механизма работы:
802.11 - двусторонняя связь. Клиент устанавливает линк со своей стороны (и динамически управляет канальной скоростью передачи), AP - со своей стороны. Канальные скорости не могут и не должны быть одинаковые у AP и клиента. Когда AP активно передает данные клиенту, она постоянно подстраивает текущий линк. Если текущего битрейта достаточно, AP может перейти и на более низкий линк, но с лучшей защищенностью от ошибок. Когда AP передает, клиент обычно только отсылает ACK-и линк с его стороны может быть любой, стратегия линка определяется ПЕРЕДАЮЩЕЙ стороной в текущий момент времени.
-
2
-
-
Насколько я понял, вы обнаружили что регрессия началась именно с 2.09.A.6? На предыдущих 2.09 было в норме?
-
1
-
-
ydzhus
Сервинг с хоста роутера - это несколько иное чем маршрутизация и L2 бридж. Описание проблемы нужно было сразу начинать с того, что у вас ухудшилась скорость передачи с USB3 порта роутера на 5G клиента, там причин не относящихся непосредственно к кухне радио - может быть несколько. В итоге вы заочно вынесли вердикт что на 2.09 "глючное радио", я вам в ответ привел пример что это не так.
ЗЫ.
Попробуем охватить тестами данный кейз, чтобы понять, есть ли регрессия и локализовать, если проблема обнаружится.-
1
-
-
Специально сейчас замерил на U2, клиент в 4 метрах, пилы нет, скорость > 400 Mbps.
Никакого криминала не вижу. Единственное что могло хоть как-то повлиять - это небольшое занижение гаина, о котором писал выше, но эту разницу можно увидеть только в плохих условиях.
Какое расстояние у вас до клиента, есть ли препятствия?
ЗЫ. На графике WAN -> WiFi 5, т.е. плюс операция NAT. LAN -> WiFi легче для роутера.
-
1
-
GigabitEthernet1: can not send DISCOVER (no buffer space available) на Keenetic Ultra II
in 2.10
Posted
У чипа два интерфейса (LAN и WAN), но общая DMA очередь на оба. Если любой из интерфейсов заблокируется, то очередь вскоре заполнится и возникнет общий затор. Это не позволит отправлять пакеты в оба интерфейса, так как не будет места в очереди, чтобы положить новый пакет.
Причиной блокировки может быть как WAN порт, так и один из LAN. Сброс линка "продует" очередь, так как MAC выбрасывает все пакеты, если у PHY нет линка.
Заблокированный порт обычно характерно моргает LED-ом во время коллизии (пытается отправить пакет снова и снова).