Padavan

Смена мощности приводит к тому что NDM перезапускает Wireless драйвер, при этом заново срабатывает автовыбор канала, соответственно у вас каждый раз может выбираться разный канал. Сама смена мощности не может давать подобного эффекта, так как это лишь ослабление от 0 до -12dB. Смотрите в лог, какой канал у вас выбирается при нормальной скорости, причина с большой вероятностью в этом.

Если порт не может передать пакет в порт линк-партнера, там характерно моргает LED как при коллизии.

У Omni2 не лочатся порты сами собой, если роутер не завис, ищите мертвый порт, который блокирует передачу пакетов.

Обычно это следствие того, что один из портов свитча не может отправить ни одного пакета. Так как всегда есть броадкаст и служебный мультикаст предназначенный для всех портов, то сначала забиваются очередь свитча, затем Frame Engine, затем софтовая очередь eth2 интерфейса. Чтобы понять, какой порт блокируется, начинайте отключать LAN кабели, по одному. Отключаете кабель и ждете секунд 10..15. Если отключите виновника, то доступ по LAN возобновиться сам, а также поднимется WAN. Виновником вполне может быть WAN порт (линк партнер). В общем вы сами увидите, отключение какого порта приведет к оживлению. Перезагрузка не требуется. Виновниками такого поведения часто бывают TV (и другие встройки) с Eth, они могут позволить поднять линк PHY, но не подняв свой MAC, в итоге данный Eth порт создает затор.

Уточните, версия прошивки на которой это воспроизвелось v2.10.C.2.0-4?

Да, спасибо за лог, будем смотреть. Исключение в Wireless драйвере. Похоже на NULL pointer dereference.

Что-то вы тут краски сгущаете. Есть под руками пара арчеров на реалтеках: T4U, выдает ~430Mbps T9UH, выдает ~ 520Mbps Проблема в том, что если ставить драйвер с реалтека, он не переключает мост в USB3 и всегда работает в USB2. Если поставить драйвер от тплинка, то он сразу переключает мост в USB3 и так держит его до снятия питания. Даже если потом поставить драйвер от реалтека, мост остается в USB3, пока не извлечь адаптер из порта. - Мы тестировали порядка 20 разных клиентов, ни с одним не было проблем с Beamforming, тем более что eBF всегда автосогласуется с клиентом. С iBF возможны проблемы, он работает без автосогласования, поэтому по умолчанию вЫключен. Включается отдельно через CLI. Боле того, не было ни единого адаптера, с которым бы 7615 показал скорость ниже 7612, наоборот, всегда выше. с BCM4366 выдает до 640Mbps в 4 метрах прямой видимости.

MT7628 SoC содержит на кристалле Wireless IP модуль MT7603. Этот же модуль идет во внешних PCIe чипах MT7603E и MT7592N.

Как уже сказали, M2U работает автоматически по подписке, более того, работает на уровне Wireless драйвера без копирования skb (используется быстрое клонирование), что положительно сказывается на загрузке CPU. В противном случае вы бы не смогли смотреть IPTV мультикаст с WiFi клиента.

Нужно больше вводных данных. - Версия прошивки NDM - Примерное расстояние от WISP клиента до Root-AP - Примерное расстояние от клиентов до AP Keenetic Я так понимаю что на WISP клиенте у вас WEP шифрование. А вот на AP Keenetic тоже выставлен WEP? Или WPA2-PSK?

Wireless чипы MT7620 и RT5592 (применяемые в данном устройстве) не поддерживают аппаратное шифрование/дешифрование PMF (ни один тип 802.11 пакетов). Поэтому нет и не планируется. Для домашнего применения PMF малоактуален, это прерогатива для хотспотов и интернет кафе.

Giga3 поддерживает в 5ГГц и 11N и 11AC, однако если у вас клиент не поддерживает 11AC, либо 11AC заблокирован в прошивке смартфона, будет подключаться как 11N. 150 - это линк 11N, в 11AC совсем другие цифры (1SS до 433 при 80МГц).

Если у вас клиент 1SS, то в 11N линк 150 на полосе 40МГц - это предел стандарта. Я чуть выше приводил расклад по линкам.

Первый раз слышу подобное. Обе AP абсолютно независимые, настройки также. Переключение 270/300, 135/150, 65/72 - это нормально, когда AP не передает активно трафик, линк переключается на ступень ниже (c GI400 на GI_800). ЗЫ: Роутер передает по проводу > 930Mbps, я не знаю почему вы пытаетесь найти черную кошку в темной комнате, выискивая под лупой отличия от вашего "эталонного" девайса.

Очень странно на все это смотреть. Giga3 с тем же Xiaomi Mi6 на линке 866 в 5ГГц выдает на спидтесте 420..450 Mbps в обе стороны (ISP Ростелеком, GPON), в прямой видимости. Близкие скорости на iPad Air2 и на ноутбуке с Intel AC7265 адаптером. Пытаться выжать на клиенте с 1SS, задушенном до 20МГц в 2.4ГГц в условиях занятого эфира жалкие 10..15Mbps и сравнивать по этому показателю устройства из разных категорий - выглядит как погоня за идеалом. 13 канал не выбирается на автовыборе в 2.4ГГц с давних времен, причина - массовое кол-во клиентов (в основном гаджеты), имеющих лейбл РСТ, но не работающих с 12 и 13 каналом из-за ограничений FCC в прошивке. Это приводит к тому что такие клиенты перестают "видеть" точку доступа, когда она встает на канал выше 11. Если клиентское устройство имеет 11N/AC адаптер с 1SS (читайте 1 антенну), то максимальная скорость линка будет ограничена по стандарту: 65/72 при 20МГц 135/150 при 40МГц 390/433 при 80МГц (11AC) Поэтому нужно понимать, что на линке 65 в плохих условиях, скорости 30..40Mbps являются отличными. На линке 135 можно рассчитывать на скорости в районе 90..100Mbps, но в хороших условиях. Например мой Zenfone2 551 выдавал стабильно 110 Mbps (с GPON провайдером). Если нет прямой видимости, в 5ГГц скорости сильно плавают из-за отражений, 5ГГц также отражается от тела человека.

Вышеописанные исправления не касаются rt539x, там нет поддержки VHT. Я так понимаю проблема подключения была и на других версиях прошивок?

1) В 2.4ГГц диапазоне всего 3 неперекрывающихся канала 40 МГц. Нужно жить в деревне или чистом поле, чтобы не иметь наложений. В городе наложения есть всегда. 2) Даже если одна из соседних ТД села на канал, который накрывает часть спектра канала вашей ТД (или целиком перекрывает ваш спектр), это далеко не трагедия, так как помехи от такой ТД сильно зависят от того, передает ли она данные и с какой скоростью. Чем плотнее занят канал передачей данных и чем выше скорость, то тем больше помех от такой ТД. Пассивная ТД лишь рассылает маяки и никакой проблемы для вашей ТД представлять не может. Даже если она за стенкой и ее уровень сигнала выше вашей ТД. 3) Когда к ТД подключено более 1 клиента, она не может и не должна каждые 5-10 минут сканировать эфир. Так как это не останется незамеченным для клиентов, потому что ТД должна пройтись по всем каналам и задержаться на каждом минимум 400мс. Пока ТД на другом канале, клиент не может работать с ТД. В 2.09 прошивке функция авто-выбора канала была значительно доработана, там есть удобный режим Динамически, к тому же всегда проверяется активность клиента и если автосканирование было отложено из-за активности клиентов, будут выполняться попытки снова и снова. При сканировании теперь анализируется не только RSSI на смежных каналах, но и FalseCCA (Busy Time). Также был реализован Partial Scan для AP-Client.

Код US вещается только в 5ГГц и только для региона RU (выбирается в WebUI). Для обхода проблем в 11ac со многими Apple клиентами. Если выберите регион, например UA, будет вещаться именно UA. Подменивается только код US в маяке, Power Domain от USA при этом не используется.

Отлично, спасибо. Тут похоже дело пахнет быстрым отмиранием 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 оффлоад и покрутить их налету.

Ubeavis MT7621 гарантированно не дропает UDP пакеты без чексумм, это очень легко проверяется. Здесь возможно проблема косвенная и связанная с порядком UDP пакетов. Проходя через десятки маршрутизаторов, UDP последовательность часто нарушается. Блок PPE вряд-ли занимается восстановлением последовательности, он форвардит пакеты как есть, по мере поступления. Можно заморочиться и выяснить, что конкретно приводит к данной проблеме с TeamSpeak и Discord, но здесь явно проблема никак не связана с чексуммами UDP.

Спасибо. Нужно было выяснить что нет регрессии, поскольку тестировать OTT из глобальной сети в других условиях просто нереально, трасса будет совсем иной, как и результаты. Да и у провайдеров приоритеты на разный тип трафика (а также параметры DPI) разные.

Я так понимаю что при возврате на 2.09.A.5.0-2 ситуация не изменилась? Соответственно как таковой регрессии в А.6 нет.

enpa Multicast у нас на стенде прошел проверку целостности пайлоада после передачи с сервера на клиента (если говорить о А.6), поэтому сначала не разглядели что речь идет о OTT источнике (unicast). Все текущие изменения по ядру приняты в ветку stable для 3.2 (маинтайнер Ben Hutchings) и вошли в LongTerm Debian. Это не 100% гарантия, иногда бывают осечки. Чтобы исключить смену условий и окружения, не могли бы вы прошить предыдущую сборку и не меняя настроек, попробовать воспроизвести эту проблему на месте? Спасибо.