Според мен няма читав начин със мониторинг АПИ-тата да подмениш комуникация по сокет. Това което съм ти изкарал по горе като интерфейс е мястото където можеш да реализираш отваряне на сокет с ип адрес и така да подмениш целият линукски стек отдолу с този на микроконтролера. Само, че не е тривиално и ще отнеме време. Бързо решение на това ниво няма - всички други са на по ниските нива където най вероятно нямаш подходящо АПИ (пращане на етернет пакети, датаграми и т.н.) с което да успееш да се оправиш. Евентуално може да има нещо в разните виртуализации - примерно UML (user mode linux) има драйвери които правят точно това което ти трябва като си говорят директно с хост операционната система - но и там като гледах виртуализацията е на по ниско ниво най вероятно за да може линукса да рутира трафика. То това с рутирането ще ти е проблем и на теб - не съм много сигурен дали линукс поддържа да имаш няколко реализации на PF_INET и ако е така ще трябва да подмениш неговият и да анализираш всяка заявка за отваряне на сокет дали да я пращаш към микроконтролера или да я пратиш на към оригиналната линукска ИП4 имплементация която да ползва вградените мрежови адаптери. И как ще ги различаваш си е отделен проблем сам по себе си. Вграденото линукса рутиране май е на по долните нива в самият ТЦП/ИП стек а не на ниво сокети където ти искаш да се закачиш. Въобще ... замисли се добре дали да се занимаваш с това - не е невъзможно, но си е сериозна и доста отговорна работа пряко свързана с високите дневни надници дето ги коментираме в другите теми.

Благодаря, това е възможна посока - линка изглежда доста точно по темата, ще пусна примерите му и ще видя какво получавам като пакети - доколкото видях при tun ще получа ip пакетите и ще има нужда от парсиране - в смисъл че не е нивото connect, accept, send, receive. Ако е достатъчно чиста информацията ще свърши работа. Ако не ще ровя другаде.

@palavrov - аз не искам да я променям - ако знам че някой е отворил listening сокет ще "създам" комуникацията - ще се конектна от моето бридж приложение и това ще е всичко, което линукса ще види. Ще използвам станартните сокет операции към отворената връзка. Пак остава това че ми трябва информация кога е създаден сокета. tun-а евентуално може да го ползвам само за да разбера точно това създаване на сокети - за да не правя периодични netstat -l

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

tun/tap пак е на много по ниско ниво от сокетите и ще е цял подвиг да го иземулираш със сокети през този микроконтролер.

Мда, не мисля че през tun ще разбера кога някой е отворил listening сокет. Отделно пакетите трябва да се парсират наобратно, т.е. да възстановя още по-горното ниво, дето го гледахме в tcp_ipv4 и proto структурата.
В момента съм на fallback решението - парсирам изхода на нетстат и изглежда прилично, поне има достатъчно информация. Мен не ми трябва много бърза реакция - секунда-две закъснение никак не ми пречи - виж при евентуално затваряне може и да има повече странни ефекти
Има си режим за периодично принтване на статистиката: "-c", сега гледам дали някой е мислил по подобие на tail да хваща промените между изхода от текущото и предходното извикване - иначе сигурно ще трябва да го пиша във файл, ама после трябва да го правя "_old" и т.н. - все неща дето май няма да стана с просто pipe-ване на командния ред.

Този fallback който мислиш също хич не ми харесва - айде да разбереш, че има нов отворен слушащ сокет е лесно. 1с латентност никак не е малко, но да кажем, че погледнеш сорсовете на туула с който ще мониторваш и намериш начин да го ускориш. Повече ме притеснява как ще успееш да препратиш данните по този сокет в двете посоки и всичко да си работи. Ако имаш някаква конкретна идея ще погледа да видя дали няма да има ядове, но аз не се сещам за някакъв лесен начин да стане - то и за труден не се сещам ама то щото акъла ми е в един AVR и ...

Сорсовете на netstat очаквано показват че там не се случва нищо значимо - просто се чете и парсира с един sscanf от sysfs - по-точно се чете от /proc/net/tcp и /proc/net/udp. Данните там се конвертират до читаема форма и се принтват. Т.е. при мен няма да пускам нетстат а ще си чета от sysfs същото. Даже е удобно че ще получа в отделни списъци tcp и udp че ще ги ползвам с различни апи-та после.
Идеята е максимално баламска:
- чета отворените сокети и да кажем виждам че има един 0.0.0.0:21 - щото току-що е тръгнал ftp сървъра в линукса
- викам 1-2 функции на специфичното апи които изискват от стека в микроконтролера да отвори listening сокет на порт 21 през неговата си RJ45 дупка
... минава време и някой отвън иска да се закачи към микроконтролерския порт 21...
- специфичното апи ми казва има дошъл коннект на 21, шъл ли ги аксептваме
- създавам клиентски сокет в линукса към localhost:21 и ако успея отговарям на микроконтролера - я, я, ша го аксептваме
- микроконтролера казва "дойдоха 84 байта по тоя сокет" и аз стрелям 84 байта по сокета към 127.0.0.1:21
- линукса ми казва "има 96 байта от 127.0.0.1:21" сокета и аз казвам на микроконтролера "има 96 байта за предаване през твоята rj45 към твоя клиент"
- след малко линукса казва "някой отвори нов listening socket" на по порт 1234 (фтп сървъра отваря сокета за дата връзката по горната сесия)
- по описания сценарии прехвърлям това към uC да отвори и то слушащ сокет оттатък
- фтп клиента опитва да се конектне към 1234 на uC дупка и ако съм бил достатъчно бърз (полинга на /proc/net/tcp) ще успее
Целта е да имам процедура която е изчистена и повтаряема за всеки открит нов порт, който все още не съм "бридж"-нал - понеже /proc/net/tcp , udp не ми дават събитията трябва да си следя кои са нови, кои са вече обработени, кои са изчезнали от линукса а още отворени в uC.
Това е за listening сокети в линукса - за момента това е основното, което се иска. Но ще трябва да мисля и за обратната посока - там вече става сложно и евентуално tun щеше да е по-добре, или друг вид наименован адаптер, за който линукса да знае. Самият uC си има собствен ip адрес и ако се направи виртуален интерфейс в линукса лесно може да се рутира. Ама сега не знам...
За момента може би ще е фиксиран списък на разрешените портове и ще правя обратния процес още на стартъп - ще отварям listening сокети на тия портове в моя бридж (за всеки порт от твърдия списък) на локалхост. Ама това е безсмислено, аз ако отворя 21 то вътрешните приложения ще трябва да стрелят към localhost:21 - ма то там е локалното ми ftp... Т.е. това е нонсенс.

Така може и да сработи за по пристички комуникации но ме притеснява, че този bridge който правиш ще скрие реалните IP адреси и винаги от едната страна на сокетите ще е 127.0.0.1 ... ако си късметлия може да не се отрази на нищо и да работи де. Но ще е много скопена системата така - не може да се направи никаква връзка навън към интернет по този начин.

Да, така е - не изключвам посоката да ровя дали ще мога да се закача на високото. Трябва си ми възможност да се обявя като интерфейс на L4 - ама докато не открия някой да го е постигнал си мисля че ще е непосилно за мен и не искам да съм пионерче...
За да имам нормална имплементация ще трябва да започна от това да сложа реалния адрес на uC някъде - т.е. да науча линукса че има такъв интерфейс. Това досега видяхме че може да стане с tun, но там сме едно ниво по-ниско от желаното. По-горното се получава със собствен протокол, ама вече има хендлър за IPv4. Принципно не виждам как ще стане да има втори на това ниво, очаква се по един модул за всеки тип. Аз нов тип не мога да ползвам понеже приложенията (ftp, ssh) вика създаването на сокети с AF_INET и т.н. По тази верига явно трябва да се закача в тоя флоу от викания и данни, т.е. да подменя или hook-на някъде там (в tcp_ipv4.c) - по-високо не мога, по-ниско не ми върши работа (а-ла tun). Но това си е сериозно предизвикателство.
Като показателен use case мога си дефинирам следното - трябва да може ftp/ssh или друг сървър да може да сработи да слуша дори САМО на дупката на uC - досега обмислям заобиколки понеже тези сървъри слушат на всички интерфейси. Ама истинското решение би трябвало да позволи сървърът да може да бъде пуснат с конкретния адрес на uC и пак да сработи. Както и клиентски приложения да могат да достъпват различни адреси (сървъри) в локалната мрежа зад uC дупка.

Ами в по напред го написах как според мен може да се реализира не да имаш втори протокол а да подмениш оригиналният с твой и в него да рутираш отварянето на сокети по някакъв критерий към вграденият стек или към този на микроконтролера.

Според мен проблемът нешо сте тръгнали накриво в дизайна на системата - тежи мрежови проблеми отдавна са решени достатъчно добре и е по евтино да решиш проблема по някакъв друг начин. Доста показателно е, че на никой не му се е налагало досега да прави нещо подобно т.е. явно не се прави така и по добре да не вървиш в тази посока.

Ей тука една статия за особенностите на сокети и таймаути която ми мина през погледа днес - хубаво е да имаш в предвид какви проблеми те чакат и с тях ако решиш да се бориш със сокете ...

https://idea.popcount.org/2019-09-20-wh ... se-to-die/

Ако може да нарисуваш някаква схема на нещото, което трябва да стане. Имам някакво чувството, че искаш за запушиш кръгла дупка с квадратен чеп...
Дотук разбрах: имаш custom устройство, което си говори през spi с linux машина. Искаш да имаш възможност да отвориш през стандартните функции на Linux-а(open, read и т.н.) IP стека на устройството и да си говориш с него. Това ли търсиш?

Няма как да си IP интерфейс директно на L4, защото адресът ти е на Layer3, на L4 са ти вече TCP/UDP вързки, но те трябва да все свързани с някой интерфейс.

От моето разбиране до тук това допълнително устройство е реално Етернет адаптер, който искаш да ползваш в Линукс системата, закачен на някаква шина, примерно SPI. Проблемът е, че API-то ти до този адаптер е към собвстен TCP/IP стек вървящ върху него, тоест нямаш достъп до Layer 2 (Ethernet) да изпращаш и приемаш фреймове.

Не знам как се задава мрежовата конфигурация на това устройство, но предполагам, че можеш поне да я четеш през достъпното API от Линукса. В такъв случай вдигаш един tun интерфейс (директно на Layer 3) и му слагаш IP адресът, който си взел от твоето къстъм устройство. Линукс истемата вече знае, че този адрес си е нейн и съответно трафикът от/към него отива в твоя userspace процес, бридж демон да го наречем. Той от своя страна вика АПИ-тата на странният мрежови адаптер.

Не виждам защо да не работи тази схема. Точно по този начин работи OpenVPN да речеме, вдига един tun интерфейс (приемаме, че е настроена за Layer 3) и трафика от/към него отива в openvpn демона. Той на свой ред го препраща във някакъв тунел. Вместо в тоя тунел ти ще го препращаш от/към API-то с което имаш достъп до стека на странния мрежови адаптер. Какъв е проблемът с този подход? Единствено ще трябва да синхронизираш IP мрежовите настройки на tun инерфейса и IP стека вътре в адаптера.

Радо, проблемът е, че API-то което има този микроконтролер е на ниво сокети т.е. L5 ...

Мда, прави си. Ще трябва да 'синхронизира' връзките в двата TCP/IP стека. По-скоро тогава демона трябва да е proxy, което слуша на външния интерфейс и прехвърля връзките към Линукса. До колкото разбрах само в посока отвън навътре ще се инициират.

Нещо такова, ама не само - наистина повечето мислене и обсъждане е за връзки отвън, т.е. към вътрешни сървъри. Но търся да покрия и останалата част, т.е. връзки отвътре към външни сървъри зад uC интерфейс.
Проблемът се крие в историята за тези устройства и използваните компоненти - този uC да го наречем е доста специфичен и да кажем уникален в областта си. Реално производителят му покрива такъв use case по много смислен начин - като дава L2 API, че и готов модул за линукс с който да се вижда като физически интерфейс. Само че и те си развиват нещата и конкретно тази опция (L2 интерфейса) го има за следващата серия uC на тази фирма. За по-стария който ние още ползваме не искат да го поддържат като казват че не му стигат ресурсите - дали е така или просто не искат да инвестират в по-стар продукт си е тяхна работа. Отдавна напъвам да сменим с по-нов чип, който даже е пин компатибъл, но и това иска ресурс за да се случи и шефовете не виждат смисъл. Има едно баламско решение, което работи в по-слънчево време, но си има заложени принципни проблеми, които един по един ги хващат клиентите. Чистенето им в толкова оплетен код отнема седмици и е загубена кауза. Затова и търся нещо по-стандартно и изпитано - ако ще тръгвам по трънлив път по-добре да кърпим старото и да се надяваме да мине. Ако изчистя концепция, което принципно избягва глупостите си струва да се боря да я имплементираме и да замести старото.

По инициирането - да, отвън тръгват, но моя код се намира зад техния tcp/ip стек - ако някой отвън поиска връзка техния стек ще го отсвири без да разбера, ако преди това не съм го инструктирал да слуша на тоя сокет. Текущото решение има твърд списък на портовете, които някой някога може да поиска - този списък е дълъг и е суперсет на всички възможни конфигурации и приложения на тези устройства - никога не се ползват всичките в едно и също устройство. Отделно реалното тръгване на сървърите и сокетите (фтп, ssh, ...) не е синхронизирано. По-лошото е че при спиране или затваряне също стават разминавания. Третият проблем е около фтп-то - на 21 порт са командите, но после сървъра и клиенти си обменят на кой друг порт да прехвърлят данни - това няма как да е в твърдия списъл и се сега се инспектира трафика по порт 21 за да се подслуша на кой порт ще си говорят.
Цялата логика е описана в стейт машини, които много са имплементирани по начин, който никак не харесва неочаквани събития да му се месят някъде - това си е проблем на колегата, който го е писал, но като цяло промяната им към нормален активен обект ще е повече писане от пълна преработка - стига да има изчистена идея, която решава поне проблемите и use case-овете, които старото решение обслужва някак си в слъчнево време.

Едит: и още нещо - тези сървиси в устройството не са за ползване от потребителите, а се достъпват от наши PC инструменти. Т.е. нашите инструменти имат ftp клиент, ssh клиент и т.н. Отдавна натискам тия простотии да спрат, ама само админите ме разбират - като чуят ftp и се изприщват, напълно разбрано. Още преди да направим тия хакове предлагах да хванем и помислим за по-смислен протокол, през който да вършим нещата, който да ползва по-ясна концепция, ако ще и облачно - примерно mqtt и брокер някъде в pc, или поне всичко да минава през ssh/scp. Това можехме да го закачим към специфичното апи, понеже няма да се ползва proftpd и т.н. Само че пишещите инструментите се дърпат, макар че и те хвърлят сума ти време да се борят с подобни проблеми.

Ако имаш бюджет (време+пари) най смислено ми се струва трънливият път с подмяната на протокола на 5-то ниво. Ако ли не по добре направо ескалирай проблема нагоре по йерархията да се мисли някакво мениджърско решение т.е. една хубава калкулация колко ще струва трудният начин сега сравнен с колко ще струва ъпгрейд към новата версия на този контролер в който вече имаш API за L2 + готов драйвер за линукс.