# IP-Datenverkehr auf verschiedene LAN-Interfaces mappen



## fadade (24. Januar 2017)

Guten Abend,

da ich keinen Doppelpost machen wollte mir aber vorstellen kann, dass Linux-Netzwerkeinstellungen auch eine Lösungsmöglichkeit darstellen könnten, wollte ich auch in diesem Forenteil einmal an folgendes Anliegen von mir verweisen: http://extreme.pcgameshardware.de/i...und-softwareseitig-verbinden.html#post8658959


Kurzdarstellung:
Nach Möglichkeit möchte ich 4 benachbarte und über LAN verbundene Raspberry Pis von einem Raspberry ohne zentrale IP-Verwaltung o.ä. über TCP mit C++ und Java-Anwendungen ansprechen können. Neben einer physischen Verkabelung und Einrichtung lässt sich das vielleicht auch über eine OS-Konfiguration in Linux bewerkstelligen ?!


----------



## cann0nf0dder (26. Januar 2017)

steh da grade ein wenig aufm schlauch oder so und seh denn sinn nicht wirklich oder versteh was komplett falsch ... aber warum dann keine feste ip in den jeweiligen pi's eintragen, das wäre dezentral .... ansonsten ka


----------



## forenshit (26. Januar 2017)

Du kannst einem Port ein Transport Protokol im xinetd festzuschreiben. Und noch andere Sachen. Ich glaube das ist es, was du meinst und suchst. Übrigens eine nette Sache, was du da baust.


----------



## forenshit (26. Januar 2017)

netcat?


----------



## fadade (27. Januar 2017)

Hi,

danke für die Anregungen. Werde mir gleich mal netcat & Co. bzgl. ihrer Funktionen und Eignung anschauen - im anderen Thread habe ich auch noch ein weiteres Bild eingefügt. Vielleicht hilft das die Tools etc. noch weiter einzugrenzen. Vielen Dank dennoch schonmal


----------



## forenshit (27. Januar 2017)

Du kannst einem physikalischem RJ45 Anschluss mehrere IPs zuweisen unter Linux. Es ist auch relativ einfach und zuverlässig. 
Darf es, wirklich und unbedingt,  nicht mit einem Switch/Hub laufen?
Der ankommende Paket muss also unbedingt die IP 192.168.1.1 als Quell-IP tragen?


----------



## fadade (29. Januar 2017)

Nabend,

es freut mich, dass jemand doch so interessiert ist 
Also netcat und (x)inetd scheinen in Kombination schon vieles bewältigen zu können. Aber irgendwie lande ich mit meinen Überlegungen immer wieder bei dem Problem eines IP-Adresskonfliktes zwischen jeweils zwei Raspberrys ...

Das Gesamtsystem darf auch Switches/Hubs beinhalten, aber eine zentrale DHCP-Verwaltung o.ä. ist eigentlich nicht erwünscht. Wobei ich das in den letzten Tagen auch an Attraktivität gewonnen hat - zumal das bei einem globalen Netz kaum Zusatzaufwand wäre. Das Problem ist, ich muss in den Softwarekomponenten immer die physischen Nachbarn identifizieren können. Wenn nun die Maschinen A, B, C und D mit den IPs 192.168.1.1/.2/.3/.4 ausgestattet sind und alle an einem Switch hängen, ist vollkommen unklar, wer welche Nachbarn hat.
Deswegen finde ich eine Lösung über mehrere Ethernet-Ports aktuell zielführender: Die Raspberrys werden mit 4 USB-to-Ethernet-Adaptern ausgestattet, jedes dieser USB-LAN-Interfaces bekommt eine feste IP (z.B. 192.168.178.1/.2/.3/.4) und wird immer verbindet immer einen entsprechend linken/rechten/vorderen/hinteren Nachbarn mit dem aktuellen Modul. Wenn ein Raspberry nun an 192.168.178.1 sendet, würde er bspw. den linken Nachbarn erreichen. Problem: Wenn das LAN-Kabel dort auch am Interface mit 192.168.178.1 hängt 

Mögliche Lösung:

Eigene IP-Aushandlung über UDP auf jedem Interface ausführen, bevor die Software startet 
Immer die gleiche IP und mit netcat/inetd irgendwie ein Mapping definieren, was bei diesen Punkt-zu-Punkt-Verbindungen funktioniert 
Über den nativen Ethernet-Port am Raspberry eine zentrale IP-Vergabe über DHCP und dann entweder mit den USB-LAN-Adaptern arbeiten (in der Hoffnung, dass mir noch etwas einfällt) oder einfach jedes Modul mit einem 5-Port-Switch ausstatten (1 zum Raspberry und 4 zu den Nachbarn) 

Wenn der Chef hinter Letzteres kommt, wird es wahrscheinlich etwas lauter ... deswegen würde ich eine der ersten Lösungen präferieren. Ist das realistisch damit die lokalen Punkt-zu-Punkt-Verbindungen zu verwalten oder gibt es möglicherweise noch andere Einfälle? Forschung und Fortschritt leben ja auch von Beiträgen einer heterogenen Ideenschmiede 

Schöne Grüße,
FADADE


@forenshit: Ich weiß noch nicht, wie das rechtlich aussieht, aber ggf. kann ich dich in den nächsten Monaten mal etwas genauer über das Projekt informieren, wenn du Interesse hast


----------



## forenshit (31. Januar 2017)

Hallo fadade,

ich bin schon seit einiger Zeit nicht mehr so unterhalten, wie jetzt bei deinem Problem. Und zwar, wie kann man mit IP-Adressen seine Position im Netz bestimmen? Immerhin wurde dieses Protokoll genau für das Gegenteil entwickelt.
Die Sachen, die du Beschrieben hast, sind relativ einfach zu lösen, nur das ein Raspi jetzt selbstständig entdeckt, wer sein Vor- und Nachgänger ist, war hier schwierig.
Das hat mich jetzt drei Tage gekostet (und ein völlig Off-Topic Kommentar), aber ich weiss jetzt, wie du deine Aufgabe lösen kannst und zwar genau, wie du sie beschrieben hast, dezentral, ohne Hilfsgeräte, auf der OS-Ebene und in Daisychain. Jetzt muss ich aber allmählig ins Bett, ich habe Morgen ein Meeting. Und wir wollen ja die Spannung aufbauen.

Ich würde schon gerne mehr über dein Projekt erfahren. 

Gruß


----------



## fadade (31. Januar 2017)

Morgäähn,



forenshit schrieb:


> ich bin schon seit einiger Zeit nicht mehr so unterhalten, wie jetzt bei deinem Problem.


Hmm, das war zwar nicht meine Absicht, aber freut micht, dass ich für Unterhaltung gesorgt habe 




forenshit schrieb:


> Und zwar, wie kann man mit IP-Adressen seine Position im Netz bestimmen? Immerhin wurde dieses Protokoll genau für das Gegenteil entwickelt.


Irgendwie kam mir der Gedanke am Anfang auch. Allerdings hatte ich auch das Gefühl, dass es möglich ist - deswegen das Hilfegesuch hier im Forum.




forenshit schrieb:


> Die Sachen, die du Beschrieben hast, sind relativ einfach zu lösen, nur das ein Raspi jetzt selbstständig entdeckt, wer sein Vor- und Nachgänger ist, war hier schwierig.
> Das hat mich jetzt drei Tage gekostet (und ein völlig Off-Topic Kommentar), aber ich weiss jetzt, wie du deine Aufgabe lösen kannst und zwar genau, wie du sie beschrieben hast, dezentral, ohne Hilfsgeräte, auf der OS-Ebene und in Daisychain. Jetzt muss ich aber allmählig ins Bett, ich habe Morgen ein Meeting. Und wir wollen ja die Spannung aufbauen.


Das klingt zunächst so, als hättest du eine Lösung gefunden und freust dich darauf, wie ich heute unabdingbar und voller Anspannung alle 10 Minuten ins Forum schaue, ob hier weitere Ausführungen gepostet wurden .... FRECH!!! 
Aber sollte es tatsächlich so sein, wäre das ein erstes Highlight des Jahres. Ich freue mich schon auf Weiteres (und baue nebenbei Spannung auf!)




forenshit schrieb:


> Ich würde schon gerne mehr über dein Projekt erfahren.


Dann verweise ich an dieser Stelle zunächst einmal auf öffentlich verfügbare Informationen, wie https://www.iph-hannover.de/_media/files/downloads/IPH_Flyer_netkoPs.pdf

Gruß,
fadade


*
Update:*
Im oben verlinkten Start-Thread ist nochmal ein längerer Post von mir hinzugekommen: Netzwerktopologie und -konfiguration für Forschungsprojekt - Raspberry Pi technisch und softwareseitig verbinden


----------



## forenshit (2. Februar 2017)

Hallo,

tut mir leid, dass ich mich so spät melde, aber mir kam ständig irgendwas dazwischen. Ich lese alles, was du mir gegeben hast später, verzeih, ich finde aber, dass es besser ist dich nicht mehr zu foltern. Soll also etwas obsolet sein, was ich dir weiter schreiben werde, bitte um Verständniss.

Im Endeffekt ist diese Links-Rechtserkennung zimlich einfach. Aber von Anfang an. Verbinde die Raspis in die Kette mit RJ45(LAN) und einem USB to RJ45 Adapter (USB) und zwar vollgendermassen: immer von USB auf LAN. Somit ist LAN - links und USB - rechts. Die IPs werden statisch vergeben, irgenwelche in deinem Netzwerkbereich (Netzwerk) z.B. A hat dann LAN 192.168.0.1 (...1) und USB 192.168.0.2 (...2) und B LAN ...3, USB ...4. Die Interfaces werden verbunden z.B. IP-Forwarding, Brücke oder sonstwas. In Firewall blockerst du ein Port z.B. 2000. Jetzt lässt du dein Netzwerk mappen (nmap) auf dem Port, dass du blockierst z.B. auf LAN. Da die Weiterleitung der Anfragen blockert ist, bekommst du nur eine IP und zwar, die von deinem direkten Nachbar links. Erledigt. Das gleiche kannst du auch rechts machen, natürlich. Ab jetzt kennt dein Raspi seine Nachbarn links und recht und kann sich automatisch anpassen. Ab jetzt setzt beinahe nur deine Vorstellungskraft und sein Sollbuch, was du damit machst. Deine Raspis können jetzt ihre IPs automatisch verändern, ihre Nachbarn zu Veränderung ihrer IPs bewegen und was du nur willst. All das kannst du mit OS-Werkzeugen erreichen und etwas Skript-Programmierung (oder mit der Sprache, die du bevorzugst). Es wird ab hier sozusagen langweilig. Du kannst sogar eine kleine DB aufbauen, die jeweilige IPs festhält. Wenn sich ein Raspi bewegt hat, ergo seine IPs verändern sich, aktualisiert er die DB und per Multicast und TCP gibt er die Datei weiter. Du kannst eine Sicherheit auf Basis von HASH oder einfach einer Versionnummer in der DB selbst, einbauen. Wenn du willst. Wie gesagt, nachdem sie sich und ihre Nachbarn erkennen können, gibt es hier kaum noch Grenzen dessen, was du damit machen kannst. Wenn du unbedingt immer feste IPs für deine Anwendung brauchst, baust du zwischen App und Interface ein static NAT. Sonst kommt keine unaufgefordete Verbindung zustande, solltest du dynamic NAT benutzen, beachte das. 
So, ich glaube ich konnte dir die Vorstellung davon vermitteln, wie dein Problem zu lösen wäre. Allerdings muss ich auch schreiben, dass ich so etwas noch nie versucht habe (IP in DaisyChain), daher sind das meine theoretische Überlegung und könntest es auch sein, dass es nicht funktioniert. Mein Kung-Fu würde darunter leiden, aber ich kann meine Idee aus praktischer Erfahrung nicht bestätigen/untermauern. Einzelheit können wir später noch besprechen. Alle nötige Werkzeuge sind schon in Unix integriert oder bekommst du einfach installiert. Du kannst sie natürlich selbst auswählen, das alles oben sind nur Vorschläge, vielleicht kennst du welche, die besser passen würden. Genau wie IPs usw. Ich weiss es nicht, wie deine App mit der Aussenwelt kommuniziert, daher macht es keinen Sinn hier noch weiter zu vermuten. Es könnte sein das sie eine BlackBox ist und du keinen Zugriff auf das Quellcode hast. OK, sollte es laufen, kommt auf dich ziemlich viel Frickelei, wenn du alle Möglichkeiten decken willst, die mit der Veräderung im Netz eines Raspis entstehen werden, aber sonst wüsste ich wirklich nicht, wie du deine Aufgabe meistern sollst, ohne sündhaft teure Geräte. Ich glaube, das wäre alles für Jetzt.


----------



## fadade (6. Februar 2017)

Hi,

so habe das nun einmal gedanklich durchgespielt und schaut soweit gut aus. Ist natürlich noch nicht bis ins kleinste Detail nachvollzogen, aber ausprobieren steht sowieso noch an - danke trotzdem schon für die Anregungen 
Der Chef wird dann die Tage entscheiden, wie es die nächsten Wochen weitergeht und ob er nicht doch lieber eine super-teuere-Infrastruktur bevorzugt  ... (wer hat, der kann )

Die DB könnte sich tatsächlich als sehr nützlich erweisen - zwar gibt es eine ähnliche Funktions-Schnittstelle mit einem anderen Mitarbeiter schon, aber dort sind soweit ich weiß keine dynamischen Änderungen vorgesehen.
Ich melde mich dann in den nächsten Wochen mal wieder mit dem Fortschritt.

Grüße,
fadade


----------



## takan (7. Februar 2017)

sowie ich das netzwerk verstanden hab, brauchst du immer noch einen router der die pakete verwaltet. wenn du nur reine switches hast brauchst du immer noch ein router(software).


----------



## Nmap (8. Februar 2017)

fadade schrieb:


> Kurzdarstellung:
> Nach Möglichkeit möchte ich 4 benachbarte und über LAN verbundene Raspberry Pis von einem Raspberry ohne zentrale IP-Verwaltung o.ä. über TCP mit C++ und Java-Anwendungen ansprechen können.



Antwort: Feste IP Vergabe und Eindeutige Namenszuweisung.

Einfach nur logisch, verstehe Dein Prob nicht.


----------



## Nmap (8. Februar 2017)

Ist man im "selben Netzwerk Segment", kann eine / odere mehrere spezielle IP Zuweisung / en Sinn ergeben ! (In Deinem Fall ist es ja Erwünscht - daher feste Zuweisung /en.)

Berechtigungen, wer letzendlich Schreibend / Lesend usw. auf Ordner & Dateien Zugreifen darf usw. - kann man dann auch noch einmal gezielt Festlegen !


----------

