Padavan
-
Posts
454 -
Joined
-
Last visited
-
Days Won
26
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Padavan
-
-
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 аппаратный.
-
2
-
-
Проблема подтверждается, будет исправлена в очередной сборке.
-
3
-
-
Rakerunner
Транслировать можно, но надеяться на исправление особо не стоит, так как проблема в wireless драйвере клиента, от которых у большинства вендоров просто нет исходников.
-
У нас в офисе был ранее Huawei Honor 8, который имел ту же самую проблему. Будучи на Тайване, мы хотели при встрече с вендором рассказать о подобной проблеме, но продемонстрировать ее не смогли, с тайваньской SIM картой данный смартфон на всех каналах работал на 80MHz, не применяя региональное ограничение.
Новые чипы MT7615, MT7613 и выше имеют более интеллектуальный rate_ctrl, (чем MT7610 и MT7612), на них эта проблема не сильно выражена, они могут при подборе рейта "сесть" на 40Mhz и там долго сидеть и в целом все выглядит прилично. Разве что первые 10..20 секунд будут блуждать из-за ретрансмитов. В чипах MT7610 и MT7612 это не работает, поэтому для них лучший вариант - это фиксация полосы в VHT40.
-
1
-
-
Все ваши устройства, не-работающие на 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.-
4
-
-
Наводящий вопрос - если переключить в настройках точки доступа 5ГГц полосу в 40MHz, проблема c провалом линка уходит на данных устройствах?
-
Цитата
есть подозрение что сломалось после 3.4.3 надо будет проверить
Очень сомневаюсь, в 7615 драйвере 4-way hs не менялся. Было несколько исправлений 2-way hs (group rekey) а также множество исправлений по FT примерно с мая. С вашими клиентом явно проблема в 4-way hs.
-
Глянул по ссылке, там никакой конкретики. При этом другой человек пишет, что ему увеличение max retries to 4 and timeout to 2000 никак не помогло. Лучшее решение - сделать дамп эфира к AP во время подключения с ошибкой и к той AP, к которой заведомо подключается успешно. Я разберу дампы и возможно смогу помочь. Если сможете это сделать, присылайте сразу в техподдержку, мы каждый день на связи.
-
All
Если AP застреливает клиента с сообщением had been aged-out and disassociated (retransmits limit reached), это означает что при передаче данных клиенту, клиент не прислал ни одного ACK/Block ACK на серию передач к нему. В итоге после последовательного накопления 2000 ретрансмитов, считается что клиент мертв (например просто ушел из зоны связи) и удаляется. Важно что выполняется проверка, если клиент находится в PSM режиме, он не удаляется. Так что с большой долей вероятности клиент ушел в Power Save Mode, не уведомив AP.
По поводу согласования GTK ключа (bcast/mcast) трафик, в свежих версиях 3.04 выводится подробная информация о Group rekey. Если у вас rekey отключен, то пере-согласование не выполняется и GMK на AP не меняется. Рекомендуемый период Group rekey для AES шифрования - 86400 секунд (сутки). Если Group rekey прошел не успешно (например клиент уснул и не ответил в течении минуты), то драйверы 7615 и 7613 сейчас удаляют клиента с ошибкой Group rekey timeout, поскольку AP меняет GMK и все кто не получил новый GTK, не смогут получать bcast/mcast фреймы.
-
Dick
Нужно смотреть эфир 802.11 во время подключения такого клиента. Либо клиент слишком часто повторы EAPoL Msg2/4 шлет, либо наоборот долго отвечает. С нашей стороны драйвер выполняет до 3 повторов, если от пира нет EAPoL пакета в течении секунды. С другой стороны, неверный MIC говорит о том что либо PSK неверный, либо клиент несколько раз пачкой шлет EAPoL Msg2 с одним SNonce.
Можно сказать, что чип здесь не имеет значения, так как 4-way хендшейк программный.
ЦитатаПохожая проблема у другого производителя правиться параметрами
config advanced eap eapol-key-timeout
config advanced eap eapol-key-retriesБыло бы интересно на это взглянуть.
-
1) MU-MIMO переименована в DL MU-MIMO (Downlink) по причине совместимости с Wifi6 (там добавляется Uplink)
2) MU-MIMO в 2.4GHz невозможна по дизайну Wifi5, так как OFDM фреймы при включении 256QAM не меняются, меняется только максимальная модуляция. В описании CLI и web была допущена ошибка.
3) MU-MIMO в 2.4GHz по дизайну возможна только в Wifi6.
4) В Wifi5, на 2.4GHz с KN-1810 доступен только HT Explicit/Implicit Beamforming и QAM256. С KN-1010, 1910 доступен только QAM256.
-
3
-
1
-
-
r13
На rxrate смотреть не стоит, там выводится последний rate, который был получен из RX пакетов клиента. Он не на всех чипах сейчас выводится корректно, туда могут попадать legacy пакеты, например с линками 1 или 6.
txrate - да, это текущий ucast TX rate при передаче от AP к клиенту data фреймов и им управляет rate_ctl.
-
Sonpul Sonpulov
Пока могу связать проблему сваливания линка только с обновлением драйвера MT7615 5.0.5.0, который используется в ветке в 3.05, у него микрокод MCU новее, чем был в ветке 3.04. Микрокод закрытый, поэтому достоверно сказать не могу, были ли там изменения, которые могли затронуть rate_ctl.
-
1
-
-
drugold
KN-1910 на базе чипа MT7615D, у него rate_ctl полностью управляется внутренним микрокодом MCU. А это означает, что на одной и той же версии микрокода MCU логика всегда одинаковая и не зависит от прошивки совсем. Версия микрокода на некоторых чипах выводится в системный лог при загрузке системы, я проверю и добавлю вывод для MT7615 и MT7613, если сейчас это не выводится.
На текущий момент в ветке 3.03, 3.04 используется драйвер 5.0.4.0, в ветке 3.05 используется 5.0.5.0 (версия микрокода новее).
Fallback to CCK в 2.4 у нас также давно запрещен, если в настройках задан режим, не включащий 11b (например 11g/n).
Идея переподключения клиента, когда он свалился на дно rate_ctl таблицы не выглядит хорошо, потому что это нормальное поведение при long-range клиенте. Любое переподключение - это deauth клиента со всеми вытекающими. Apple iOS клиенты, например, если их напнуть 3 раза подряд с интервалом менее 180 секунд, вносят эту AP в бан лист и больше не будут к ней автоматически подключаться, пока не тапните вручную.
-
2
-
1
-
-
Sonpul Sonpulov
Привязка к диапазону работает по принципу блокирования смежного диапазона. Т.е. если вы включили MAC привязку к 5GHz, то данному MAC драйвер в 2.4GHz не отвечает ни на probe response, ни на assoc response, ни на auth request. Никакой явной причинно-следственной связи с падением линка на противоположном диапазоне от этого быть не может.В таблице подключенных клиентов отображается его текущий TX rate от AP к клиенту. Им управляет встроенная логика rate_ctl и текущий TX rate зависит от множества факторов, основной - это RSSI, BER, количество ре-трансмитов. Когда клиент подключается, AP обычно выставляет для него максимальный поддерживаемый TX rate за минусом Short GI. Дальнейший TX rate будет всегда дышать и зависеть от передаваемых данных и работает это автоматически, в новых чипах весь алгоритм rate_ctl спрятан во внутреннем микрокоде MCU.
Значения линка в OFDM 6 (это и есть 11a) при среднем уровне RSSI говорят от том, что от клиента наблюдается пропуски ACK-ов (большое количество ре-трансмитов к нему во время передачи данных), поэтому rate_ctl снижает линк до него до нижнего порогового значения.
-
1
-
-
KorDen
Нужна доп. информация по KN-1810 (о проблеме 255 dBm)
- Какой канал выбран (если вручную)
- Какая ширина полосы
- Включен ли RRM (галка "Управление BSS-окружением 802.11k/v") -
US код региона форсируется только для кода RU в 5ГГц, это давний костыль для 802.11d, нужен определенным Apple устройствам c 11ac. Костыль один для всех чипов.
Насчет 255 dBm похоже на баг в драйверах 7615 и 7613, там ранее подобная проблема была с TPC репортом, показывало 63dBm, это давно поправлено. Я проверю и исправлю, спасибо за замечание.
Вендор, модель и серийный номер давно заполняются в WPS IE, больше года назад, такое требование руководства.
-
Цитата
при создании WiFi-сети из 3х роутеров - есть возможность явным образом назначить подключение определенных клиентов к конкретным роутерам
Клиент сам выбирает лучший вариант, причем если поддерживает FT, то будет переключаться бесшовно. Нельзя прибить клиента к конкретной AP, потому что именно сам клиент выбирает кандидата в качестве AP. Единственный механизм со стороны AP - это WNM, но он лишь просит перейти, клиент все равно сам решает.
-
На смартфонах полоса 160 все же избыточна, это в основном удел для десктопов и ноутов, чтобы получать до 900mbps в пике (например копирование с NAS). Под рукой Galaxy S10 на exynos, он не поддерживает 160, однако на 80 прекрасно выдает до 650mbps даже со Speedster KN-3010.
-
2
-
-
В диапазоне 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. Если ранее были другие результаты, сообщите.
-
1
-
-
All
Проблема была сложна для воспроизведения и отладки, поэтому решение затянулось.Есть большая вероятность что проблема решена, по крайней мере на Ростелекоме больше не воспроизводится в течении 13 часов стриминга. Исправление вошло в 3.3 Alpha 4, а также войдет в ближайший 3.01. Большая просьба отписаться по результату.
Для выявления проблемы желательно смотреть канал в дневное время, когда присутствует большая активность абонентов.
Вкратце, проблема была:
- не связана с nimproxy, то что работал igmpproxy из Entware было следствием отключения галки IGMP proxy
- не связана с IGMP стеком ядра 4.9
- не связана с какими либо ускорялкамиПри большой активности IPTV абонентов, когда они уходят с канала, который в это время смотрите вы, IPTV сервер провайдера рассылает всему сегменту Group Specific Query с данной группой, на который нужно быстро ответить (обычно в течении 1 секунды). Если не ответить вовремя, сервер тихо исключает вас из рассылки и поток на наш WAN порт останавливается.
-
7
-
2
-
-
Эта тема актуальная, спасибо за дополнение.
-
1
-
-
Поддержки каналов 32 и 34 пока нет, в старые устройства (чипы MT7610/MT7612) поддержку добавить не составит проблем, но поддержка в чипе MT7615 может быть пока затруднена, так как зависит от поддержки в микрокоде. Будем выяснять у вендора.
-
r13
У вас удобные логи для отладки, оба радио неактивны, пакетов по ним нет, счетчик прерываний по ним также стоит. И USB тоже. И тем не менее, утечка очень большая.
Судя по SLAB-у и vmstat-у ничего криминального, при этом видно что pagecache reclaim работает хорошо и динамически высвобождает 50% pagecache от размера свободной RAM. Так как в SLAB разбуханий не обнаружено, остается только страничный аллокатор, он используется для аллокации RX буферов в Ethernet драйвере. Именно он уменьшает кол-во свободных страниц, но число in flight страниц по нему не видно. А значит где-то не освобождаются RX skb на Ethernet. Для дальнейшего исследования этой проблемы нужно переключить Ethernet драйвер на SLAB аллокатор, тогда все Ethernet RX skb буферы будут видны в SLAB kmalloc-2048.
@Le ecureuil соберет вам прошивку с SLAB аллокатором на Ethernet, чтобы in flight Ethernet буферы появились в slabinfo.
SFP-VDSL
in Обмен опытом
Posted
Нет, LED напротив SFP слота Кинетика. Этот LED отображает актуальный SGMII линк в SFP слоту. LED на самом модуле обычно показывает линк физики.