Padavan

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.

Есть мнение, что проблема в SMB клиенте Android, ибо под Windows проблем с SMB не наблюдается, по проводу чтение с USB3 85МБ/с (чтение можно поднять до 100МБ/с, будет в ближайших версиях), по воздуху в зависимости от линка и условий до 35МБ/с.

IgaX Драйвер перечитывает настройки из dat файлов только при поднятии первого инстанса любого интерфейса. Соответственно чтобы он их перечитал, нужно положить все интерфейсы одного радио и поднять нужный заново. Если преследуете академический интерес, то NDM прошивка меньше всего подходит для этого, она изначально проектировалась под CLI и в ней нет никаких инструментов для пытливого ума.

В этом логе нет ничего полезного для решения описанной проблемы. По крайней мере устройство точно рабочее.

Речь о выделении порта под IPTV приставку или VoIP (бридж с WAN портом). В этом случае формируется софт-бридж Linux, который без проблем оффлоадится через PPE.

Никто специально локальный трафик не загоняет в conntrack, так работает Linux. Предвидя вопрос - "а как-же NOTRACK", отвечу - никакого профита на локальном трафике от NOTRACK нет, только лишние хуки в RAW таблице iptables. И лишние проблемы, если требуется сNAT-тить что-то для локального трафика (например сменить внешний порт на внутренний). Сейчас в 2.07 на девайсах с 64 и 128МБ RAM установлен лимит в 8K соединений, на 256МБ - 16K соединений. Если вы обновляли прошивку поверх, лимиты могли остаться старые, но выставятся по умолчанию после сброса настроек. Либо если сами добавите руками в конфигурацию требуемый лимит, например set net.netfilter.nf_conntrack_max 16384

Если быть точнее, то это не сетевая карта, а полноценный свитч, используется только один порт. MT7621 [GE1] -> GSW MT7530 (on-chip) -> Синий WAN MT7621 [GE2] -> GSW RTL8370M -> Желтые LAN Чтобы было понятно, на MT7621: - Все VLAN-ы аппаратно оффлоадятся (pop/push), как для локального трафика, так и для ускоряемого через PPE (hw_nat). - Трафик в бриджах Linux также оффлоадится через PPE (hw_nat). Ничего мудрить не требуется. Пропускная способность между Синим портом и Желтыми ~2Gbps. Если делать WAN порт на одном желтом порту, то пропускная способность между Желтым WAN и Желтыми LAN ~1Gbps. - Единственный минус аппаратного оффлоада бриджей на текущий момент - PPE отнимает TTL на единичку, как у маршрутизируемого трафика. В планах есть сделать распознавание бриджа и динамическое управление TTL битом в PPE.