Padavan

Работает и в 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.