Использую STM32F4 + FreeRtos + LwIp.
Возникла задача принимать некоторые фреймы Ethernet, обрабатывать их не пропуская в стек LwIp, после обработки посилать в Ethernet. При этом не нарушить работоспособность стека LwIp.
Подскажите в каком месте следует перефатывать принятые фреймы, и как передать свой фрейм. Разобраться в исходниках ядра не смог - натыкаюсь на бесконечные переопределения, указатели, семафоры, очереди.
Вобщем не смог проследить путь от netconn_write() до места где данные уходят наружу, там мог бы и подменить буфер с фреймом.

Вот пример от терраэлектроники как они реализуют прием и отправку по Ethernet. Можно попытаться сделать разграничение по двум типам приема: в ручную и стеком. http://forum.promelec.ru/index.php/topic,1828.15.html

Если прямо кадры Ethernet - то в так называемом "драйвере" STM32 Ethernet MAC. Драйвер написан кодерами-индусами из ST, так что разбираться тоже будет непросто. Кстати, мой самописный драйвер имеет размер всего 450 строк.
Если достаточно перехвата пакетов IP, то в lwip для этого есть штатные средства.

В lwIp я не шибко силен - читал что есть raw-функции, которые можно использовать если не используется многозадачность. Я так понял, что либо FreeRtos без lwip - либо lwIp без многозадачности?

Неправильно поняли. Почитайте немного там. А вообще lwip плохо документирован, конечно. Информацию приходится собирать в разных местах, а также внимательно изучать имеющиеся примеры. И уж точно никто вам в форуме не даст волшебное заклинание, от которого всё сразу заработает.

основное это не кол-во строк, хотя это не плохой показатель, а в большей правильности (читай продуктивности) использования железа...
в указанном стэке, в основе лежит поллинг (например), или использование DMA по фиксированным адресам... и т.п.

это не про LwIP просто, а про LwIP на софтварных процах микроблайза. Там LwIP завернут в библиотеку, и у него 2 режима работы. Raw и Socket, первый без операционок, а второй требует операционки. Но это все про ксалинкс, плис, и их микроблайз.

Для АРМ и прочего может быть не так, если вы только ихнюю же библиотеку как то не прикрутите, или вам не попались их исходники, или в LwIP для армов изначально тоже все это есть...

При чём тут плис и арм?
lwip - вполне себе нормальная библиотека, написанная на языке Си. Работает одинаково как на армах, так и на софткорах. Процессор - он ведь и в Африке процессор.
Полистайте для разнообразия исходники lwip. Возможно, развеются какие-нибудь заблуждения.

ТС сказал "читал что есть raw-функции, которые можно..." такого рода деления я видел в реализации LwIP для плис, в смысле где режим полинга по таймерам называли Raw. И провел некую цепь размышлений, возможно она была не верной... извиняюсь...

1. Вам нужно найти место где инициализируется структура


P.S. Странный подход у Вас вам нужны вреймы а вы их пытаетесь проследить от netconn_write(), не стой стороны копаете, копайте со стороны драйвера МАС.

как бы роу - в контексте стэка, имеется ввиду сырые пакеты. т.е. юзверь стэка может формировать
сам пакеты и сказать - а теперь передатчик съешь это всё. это становится понятно, когда загляните в исходники lwip - там прямо
такие кейсы и встретите по коду
SOCK_RAW
LWIP_RAW
MEMP_RAW_PCB
PBUF_RAW
NETCONN_RAW

а как это обслуживает стэк - поллинг или прерывания или там сбоку подпрыгивает - пофигу...

Разбираюсь с исходниками lwip, настроек очень много, на какие стоит обратить внимание в первую очередь?

Не стоит путать сырые пакеты IP с фреймами изернет где могут передаваться фреймы отличные от IP протокола, а RAW сокеты работают с IP пакетами.

Устройство должно выполнять следующие задачи:
- WEB - cтраничка для оперативного управления
- FTP-сервер для удаленного обновления
- маршрутизация (пересылка некоторых фреймов в необработанном виде) в другие (не Eternet!) интерфейсы (UART, SPI...) и обратно из других интерфейсов в Eternet.

Покопался в исходниках LwIp со стороны обработчика прерываний - вышел на функции low_level_input(), low_level_output(). Думаю получится.

Пересылка голых кадров Ethernet? Зачем? Через UDP было бы удобнее.

ну да. Вам и контрольную сумму посчитают, и мак адрес проверят, зачем эту работу самому то делать? А главное чего вы выиграете, только стэк сбивать будите.

Сделайте доп порт UDP, а лучше TCP. И все что льется на него просто транслируйте в другие интерфейсы, стэк все равно крутиться...

Чтобы не зависеть от протокола - отбор кадров по МАС адресу источника.

Ни капли ясности не прибавилось. Какая такая "зависимость от протокола"? Чем это плохо? Весь мир зависит от ARP, IP, TCP и т.д. - и не тужит.

и не понятно откуда возьмутся независящие от протокола кадры? Вы уверены что все свичи, маршрутиризаторы и хабы в езернет сети пропустят какие - то голые кадры?

Даже если представить что у вас сеть состоит из нормальной ТСР, и ваших устройств где вы не хотите морочиться со стэком для обмена между устройствами, то уж UDP пакет собрать вообще ничего не стоит, контрольную сумму то к данным всяко добавлять надо, как и адрес назначения.

это пока какой нить (программно настраиваемый) свитч не порежет IP по 100 байт
вот тогда все костыли идут лесом...

Между прочим, lwip умеет как разбивать IP пакеты на кусочки, так и собирать их обратно.

апсолютно верно (если скомпилировали с опцией реассемблирования).
Вы бы хоть почитали реплику на которую я так ответил

Так поставлена задача. Неизвестно, какой протокол нужно будет маршрутизировать. К "другим" интерфейсам будет подключен некий модем (проводной, радио...) через который будут передаваться-приниматься фреймы с аналогичного устройства. Модем - не моя задача. Руководитель проекта - программист верхнего уровня - не воспринимает перечисленные Вами аргументы, хотя я с большинством замечаний полностью согласен

какой бы протокол ни был всегда можно его посылку завернуть в UDP/TCP, а в проце, взять данные и послать дальше, обратный канал аналогично. В этом случае вы не нарушаете сеть, и можете принимать-посылать данные виндусом, и прочими операционками.

Мне трудно представить хоть какое-то готовое устройство с Езернет подключением, у которого на выходе был бы свой какой-то неизвестный протокол. Это кто же такое сделает, и как оно работать то будет?

Обратите внимание вашего верховного программиста что ему не предлагают делать свой протокол, просто в качестве транспорта данных (капсулы для них) разумно использовать стандартный протокол, поддержанный стэком, с обеспечением целостности данных и прочего. Процессор получает пакет, извлекает из него данные и не думаю что там шлет их дальше. Полученные данные из вне, также не думаю заворачивает в UDP и шлет обратно. Да все так делают...