Padavan

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% гарантия, иногда бывают осечки. Чтобы исключить смену условий и окружения, не могли бы вы прошить предыдущую сборку и не меняя настроек, попробовать воспроизвести эту проблему на месте? Спасибо.

Да, в логе отображаются только успешный автоскан, когда прошли проверки. Если пропущено, то ничего не пишет.

Solonix Уточните пожалуйста релиз 2.07, на котором проблема не наблюдается в ваших условиях.

Общий трафик ничего не даст. Когда приходит запланированное время для автоскана, проверяется трафик за последние 10 секунд. Если он превысил лимит, то автоскан пропускается. Тут можно сделать небольшую доработку - если лимит превышен, сделать еще хотя бы 3 попытки с небольшим интервалом. И если они провалятся, то уже откладывать до следующего события планировщика

KorDen Как поймаете пропадание AP из эфира, попробуйте сделать следующее - зажмите кнопку WPS дольше 5 секунд - это вызовет отключение радиотракта. И повторная процедура снова запустит радиотракт. Нужно понять, появится ли AP после этой процедуры.

Проверил версию Wireless драйвера mt76x2 в сборке v2.07(ABGH.3)C2, с тех пор изменений было не так много, ни одно из них не касающееся радиотракта, в основном по логике коннекта AP-Client. Так что очень странно. Вчера вышла 2.07.С.4, там Wireless драйвер по срезу идентичный с 2.08.

Трафик виден в закладке Wi-Fi клиентов. Но его придется просуммировать по клиентам, чтобы оценить. В 2 раза поднять лимиты можно, тут главное чтобы не возник дискомфорт от того что AP сменит канал, когда вам не нужно. Так как смена канала вызовет переподключение клиента, что даст затык на 3..5 секунд.

KorDen Для информации - на Giga3/Ultra2/Air/Extra2 используется один и тот же Wireless драйвер 5ГГц mt76x2 3.0.5.0 (т.е. собирается из общего котла). Разница лишь в eLNA (Giga3/Ultra2) и iLNA (Air/Extra2). Если AP исчезает из эфира, значит есть какая-то мощная помеха в 5ГГц. Некоторые бытовые приборы (в том числе HD телевизоры) могут генерить подобную помеху в 5ГГц спектре. Драйвер постоянно подстраивает усиление входного сигнала, опираясь на клиентов. При максимальном усилении чип уязвим для помех, которые могут вызвать флуд на входе, это вызывает пропадание AP в эфире (отсутствие маяков). Как только помеха исчезает, маяки появляются автоматически. Если роутер находится в непосредственной близости с ТВ, попробуйте отнести его на несколько метров. - Можно немного подрезать верхний уровень усиления AGC 5ГГц в драйвере, это позволит избежать подобной проблемы, но немного ухудшится слышимость удаленных клиентов.

Лимиты можно увеличить, предлагайте варианты. Однако здесь есть тонкая грань, которая определяет уровень комфорта. Главное не загрубить.

Значит есть небольшой паразитный трафик. В финальном варианте лимиты такие: RX: 9Kbps TX: 3Kbps Если в течении 10 секунд трафик не превышал этих лимитов, то при приходе планирования автоскана, он разрешается. Иначе пропускается. Когда нет подключенных клиентов - разрешается автоматически. Напоминаю, что в этот момент также проверяется активность WPS кнопки и включенного Wireless клиента (например WISP). При подключенном клиенте любой автоскан блокируется, так как клиент является ведущим, AP - ведомой.

Тут вряд-ли пахнет неисправностью. У 802.11 очень сложная архитектура, и огромное кол-во потенциальных проблем совместимости с разными клиентами. Для примера, недавно выяснили проблему с Honor8, который при подключении сообщает о поддержке 11ac 80МГц, но реально работает на 40МГц. В итоге половину данных что ему шлет AP он теряет и скорость RX очень низкая. Если выставить AP принудительно на 40МГц, работает отлично. Баг в драйвере клиента.

KorDen Уточните версию 2.07, на которой вы проблему не наблюдаете. Для понимания происходящего нужно более точное определение "падает": - Точка 5ГГц пропадает из эфира? - Точка видна в эфире, но данные подключенных клиентов не ходят, а новые подключиться не могут? Если второе, то лечится ли само после отключения данного клиента?

Клиент, который не попрощался с ТД (не отправил DEAUTH) считается подключенным и находится в списке клиентов. Если этому клиенту есть пакеты в очереди (а особенно M2U Multicast), то такая "мертвая душа" будет представлять проблему при передачи данных остальным клиентам. До тех пор, пока такой клиент не будет отстрелен: - либо по таймауту неактивности (300 секунд) - либо по превышению порога ретрансмитов данному клиенту На прошивках 2.08 (а также 2.07.С.2 и выше) используется продвинутый алгоритм подсчета ретрансмитов и отстрел таких клиентов производится достаточно быстро. Однако несколько секунд, пока счетчик накручивается, затыки еще возможны. После того как клиент отстреливается, работа ТД полностью восстанавливается.

В 2.08 точно будет.

GConst https://forum.keenetic.net/topic/541-журнал-изменений-208/?do=findComment&comment=15539 Там как раз проблема была с UDP без чексумм. Сейчас это работает.

Все верно. Софтверный вариант PPE работает как с чексуммами так и без, примерно на 50..60% снижает загрузку CPU. TCP трафик будет проходить через PPE hardware, UDP - через PPE software. При этом вам не нужно отключать PPE hardware, достаточно просто обновить прошивку. Если ранее отключали PPE hadware, то просто наберите в CLI ppe hardware ppe software system configuration save

Да, LTE забыл включить, там UDP оффлоад тоже работает на любых типах пакетах (чип RT63368 идентичен RT6856, только BigEndian).

GConst Сегодня обсуждали решение, скорее всего оно сведется к отдельному выключателю, при этом, если UDP оффлоад будет отключен, он будет автоматически подхватываться в PPE software, это как минимум в 2 раза будет разгружать CPU на сложном uTP трафике. Пока это предварительное решение. Основная цель - чтобы пользователь просто обновил прошивку и у него проблема с VoIP софтом (включая TeamSpeak) решилась автоматически.

Dobryak Я предложил решение. И мы его реализуем в ближайшее время. Других вариантов нет. То, что существует подобная проблема с VoIP приложениями на данных устройствах - проблема софтовая, та как мы не сделали отключение UDP оффлоада на этих устройствах. 100% оффлоад UDP на устройствах с гигабитными портами есть только на Giga3 и Ultra2 (и старых Giga2/Ultra/LTE на RT6856/63368). Там многих деталей нет. Например, что аппаратное ускорение отключается для хоста при включении на него шейпера/QoS. Потому что оно по дизайну не совместимо c PPE. Что аппаратное ускорение работает только с Wired. И это не дефект, поэтому отзыву не подлежит, вы привели некорректное сравнение.

Отключение оффлоада полностью конечно не есть хорошо, вы теряете разгрузку TCP, которая работает замечательно на этих устройствах. Могу предложить только 2 решения 1) Отключить разгрузку UDP принудительно, на уровне драйвера. 2) Сделать возможность отключения/включения разгрузки UDP из командной строки. Так как c uTP разгрузка работает без проблем.