Padavan

snark Попробуйте включить Green Ethernet на WAN порту, это иногда помогает на коротких кабелях c RTL чипами. interface GigabitEthernet1/0 green-ethernet system configuration save

Это не совсем так. Гигабитные устройства, где синий порт исполнен на базе интегрированного свитча (например KN-1910, KN-2310, KN-3010), синий порт абсолютно идентичен остальным портам, отличается лишь трансформатор, обычно на WAN порт ставится отдельный трансформатор. На KN-1010/1011/1810 - да, синий порт исполнен физически на отдельном EPHY чипе, поэтому у него своя жизнь. Тем не менее, мы проверяли бухту 120 метров, в штатных условиях порты держат линк примерно одинаково.

Уже ответил ранее - когда клиент не понимает что-то в RSN IE, он переключается на Enterprise режим, в котором вместо PSK ключа необходимо вводить Login + Pass, который назначается на RADIUS сервере и выдается пользователю. Есс-но это работать не будет в Personal режиме, просто такой fallback на многих старых клиентах.

Более того, скажу что на текущий момент у нас в 3.07 уже есть поддержка SAE H2E на всех устройствах.

Чудес не бывает, скорее всего "другой" добавлял Group Cipher TKIP в RSN IE. Чего не должно быть в современном мире.

Подключился как WPA1 или как WPA2? Клиент выходит настолько тупой, что не воспринимает стандартный AKM. Либо не понимает Group Cipher AES. В смешанном режиме Group Cipher всегда TKIP. В чистом WPA2 он запрещен и очень давно. В смешанном WPA-PSK + WPA2-PSK режиме, RSN IE содержит две AKM Suite, два Ucast Cipher и один Group Cipher TKIP. В чистом WPA2-PSK только одна AKM Suite, Ucast Cipher=AES, Group Cipher=AES.

Когда клиент выводит диалог ввода логина + пароля (вместо PSK ключа), то он считает что данная AP находится в Enterprise режиме (802.1X). Также, как было отмечено выше, многие старые клиенты реагируют на незнакомый OUI в RSN IE, например при включенном WPA3-PSK. Проверьте, что у вас в startup-config не осталась настройка от Enterprise режима.

в 3.05 и выше, интервал обновления GTK (ключ для шифрования мультикаста и броадкаста) по умолчанию 1 сутки (если сбросить настройки). Если у вас перешли старые настройки с прошлых версий, то там действительно 3600 секунд. Можете увеличить руками: interface WifiMaster0 rekey-interval 86400 interface WifiMaster1 rekey-interval 86400 system configuration save Сутки - рекомендуемый интервал обновления группового ключа для AES шифрования.

Динамический выбор канала на каждом бэнде срабатывает в случае: когда нет подключенных клиентов когда есть подключенные клиенты, но при этом сумммарный битрейт по всему бэнду не превышает минимального порога в 30KB/s за последние 15 секунд В случае MWS, если к backhaul BSS подключен(ы) backhaul STA, динамический выбор каналов на данном бэнде отменяется. Динамический выбор канала всегда можно включить в однократном режиме или выключить. В 5ГГц, держать его в периодике не имеет особого смысла, так как полосы по 80МГц.

В офисе нашли метаноевский VDSL2 модем, проверим его в ближайшее время. На старте запуска KN-1010 в серию, я помню запрос с фабрики, они на стресс-тестах выявили проблему с Metanoia VDSL2 модулями, тогда мы убрали в буте софтверный сброс и фабрика отрапортовала, что проблема ушла. Скорее всего у вас модель модема немного отличается. Либо прошивка модема.

Повторю свой ответ из поддержки: Теперь все встало на свои места. Данный VDSL2 модуль подвисает при сбросе чипа RTL8211FS (как программном так и аппаратном). В оригинальном загрузчике, аппаратный сброс чипа RTL8211FS не выполняется и он срабатывает только 1 раз при подаче питания (power-on-reset). При софтверных перезагрузках его не было. В последней сборке я добавил в загрузчик принудительный импульс сброса чипа RTL8211FS, который выполняется как при холодном старте, так и перезагрузках. Поэтому при холодном старте LED стал вспыхивать 2 раза. При этом появилась регрессия, модуль стал ронять линк после сброса и на теплых перезагрузках роутера. Чтобы решить проблему холодного старта с данным модулем, нужно подкидывать питание на SFP модуль с небольшой задержкой, после того как RTL8211FS сбросится при power-on-reset. Программного решения нет для KN-1010.

Нет, я же говорил выше, что питание SFP порта не управляется программно. В том варианте прошивки заменен загрузчик, в котором отключен софтверный сброс PHY. Чтобы убедиться что все прошилось, зайдите в telnet и наберите команду sh ver должно быть bsp: exact: 2-1798137ed cdate: 20 Oct 2020 Завтра еще соберу один вариант (его можно уже шить с web, если будете шить с этой кастомной версии), добавлю аппаратный сброс RTL8211FS при загрузке ядра. Если не поможет, значит виснет именно сам модуль (его SerDes), видимо требует задержки подачи питания относительно power-on-reset RTL8211FS. Сделайте 2 раза, первый при мертвом линке после холодного старта, второй после пере-подключения модуля (через секунд 30 после пере-подключения). Лучше в поддержку отослать, мы каждый день встречаемся.

aarnet Метаноевские модемы обновляются через сетевой EBM протокол, так что обновлять его прошивку можно самому. У нас на фабрике (Тайвань) есть такие модемы, но в офисе вроде бы нет. Дополнительную поддержку управления таких модемов (настройка, чтение статистики) делать пока не планируется. Я сегодня отдам в поддержку прошивку KN-1010, она обновит вам загрузчик. Если проблема холодного старта уйдет, то загрузчик положим в апстрим сборку KN-1010. KorDen Питание SFP на этих устройствах не управляется программно, так как нет свободных GPIO пинов, все заняты по схеме. Логика переключения аппаратная, чип находится в комбо режиме SerDes/MDI и сам переключает источники, в зависимости от линка. В том числе детектор 1000Base-X/100Base-FX также аппаратный. LED также аппаратный и сигнализирует о SGMII линке. Как я уже говорил выше, если линка нет, то либо завис сам модуль (такое реально), либо модуль выдает неправильный режим SGMII/SerDes, например отличается частота клока. Медные и DSL модули обычно сразу же зажигают линк SerDes без наличия физического линка (и это может быть проблемой затора на GigabitEthernet1 интерфейсе, если среда не подключена). Оптические модули зажигают линк SerDes только при наличии линка среды. Hero/Peak DSL нет ограничения, на 30a поднимает линк до 198mbps, на 35b до 348mbps. Однако зависит от настроек DSLAM на перераспределение RX/TX поднесущих. Плюс hw_nat поддерживается.

Наводящий вопрос - если при подключенном VDSL SFP модуле перезагружать Keenetic без отключения питания (например через CLI или Web), после перезагрузки все работает нормально? Проблема только при подаче питания на холодную?

Да, поведение характерное, скорее всего проблема именно со сбросом PHY. Обратитесь в нашу техподдержку, придумаем как вам для теста собрать прошивку с обновлением загрузчика. Если удаление сброса PHY из загрузчика не поможет, то решения скорее всего нет, вероятно такому модулю нужна задержка подачи питания чтобы аппаратный сброс PHY (power-on-reset) завершился ранее. Первое вспыхивание LED - аппаратный self-test RTL8211FS при power-on-reset.

Нет, LED напротив SFP слота Кинетика. Этот LED отображает актуальный SGMII линк в SFP слоту. LED на самом модуле обычно показывает линк физики.

aarnet Наличие SFP модуля в слоте определяется либо по аппаратному пину, либо по DDMI Info через I2C. Однако, комбо-конвертор RTL8211FS должен увидеть SGMII линк в SFP слоте, после чего он аппаратно переключается на SerDes интерфейс. В вашем случае при холодном включении это не происходит. У нас была подобная проблема с Metanoia VDSL2 модулем, пришлось добавить проверку на SerDes mode, при котором сброс PHY не выполняется. Cброс PHY требует фабрика, чтобы проходил EMI тест (включение SSC и отключение CLK_OUT пина требует выполнить сброс PHY). Так вот, если обнаружен SerDes режим, то сброс PHY пропускается в загрузчике. В вашем случае похоже что модем долго инитится при подаче питания и сброс PHY проходит, после чего модуль не зажигает SGMII линк. Пока линка нет, сделать ничего нельзя, комбо-конвертор переключается автоматически по наличию SGMII линка. Проверяется очень просто - если SFP LED не горит, то SGMII линка в слоте нет. LED аппаратный.

Rakerunner Транслировать можно, но надеяться на исправление особо не стоит, так как проблема в wireless драйвере клиента, от которых у большинства вендоров просто нет исходников. - У нас в офисе был ранее Huawei Honor 8, который имел ту же самую проблему. Будучи на Тайване, мы хотели при встрече с вендором рассказать о подобной проблеме, но продемонстрировать ее не смогли, с тайваньской SIM картой данный смартфон на всех каналах работал на 80MHz, не применяя региональное ограничение. Новые чипы MT7615, MT7613 и выше имеют более интеллектуальный rate_ctrl, (чем MT7610 и MT7612), на них эта проблема не сильно выражена, они могут при подборе рейта "сесть" на 40Mhz и там долго сидеть и в целом все выглядит прилично. Разве что первые 10..20 секунд будут блуждать из-за ретрансмитов. В чипах MT7610 и MT7612 это не работает, поэтому для них лучший вариант - это фиксация полосы в VHT40.

Все ваши устройства, не-работающие на VHT80 МГц, по факту включают региональное ограничение, заложенное в их прошивке. Это ограничение переводит их в 40МГц, включает фильтр по полосе 40МГц на RX. Самая главная беда этих устройств, их клиентский WiFi драйвер не уведомляет AP через VHT Operation Info, что они ограничены полосой 40МГц и AP пытается с ними работать на 80МГц. Почти все Data фреймы не доходят (так как RX фильтр на них режет полосу до 40), со всеми вытекающими. В стандарте 802.11ac есть 2 механизма уведомления: 1) статический, через assoc request клиент указывает в VHT Operation Info что он ограничен 20/40. Используется на всю сессию подключения. 2) динамический, клиент отправляет Action пакет типа VHT Operation Mode Notification, где может динамически уведомлять AP о смене числа стримов и полосы много раз во время одной сессии подключения. Подобные клиенты, когда зажимаются в 40МГц региональным ограничением, никак не уведомляют AP ни одним из этих механизмов, поэтому AP справедливо считает что клиент пришел умеючи 80МГц. И начинается свистопляска с перебором линков rate control. С выходом iOS 13 эта проблема постигла множество старых Apple устройств, таких как iPhone 6S, iPad2 Air итд. По крайней мере все такие RU устройства теперь зажимаются в 40МГц на всех каналах, кроме 149..161, там осталась поддержка 80. Эти устройства имеют старый Broadcom драйвер, который не умеет уведомлять AP ни одним из перечисленным способом. Apple подложила свинью в паре с Broadcom. - Мы уже сейчас готовим решение, которое будет позволять отмечать зарегистрированные устройства, чтобы AP с ними переходила на VHT40.

Наводящий вопрос - если переключить в настройках точки доступа 5ГГц полосу в 40MHz, проблема c провалом линка уходит на данных устройствах?

Клиент сам выбирает лучший вариант, причем если поддерживает FT, то будет переключаться бесшовно. Нельзя прибить клиента к конкретной AP, потому что именно сам клиент выбирает кандидата в качестве AP. Единственный механизм со стороны AP - это WNM, но он лишь просит перейти, клиент все равно сам решает.

На смартфонах полоса 160 все же избыточна, это в основном удел для десктопов и ноутов, чтобы получать до 900mbps в пике (например копирование с NAS). Под рукой Galaxy S10 на exynos, он не поддерживает 160, однако на 80 прекрасно выдает до 650mbps даже со Speedster KN-3010.

В диапазоне 5ГГц всего два сплошных блока по 160МГц 36..64 100..128 причем, они могут быть недоступны для определенных регионов. Выбирая конкретный 20МГц канал внутри блока 160, вы по сути задаете только центральный канал VHT. Реальные данные передаются по всему блоку спектра. Странно что смартфон ведет себя подобным образом, по идее вообще нет разницы, какой центральный канал VHT выбирать внутри блока 160. Возможно какие-то ошибки в драйвере.

При использовании полосы 80 и 160 теряется какой-либо смысл в автовыборе канала. Поставьте ручной канал 36 и проверьте

Dkray При установке полосы 160МГц выбираете канал под сплошной кусок спектра? Если сплошной кусок недоступен, web выставляет 80+80, это видно в running-config. Под рукой два разных Intel 9260AC крайне плохо работают в 80+80. При этом хорошо работают в сплошном 160. Cкоро должны подойти Intel AX200, надо будет их глянуть. Наводящий вопрос - у вас ранее работал данный клиент на 160МГц с нормальными скоростями? Текущий микрокод, который управляет подстройкой rate_ctl чипа радио неизменный с 2.15. Если ранее были другие результаты, сообщите.