Padavan
-
Постов
495 -
Зарегистрирован
-
Посещение
-
Победитель дней
27
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Сообщения, опубликованные Padavan
-
-
Проблема общая, как для Mi6, так и для сабжа (оба на Qualcomm 835), особенность клиентского драйвера, клиент подключается всегда как 1T1R к любым AP на базе Ralink/MTK (включая старые устройства). Разбираемся.
-
2
-
-
Вышеописанные исправления не касаются rt539x, там нет поддержки VHT.
Я так понимаю проблема подключения была и на других версиях прошивок?
-
Quote
когда на мой Wi-Fi-канал вылез чей-то маршрутизатор
1) В 2.4ГГц диапазоне всего 3 неперекрывающихся канала 40 МГц. Нужно жить в деревне или чистом поле, чтобы не иметь наложений. В городе наложения есть всегда.
2) Даже если одна из соседних ТД села на канал, который накрывает часть спектра канала вашей ТД (или целиком перекрывает ваш спектр), это далеко не трагедия, так как помехи от такой ТД сильно зависят от того, передает ли она данные и с какой скоростью. Чем плотнее занят канал передачей данных и чем выше скорость, то тем больше помех от такой ТД. Пассивная ТД лишь рассылает маяки и никакой проблемы для вашей ТД представлять не может. Даже если она за стенкой и ее уровень сигнала выше вашей ТД.
3) Когда к ТД подключено более 1 клиента, она не может и не должна каждые 5-10 минут сканировать эфир. Так как это не останется незамеченным для клиентов, потому что ТД должна пройтись по всем каналам и задержаться на каждом минимум 400мс. Пока ТД на другом канале, клиент не может работать с ТД.
В 2.09 прошивке функция авто-выбора канала была значительно доработана, там есть удобный режим Динамически, к тому же всегда проверяется активность клиента и если автосканирование было отложено из-за активности клиентов, будут выполняться попытки снова и снова. При сканировании теперь анализируется не только RSSI на смежных каналах, но и FalseCCA (Busy Time). Также был реализован Partial Scan для AP-Client.-
3
-
-
-
Все-же неплохо бы получить кусок лога перед возникновением дедлока, так как "точно такая-же" может быть совсем из другой оперы.
В первом случае виден дедлок, предположительно после срабатывания пинг-чекера, во время закрытия 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
-
-
Код US вещается только в 5ГГц и только для региона RU (выбирается в WebUI). Для обхода проблем в 11ac со многими Apple клиентами. Если выберите регион, например UA, будет вещаться именно UA.
Подменивается только код US в маяке, Power Domain от USA при этом не используется.
-
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
-
-
Отлично, спасибо. Тут похоже дело пахнет быстрым отмиранием UDP бинда из-за больших интервалов.
-
Anton Bobrik
Т.е. при увеличении Life time of Binded UDP entry c 5 до 15 секунд, клиент и сам переподключился и далее уже не рвалось?
-
Ubeavis
На N56U прошивке покрутить проще, можно попробовать увеличить в PPE таймауты для UDP. Интересны эти значения:
Set HNAT Life time of unbind entry (d=3)(unit:1Sec)
Ex: hw_nat -T [1~255]
Set HNAT Life time of Binded TCP/UDP/FIN entry(d=5, 5, 5)(unit:1Sec)
Ex: hw_nat -U [1~65535][1~65535][1~65535]По умолчанию значения такие:
hw_nat -T 3 hw_nat -U 5 5 5
Можно включить UDP оффлоад и покрутить их налету.-
1
-
-
Ubeavis
MT7621 гарантированно не дропает UDP пакеты без чексумм, это очень легко проверяется. Здесь возможно проблема косвенная и связанная с порядком UDP пакетов. Проходя через десятки маршрутизаторов, UDP последовательность часто нарушается. Блок PPE вряд-ли занимается восстановлением последовательности, он форвардит пакеты как есть, по мере поступления.
Можно заморочиться и выяснить, что конкретно приводит к данной проблеме с TeamSpeak и Discord, но здесь явно проблема никак не связана с чексуммами UDP.
-
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
-
OnePlus 5 + Giga III - скорость подключения Wi-Fi
в 2.10
Опубликовано
Не совсем так. Подключается с обоих сторон как 2SS, только со стороны AP линк постоянно гуляет - rate_ctl его постоянно подкручивает из-за каких-то проблем совместимости, надеюсь с этим со временем разберемся..
144 - это нормально, так как клиент залочен на 20МГц в 2.4. Без текущего workaround-а коннектилось всегда на 72 (1SS) с обоих сторон.