Padavan
-
Posts
454 -
Joined
-
Last visited
-
Days Won
26
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Padavan
-
-
GConst
Сегодня обсуждали решение, скорее всего оно сведется к отдельному выключателю, при этом, если UDP оффлоад будет отключен, он будет автоматически подхватываться в PPE software, это как минимум в 2 раза будет разгружать CPU на сложном uTP трафике.
Пока это предварительное решение. Основная цель - чтобы пользователь просто обновил прошивку и у него проблема с VoIP софтом (включая TeamSpeak) решилась автоматически.
-
5
-
-
Dobryak
Я предложил решение. И мы его реализуем в ближайшее время. Других вариантов нет. То, что существует подобная проблема с VoIP приложениями на данных устройствах - проблема софтовая, та как мы не сделали отключение UDP оффлоада на этих устройствах.
100% оффлоад UDP на устройствах с гигабитными портами есть только на Giga3 и Ultra2 (и старых Giga2/Ultra/LTE на RT6856/63368).
2 hours ago, Dobryak said:В описании нет ни слова о том, что с частью приложений, этого самого "аппаратного ускорения" просто нет
Там многих деталей нет. Например, что аппаратное ускорение отключается для хоста при включении на него шейпера/QoS. Потому что оно по дизайну не совместимо c PPE. Что аппаратное ускорение работает только с Wired.
И это не дефект, поэтому отзыву не подлежит, вы привели некорректное сравнение.
-
4
-
-
Не могли бы вы выложить кусок лога, с момента ухода RootAP на смежный канал где происходит ложное подключение без смены канала, когда свои клиенты залипают.
Там будет характерное:
Wi-Fi client disconnected by peer client disconnected probe request ... probe response Wi-Fi client authenticated Wi-Fi client associated
Как раз probe response - это ответ от RootAP. Нужно понять, когда приходит ответ с соседнего канала - до рескана или уже после. -
Да, так и есть, спасибо за фидбэк.
Можно попробовать реализовать форсированный переход на рескан эфира после отключения AP-Client от RootAP. Рескан эфира происходит в полосе 20МГц, поэтому вероятность ложного ответа с соседнего канала исключена.
Сейчас рескан эфира также выполняется, но сначала делается до 5 попыток probe на текущем канале. Если RootAP не ответила, тогда уже делается рескан эфира и переключение на тот канал, где сидит нужная RootAP.
-
Root-AP не скрытая случаем?
-
Проверю со смежным каналом. Я проверял до этого любые вариации, но при значительной смене канала (разница > 1). AFC на Wireless работает в большом диапазоне, поэтому клиент теоретически может законнектиться к AP на смежном канале. Именно это я и вижу в том что вы описали выше. Клиент умудряется законнектиться без смены канала (при этом пакеты практически не ходят, так как частота сильно в стороне, но AFC все же позволило услышать ответ и произвести подключение). Поэтому модуль канал не меняет, клиенты остаются висеть на старом канале и до хоста роутера пинг проходит. Но не дальше.
Вы в свою очередь проверьте что описали выше, только на RootAP уйдите хотя бы на два канала в сторону. Должно работать четко. -
IgaX
К сожалению проблему воспроизвести пока не удается. Ни в режиме Router + WISP, ни в режиме Усилитель (Repeater).
AP-Client всегда корректно переподключается к корневой точке доступа, при этом автоматически обновляется информация о расширенном канале (выше/ниже). Любые переключения канала на корневой точке ведут к переподключению AP-Client.
При этом, драйвер не отправляет клиентам своей AP никакой информации об уходе с канала. Как только AP уходит с текущего канала, дальше срабатывает логика на клиентах. Клиент, не получив маяка с текущей AP (обычно таймаут 4 секунды) считает AP пропавшей из эфира, делает заново рескан эфира и если находит AP на другом канале, автоматически к ней переподключается. Иногда он может подключиться к другой AP, сохраненной у него в списке, если видит эту другую AP в эфире и считает что на ней сигнал лучше. Это уже зависит от агрессивности роуминга на клиенте.
Не получилось добиться ни одного провисания на разных клиентах, включая iOS 10и Android 5/6. Под Windows 10 с Intel клиентом также всегда происходит переподключение и восстановление передачи данных.
Судя по вашему описанию, у вас клиент не пытается пересканировать эфир и переподключиться, когда AP уходит с текущего канала. Другого объяснения не вижу. Вы могли бы назвать точную марку клиентского адаптера и версию OS/драйвера на котором видна проблема?
-
JIABP
Спасибо.
16 minutes ago, JIABP said:Видимо действительно такое происходит когда находишься во внутренней Wi-Fi сети.
Ммм... Уточните, вы подключались ранее (когда падало) к Virtual-IP из LAN подсети через Wireless точку доступа?
-
JIABP
Скиньте пожалуйста конфиг с Giga 3, на котором запущен IPsec Virtual IP сервер. Это поможет нам ускорить воспроизведение проблемы.
-
11 hours ago, Dobryak said:
Получается, что для бесперебойной работы, важную часть функций устройства приходится отключать, и в итоге мой Keenetic работает не быстрее, чем значительно более дешевые устройства.
Отключение оффлоада полностью конечно не есть хорошо, вы теряете разгрузку TCP, которая работает замечательно на этих устройствах.
Могу предложить только 2 решения
1) Отключить разгрузку UDP принудительно, на уровне драйвера.
2) Сделать возможность отключения/включения разгрузки UDP из командной строки. Так как c uTP разгрузка работает без проблем.-
2
-
-
vadimbn
> это их процессор глючит
Не нужно подменивать понятия, он просто не поддерживает UDP оффлоад со всеми типами пакетов. В коде SDK оффлоад UDP на этих чипах просто выключен. Совсем. Мы сделали возможность разгрузки UDP на этих устройствах, но недочет в том, что не сделали возможности его отключать отдельно.
-
2
-
-
Dobryak
vadimbnЭто не дефект оборудования, а известная особенность, начиная еще с Ralink чипов. Если посмотрите на белые кинетики на базе чипов RT3052, там точно такая-же картина с UDP оффлоадом. И точно такая-я же как в первых Lite2/Omni. Устройства обладают заявленным функционалом. Вы нигде не найдете на коробке заявленного UDP оффлоада.
Каждый год выходят новые чипы, поэтому устройства постоянно получают дополнительные аппаратные плюшки. Еще раз подчеркну - это не дефект, а отсутствие аппаратной плюшки, которая есть в других, более новых устройствах (на том же чипе MT7621).
Решение проблемы с TeamSpeak есть, но за счет отключения UDP оффлоада. Считайте что его просто нет в этих устройствах.-
2
-
-
blackride
Не переживайте, постараемся решить ваши 2 проблемы. По первой я отписался, она очевидно из-за смены BSSID, ее решение лежит уже на поверхности, даже тикет завел. С текущей - попробую воспроизвести.
Вы поймите, с Wireless часто проблемы индивидуальны и на других устройствах их сразу не видно. Если не сможем воспроизвести текущую проблему, придется разыскивать LG Nexus 5.
-
3
-
-
Sovenok
Quoteвидимо исправить это можно лишь заменой роутера на любой кроме кинетика.
На 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 трафик без чексумм. И это нельзя изменить.
-
3
-
-
Криптодрайвер пофикшен, имел стопку детских болезней, что приводило постоянно к дедлокам (и ребутам по watchdog таймеру), а также панике.
Сам аппаратный модуль в чипах MT7621 и RT6856/RT63368 абсолютно идентичный, совпадают все ревизии и капсы PEC. Так что все найденные и исправленные проблемы актуальные для всех 3 чипов.
В ту пятницу вошла только незначительная часть исправлений по криптодрайверу, дедлоки там еще не были поправлены. На этой неделе будет финальный вариант.
-
3
-
-
Работает и в N и AC.
С лета, tx-burst отключен по умолчанию, так как заваливает результаты speedtest RX у провайдеров, использующих шейпинг (большинство провайдеров с FastEthernet на доступе) и доступен для изменения через CLI. Ранее всегда был включен. tx-burst улучшает скорость при отсутствии шейпинга (LAN - WiFi, USB - WiFi трафик, WAN трафик со многими GPON провайдерами). Это не проблема конкретных Wireless чипов, тот же BCM4360 ведет себя точно также, tx-burst в 802.11 по дизайну работает плохо с зашейпленным TCP трафиком.
-
2
-
-
Обработка транзитного трафика LAN -> Wireless и WAN -> Wireless сильно отличается от обработки локального трафика (например USB3 -> SMB -> Wireless). Не вижу никаких проблем с транзитным трафиком, 20МБ/с с 2T2R клиентом в 11n.
Если нужно получить максимальную скорость Wireless и не важно кол-во попугаев в спидтесте (на провайдерах, использующих шейпинг), включайте tx-burst через CLI, он дает профит на UDP и на TCP с небольшим буфером, Linux-based клиенты обычно юзают cifs клиент, который по умолчанию использует буфер всего 16K.
-
1
-
-
Есть мнение, что проблема в SMB клиенте Android, ибо под Windows проблем с SMB не наблюдается, по проводу чтение с USB3 85МБ/с (чтение можно поднять до 100МБ/с, будет в ближайших версиях), по воздуху в зависимости от линка и условий до 35МБ/с.
-
Принято, спасибо, попробуем разобраться. Речь о Giga3 я так понимаю?
Канал у AP меняется гарантированно, там общая переменная в драйвере и трансивер общий у AP и AP-Client. -
IgaX
Драйвер перечитывает настройки из dat файлов только при поднятии первого инстанса любого интерфейса. Соответственно чтобы он их перечитал, нужно положить все интерфейсы одного радио и поднять нужный заново.
Если преследуете академический интерес, то NDM прошивка меньше всего подходит для этого, она изначально проектировалась под CLI и в ней нет никаких инструментов для пытливого ума.
-
1
-
-
В этом логе нет ничего полезного для решения описанной проблемы. По крайней мере устройство точно рабочее.
-
Речь о выделении порта под IPTV приставку или VoIP (бридж с WAN портом). В этом случае формируется софт-бридж Linux, который без проблем оффлоадится через PPE.
-
1
-
-
Никто специально локальный трафик не загоняет в 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.
-
1
-
Глючит аппаратный обработчик пакетов.
in Обмен опытом
Posted
Да, LTE забыл включить, там UDP оффлоад тоже работает на любых типах пакетах (чип RT63368 идентичен RT6856, только BigEndian).