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

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

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

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

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

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

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

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

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

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

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

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

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