Padavan

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

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 разгрузка работает без проблем.

vadimbn > это их процессор глючит Не нужно подменивать понятия, он просто не поддерживает UDP оффлоад со всеми типами пакетов. В коде SDK оффлоад UDP на этих чипах просто выключен. Совсем. Мы сделали возможность разгрузки UDP на этих устройствах, но недочет в том, что не сделали возможности его отключать отдельно.

Dobryak vadimbn Это не дефект оборудования, а известная особенность, начиная еще с Ralink чипов. Если посмотрите на белые кинетики на базе чипов RT3052, там точно такая-же картина с UDP оффлоадом. И точно такая-я же как в первых Lite2/Omni. Устройства обладают заявленным функционалом. Вы нигде не найдете на коробке заявленного UDP оффлоада. Каждый год выходят новые чипы, поэтому устройства постоянно получают дополнительные аппаратные плюшки. Еще раз подчеркну - это не дефект, а отсутствие аппаратной плюшки, которая есть в других, более новых устройствах (на том же чипе MT7621). Решение проблемы с TeamSpeak есть, но за счет отключения UDP оффлоада. Считайте что его просто нет в этих устройствах.

Sovenok На Viva/Extra установлен чип MT7620 ревизии 0204, который не умеет UDP трафик без чексумм через PPE. Других ревизий чипа на этих девайсах не было. TeamSpeak отключает и включает налету внутри одного flow UDP чексуммы, такой расклад не может работать на данном чипе (оффлоад через PPE). Более новые Keenetic на чипах MT7621 (Giga3/Ultra2) и MT7620 rev 0206 (Lite3 rev A/Omni2/Keenetic3) работают с UDP трафиком без чексумм, причем внутри одного flow чексуммы могут как быть, так и не быть. Для uTP протокола обычно нет проблем с чексуммами, так что оффлоад UDP под торрент-клиентами на Viva/Extra работает. Здесь дилемма - либо отключать UDP оффлоад совсем (оставляя только TCP), либо делать оффлоад UDP отключаемым из командной строки. Одно время оффлоад UDP был отключен жестко на Viva/Extra, при этом было много гневных писем о загрузке CPU под торрентами (эти пользователи обычно не отключают uTP в торрент -клиенте). Так что тут дело не в Keenetic, просто на тот момент времени не было других чипов. MediaTek начал очень поздно поставлять чипы 0206. На том же старом N56U установлен чип RT3883 который точно также не умеет оффлоадить UDP трафик без чексумм. И это нельзя изменить.

Криптодрайвер пофикшен, имел стопку детских болезней, что приводило постоянно к дедлокам (и ребутам по watchdog таймеру), а также панике. Сам аппаратный модуль в чипах MT7621 и RT6856/RT63368 абсолютно идентичный, совпадают все ревизии и капсы PEC. Так что все найденные и исправленные проблемы актуальные для всех 3 чипов. В ту пятницу вошла только незначительная часть исправлений по криптодрайверу, дедлоки там еще не были поправлены. На этой неделе будет финальный вариант.

Работает и в N и AC. С лета, tx-burst отключен по умолчанию, так как заваливает результаты speedtest RX у провайдеров, использующих шейпинг (большинство провайдеров с FastEthernet на доступе) и доступен для изменения через CLI. Ранее всегда был включен. tx-burst улучшает скорость при отсутствии шейпинга (LAN - WiFi, USB - WiFi трафик, WAN трафик со многими GPON провайдерами). Это не проблема конкретных Wireless чипов, тот же BCM4360 ведет себя точно также, tx-burst в 802.11 по дизайну работает плохо с зашейпленным TCP трафиком.

Обработка транзитного трафика LAN -> Wireless и WAN -> Wireless сильно отличается от обработки локального трафика (например USB3 -> SMB -> Wireless). Не вижу никаких проблем с транзитным трафиком, 20МБ/с с 2T2R клиентом в 11n. Если нужно получить максимальную скорость Wireless и не важно кол-во попугаев в спидтесте (на провайдерах, использующих шейпинг), включайте tx-burst через CLI, он дает профит на UDP и на TCP с небольшим буфером, Linux-based клиенты обычно юзают cifs клиент, который по умолчанию использует буфер всего 16K.