Това изглежда интересно - не е в стандартния линукс та досега ми е убягвало от полезрението:

Upstreaming multipath TCP

разгледай https://github.com/jserv/nstack

Погледнах тези user space стекове - от nstack има референции към level-ip, което бях гледал преди време. Сега се зачетох пак (за level-ip) за да видя дали не са измислили някаква хитрина за да се закачат към линукса. Доколкото виждам подменят функциите на libc чрез тяхна библиотека за да ги прихванат. Правят го чрез wrapper скрипт който пускат за всяко бинари, на което искат да се намесят (прихванат):
https://github.com/saminiir/level-ip/blob/master/Documentation/getting-started.md
Тук е сорса на wrapper-а им:
https://github.com/saminiir/level-ip/blob/master/tools/liblevelip.c
Като цяло е използваем подход, макар и не съвсем изчистен и за пред хора (клиенти), но все пак е решение. Всъщност има и друго улеснение - мога да разчитам на това че ще има само един работещ стек, по-точно адаптер. В смисъл че ако устройството ще е закачено или през нормалния си адаптер, или през микроконтролерския (но е и през двата едновременно). Така че ако няма линк на нормалния етернет мога да закачам всичко да тича през микроконтролерския. Това ще ми улесни задачата че няма да има нужда да поддържам потока и към нормалния стек - ако е активен uC порта спират другите дупки.

Тъй, аз пак съм за малко на темата и търся "опции". За в бъдеще мисля че успях да убедя мениджърите че трябва да ъпгрейднем хардуера (специфичния микроконтролер) до по-нов (който предлага L2 достъп).
Но все пак трябва да намеря временно решение със стария микроконтролер, т.е. без ethernet api.

Та, замислих се за следното - посоката с TUN интерфейса я бях отписал понеже е на друго ниво - линукса ще ми дава и искат IP пакети, т.е. като иска да праща през моя интерфейс ще ми изсипва един хедър горница (ip хедъра), а наобратно ще иска да му измисля тоя хедър и да го добавя.
Посоката с махането е по-лесната, та за начало обмислям посоката приемане:
- някой отвън праща tcp или udp на микроконтролера
- tcp/ip стека в микроконтролера си свършва работата и ми праща пакет по неговото си api за приети udp или tcp данни; в тоя пакет са самите данни и малко метаданни да си позная по кой сокет е това (хендъл от отварянето/конект или подобно)
- в моя код трябва на база получения пакет и таблица на връзките/сокетите да свърша моята работа и да изфабрикувам IP пакет, който да навра в на TUN-а дупката
- оттам насетне кърнела/стека трябва да го заведат до приложението на тоя порт примерно

Като начало мисля само за TCP, и само за връзки инициирани отвън (от pc в мрежата на микроконтролера), като сървърите са процеси в линукса (proftpd, sshd, и подобни).

Чудя се:
- на това ниво (IP - TUN) май няма причина да ме известяват че е отворен нов listening socket по моя интерфейс, така че няма да получа информация че портове 21 и 22 са отворени и чакат конекции? Това ми трябва за да конфигурирам микроконтролера също да чака, но ако го няма на tun ниво ще ползвам някой от заобиколните начини
- трябва отнякъде да получа/взема достатъчно информация за да добавят коректен IP хедър на получените пакети - единия източник е самата нотификация от микроконтролера, но там пише портовете и адресите; дали ще ми трябва и още нещо?

Като гледам ip хедър структурата не виждам нещо, което да не мога да извадя или измисля (като TTL-а). Фрагментацията интересно дали ще ми е нужна?

btw: по TAP върви целия пакет
Не ти ли върши рабта

Трябва да помисля - в едната посока е добре че ще получавам повече информация, ама в другата ще имам да пълня повече...
Това би значело да отговарям на много пакети - на целия флоу на тцп примерно.

с TAP-SLIP си играх ( щото Windows не подържа TUN ) и иска "рутиране"
https://github.com/Wiz-IO/azure-sphere- ... st.py#L313

ама ти си усложняваш живота
до колкото те разбрах: имаш една "черна кутия" в която има TCP/IP стек и сервизи(сървъри) за външна връзка, вързана на SPI, с user-api достъп
демек имаш два процеса:
1. някой "отвън" прави конекция и ти мятка съобщения
2. някой отвътре(Linux) прави сокет към "кутията"
и тези два процеса искаш да минат като интерфейс на линукса

ако съм разбрал правилно
ти трябва процес/драйвер дето ще мандахерца SPI и ще разпределя посока master/slave
master: Linux ще прави сокети към контролера (директно, TUN, TAP, SLIP, PPP, някакси)
slave: ще доставя някакси/някъде "events" какво се случва(тук май няма мрежа или зависи как ще се реагира на event)

Май ни с тун, ни с тап е работа - и в двата случая ще получавам целия трафик - примерно за TCP ще са всички пакети по отваряне (SYN, SYN-ACK, ACK), затваряне и по самия трансфер. Няма как да им отговарям подобаващо, освен да имам цял tcp/ip стек насреща. В старото решение е така - закача се локален клиент към ftp сървъра примерно и по неговия сокет се получават чистите TCP или UDP данни, които да се препращат към стека в микроконтролера. Установяването на връзката, ретрансмити и потвърждения се случват между два сокета на линукския TCP/IP стек - единия е слушащия е FTP сървър демона, другия е този клиентския в специфичния прокси софтуер.