Jump to content

Padavan

Global Moderators
  • Content count

    154
  • Joined

  • Last visited

  • Days Won

    6

Padavan last won the day on May 15

Padavan had the most liked content!

Community Reputation

157 Excellent

3 Followers

About Padavan

  • Rank
    Advanced Member

Converted

  • Location
    Keenetic Giga II
  1. Вышеописанные исправления не касаются rt539x, там нет поддержки VHT. Я так понимаю проблема подключения была и на других версиях прошивок?
  2. 1) В 2.4ГГц диапазоне всего 3 неперекрывающихся канала 40 МГц. Нужно жить в деревне или чистом поле, чтобы не иметь наложений. В городе наложения есть всегда. 2) Даже если одна из соседних ТД села на канал, который накрывает часть спектра канала вашей ТД (или целиком перекрывает ваш спектр), это далеко не трагедия, так как помехи от такой ТД сильно зависят от того, передает ли она данные и с какой скоростью. Чем плотнее занят канал передачей данных и чем выше скорость, то тем больше помех от такой ТД. Пассивная ТД лишь рассылает маяки и никакой проблемы для вашей ТД представлять не может. Даже если она за стенкой и ее уровень сигнала выше вашей ТД. 3) Когда к ТД подключено более 1 клиента, она не может и не должна каждые 5-10 минут сканировать эфир. Так как это не останется незамеченным для клиентов, потому что ТД должна пройтись по всем каналам и задержаться на каждом минимум 400мс. Пока ТД на другом канале, клиент не может работать с ТД. В 2.09 прошивке функция авто-выбора канала была значительно доработана, там есть удобный режим Динамически, к тому же всегда проверяется активность клиента и если автосканирование было отложено из-за активности клиентов, будут выполняться попытки снова и снова. При сканировании теперь анализируется не только RSSI на смежных каналах, но и FalseCCA (Busy Time). Также был реализован Partial Scan для AP-Client.
  3. Dorik1972 У вас есть USB модем? В первом сообщении у Dale работает модем.
  4. Dorik1972 Все-же неплохо бы получить кусок лога перед возникновением дедлока, так как "точно такая-же" может быть совсем из другой оперы. В первом случае виден дедлок, предположительно после срабатывания пинг-чекера, во время закрытия PPTP соединения. Однако данных в логе мало, хотелось бы видеть побольше строк до появления дедлока.
  5. Так, уже теплее. Тут просматриваются 2 варианта исхода: - пока не отключится "проблемный" клиент либо: - один из клиентов до этого покинул AP не попрощавшись (не отослав DEAUTH фрейма). В этом случае на AP остается в списке фантомный клиент (ака мертвая душа), до тех пор, пока AP его не отстрелит по неактивности (300 секунд) или по порогу ретрансмитов (в случае если для этого клиента в TX ринг попали пакеты). В этом случае в логе будет характерное сообщение "client xx:xx:xx:xx:xx:xx is age out and disassociated", после чего работа сразу восстановится.
  6. Если более на чем на одном клиенте в этот момент виден одинаковый и значительный провал уровня от AP (на > 20dBm) на длительное время, это больше похоже на аппаратную неисправность. Тем не менее, такое может произойти и от конфликта с определенным клиентом, в этом случае генерация маячков может просто затухнуть на некоторое время.
  7. Dhampir113 Немного проясню ситуацию. Wireless чипы RT3x9x/5x9x давно сняты с производства, компания МТК, поглотившая Ralink не занимается поддержкой Wireless драйверов для RT линеек уже давно. Официальных обновлений драйверов для этих чипов нет и не будет. Нам своими силами приходится заниматься бекпортированием различных фиксов из старших линеек. Как например в 2.10.A.2.0-0 включен патч проверки BSSID при получении DEASSOC фрейма, это исправление вошло ранее во все новые линейки чипов, а недавно нами портировано и в RT539x линейку. Если есть какая-то проблема и она у нас не воспроизводится, исправить ее невозможно, до тех пока мы сами ее не воспроизведем. Поэтому стОит отнестись с пониманием что ситуация ваша не массовая, в большинстве случаев проблем нет и RT5392/3593 работают в 11n. Подобные проблемы воспроизвести крайне сложно, так как нужно воссоздать определенный набор клиентов. Причем и это не гарантия воспроизведения. В сухом остатке - не стоит ждать для старых устройств кардинальных изменений по Wireless. Только исправлений для проблем, которые мы смогли воспроизвести, отладить и найти причину. - Для начала неплохо выяснить, подключение какого клиента ведет к данной проблеме. Т.е. вам нужно разрешить 11n и постепенно подключать клиентов. Скорее всего подключение одного из клиентов будет приводить к таким последствиям.
  8. IgaX В 3.0.5.0 драйвере еще с год назад было динамическое управление TxBurst в зависимости от количества подключенных клиентов (фича MULTI_CLIENT_SUPPORT). После 3 подключенных клиентов TxBurst отключится, если <= 2, то включится. Это все актуально, если tx-burst включен в профиле. Сейчас это в 2.09 работает железобетонно, ранее был небольшой изъян в стоковой логике драйвера, о чем я писал выше. В сухом остатке - если вас не смущает более низкая скорость в Ookla SpeedTest на прием (если провайдер юзает шейпинг), то можно включать tx-burst смело, он него есть всегда профит, ну а при 3 и более клиентах он динамически отключится, чтобы более аккуратно требовать ACK-и от клиентов.
  9. 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ГГц не оказывает заметного влияния.
  10. 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, также разницы не будет.
  11. ALL Для подавляющего большинства пользователей данный параметр трогать не нужно, он приглушает входное усиление на прием (ограничивает максимальный гаин). 0 - не менять, штатное значение. Актуально для G3/U2 (2.4 и 5) и Air/Extra2 (только 5), когда в эфире присутствует сильная специфическая помеха, которая приводит к исчезновению AP в эфире (пропадают маячки). Если у вас с этим нет проблем, данное значение трогать не нужно, оно только ухудшит слышимость от удаленных клиентов.
  12. 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 накопителя.
  13. Код US вещается только в 5ГГц и только для региона RU (выбирается в WebUI). Для обхода проблем в 11ac со многими Apple клиентами. Если выберите регион, например UA, будет вещаться именно UA. Подменивается только код US в маяке, Power Domain от USA при этом не используется.
  14. ED-CCA (Energy Detector) является обязательным во многих странах. Если ED-CCA активен, то AP значительно замедляет передачу порций данных, если в спектре обнаруживается высокий уровень False CCA. Это касательно изменений по Wireless драйверу. Я пересмотрел все изменения, больше никаких изменений по радиотракту не было. ED-CCA всегда был раньше, но включался/выключался на каждом диапазоне по коду региона, заданному в Web. Сейчас также включается/выключается, но по коду региона, прошитому на фабрике. Я соберу тестовый стенд с вашим кейзом и проверю в том числе влияние ED-CCA. Но сегодня уже не успею (до публикации драфта).
  15. ydzhus Начиная с 2.09.A6, NDM включает ED-CCA по коду региона, прошитому на фабрике. А не по коду региона в Web интерфейсе. Иными словами, если у вас прошито RU, то ED-CCA не будет задействована, а если например UA - то будет.
×