LINUX.ORG.RU

Packet Processing Engine (PPE): NAT Offload

 ,


0

2

Кто нибудь имел дело с программной поддержкой такой аппаратной фичи?

Сейчас маюсь с таким модулем SoC'а MT7621. Имеется в наличии фирменная библиотека Ralink, активирующая такую фичу, прикрутил ее к OpenWRT в связке с фирменным ethernet драйвером. Но хардварный нат так и не заработал.

Проблема в том, что нет понимания (хотя бы абстрактного) как это должно работать. Сейчас имею примерно такое представление: каждый полученный ethernet фрейм до попадания в драйвер (то есть в память CPU = OS) проходит через со-процессор PPE, который в дескрипторах фрейма прописывает определенные поля (каждого фрейма) и меняет адреса в IP заголовках (если пакет подлежит ре-трансляции).

Поправьте меня, если я неверно представляю себе механизм работы.

В моем случае, нет никаких признаков работы со-процессора, то есть нет записей в дескрипторах полученных фреймов. Может натолкнете в верном направлении, куда капать? Может кто то сталкивался с подобной задачей или имел дело с аппаратным натом Ralink.

PS: регистры PPE при иниализации прописываются корректно

Аппаратный NAT если он работает, ты на роутере никак не увидишь, траффик из PPE не выходит и сразу улетает клиенту, как максимум ты сможешь из регистров почитать стату.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Как он понимает, какие пакеты сыпать мне на вход (в драйвер = в ОСь), а какие в обход системы (мимо меня) на выход?

k000858
() автор топика
Ответ на: комментарий от k000858

Ты это регистрами конфигуришь. ЕМНИП, там задаётся матрица типа extip:port <-> intip:port и после этого ты пакеты в стеке ОС не увидишь.

Но я в эту часть даташита толком не смотрел, могу ошибаться.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

А может есть идейки куда можно посмотреть, если в моем случае работает ни как задумано? То есть мне в драйвер валятся все пакеты как обычно, как будто ППЕ не активирован, хотя вроде все регистры прописаны..

Еще интересно зачем в драйвере вызываются hwnat-хуки, не очень хорошо понял по коду всю механику..

k000858
() автор топика

Обычно, реализации hwnat в linux требуют патчей netfilter и conntrack. Все новые неклассифицированные пакеты приходят в Linux как обычно, а когда настает время переходить в состояние ESTABLISHED, на hwnat подается команда добавления соединения с заданными ip-адресами, протоколом и портами.

ValdikSS ★★★★★
()

За такую информацию (нормальную, написанную человеческим языком спеку по hwnat) вообще головы отрывают... :)
Потому все, кто смогли додуматься как это работает путем изучения и многочасовыми затяжками китайских исходников врядли бесплатно вам это дадут - коммерческая тайна.
Хотя, вон nbd в OpenWRT (на 99% уверен, ему тоже за это неплохо заплатили) все же потихоньку приводит эту сран^W штуку к рабочему виду).

anonymous
()
Ответ на: комментарий от ValdikSS

Это так должно работать с точки зрения ядра.
А с точки зрения китайцев на коннтрак и прочую муть вообще срать - этот модуль сам заполняет FOE, сам определяет что наступил BIND_HIT, и сам начинает обрабатывать трафик, пока не наступил UNBIND по рейту (естессно, в родном SDK никак не уведомляя при этом ядро (keepalive не считаем, это костыль сраннее самого PPE)).

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.