Padavan

Ethernet драйвер потребляет меньше ресурсов CPU на входящем локальном трафике, чем Wireless драйвер. Wireless драйвер занимаеется преобразованием 802.11 заголовков в 802.3, де-аггрегацией MPDU. Локальный трафик также обычно имеет огромные TCP пакеты, которые также склеиваются программно уже в сетевом стеке. На транзитном трафике (Wifi <-> WAN) все будет хорошо (там пакеты обычно не больше MTU), но для локального трафика, Wireless всегда будет проигрывать Ethernet по ресурсам CPU. Обратите внимание на загрузку CPU при копировании на накопитель. Она будет под 100%.

У каждого вендора свой механизм дистрибуции PMK R1, это не оговорено стандартом. Поэтому точки доступа разных вендоров не смогут работать в одном мобильном домене 11r.

Maxwell Max Попробуем воспроизвести. В вашем логе смущает одно - в 18:03:38 клиент прошел AUTH, а в 18:03:43 уже был отстрелен по превышению 1024 ретрансмитов. И чуть ранее - похожая ситуация. Ретрансмиты инкрементируются, когда AP передает пакет, но клиент не присылает ACK, происходит повторная передача пакета и т.д. Когда клиенту отправлено подряд 1024 ретрансмита, считается что он протух, после чего отправляется DEAUTH и клиент удаляется. В логе клиента все верно - deauth после set key done.

Здесь можно наглядно посмотреть различия Over-the-Air/Over-the-DS https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/80211r-ft/b-80211r-dg.html https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/5700/software/release/ios_xe_33/11rkw_DeploymentGuide/b_802point11rkw_deployment_guide_cisco_ios_xe_release33/b_802point11rkw_deployment_guide_cisco_ios_xe_release33_chapter_01.pdf Современные iOS умеют оба метода, старые только Over-the-DS. Каналы могут быть разными. SSID должен быть одинаковым в рамках Mobility Domain. Также IP подсеть в рамках домена должна быть одна. Поддержка RRM/FT пока в процессе, некоторые вещи еще не доделаны.

Serzh333 Проверьте через Wifi Analyzer, что в эфире нет других точек доступа с MAC адресом (либо SSID) как у вашей AP. Если ваша AP такая одна в эфире, понаблюдайте (желательно с двух разных устройств) через Wifi Analyzer за маяками в эфире. Если маяки будут пропадать через минуту после включения, то с большой вероятностью ваше устройство неисправно.

Поддержка WPA2 Enterprise возможна только на уровне точки доступа (AP). Для клиента (AP-Client) поддержки нет от вендора и не планируется. Мы обсудим с руководством поддержку WPA2 Enterprise для точек доступа в 2.13 прошивке, в 2.12 ее точно не будет.

Смена мощности приводит к тому что 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 бинда из-за больших интервалов.