mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Embedded NAT Device / Lösung gesucht


Autor: Tony S. (tooony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo in die Runde,

Bevor ich mein Problem beschreibe, möchte ich meinen aktuellen Aufbau 
skizzieren:

Ein 5-Port Ethernet Switch auf Basis des IC KSZ8895 verbindet ein µC 
Board mittels dem xPico von Lantronix, ein RPi Compute Modul (mit 
Touch-Display) mit dem LAN9514 IC, sowie ein weiteres ethernetfähiges 
Gerät miteinander. Ein weiterer Port des KSZ8895 steht für ein externes 
Netzwerk bereit. Das Compute Modul mit dem Display ist optional 
(abnehmbar, verbunden via PoE, ein Port vom KSZ8895 hat einen PoE 
Injektor) und dient der Steuerung und Visualisierung. Die Visualisierung 
wird hierbei durch eine Weboberfläche realisiert, sodass man auch den µC 
von einem anderen PC im Netzwerk aus einfach via der Webseite steuern 
kann.

Nun ist es so, dass das Ganze zu einem Gerät verschmelzen soll, mit der 
Anforderung, dass das Gerät insgesamt nach außen hin nur eine IP-Adresse 
besitzen soll.

Meiner Meinung nach benötige ich jetzt hier eine NAT (NAT-PMP) Lösung, 
die das externe Netzwerk mit meinem kleinen "internen" Netzwerk 
zusammenführt. Die Applikationen bzw. Datenschnittstellen aller eingangs 
erläuterten Komponenten arbeiten auf jeweils anderen Ports, sodass 
NAT-PMP hier ein richtiger Ansatz sein sollte?

Die Frage ist nun aber weiterhin, wie bringe ich ein Peripherie hinein, 
die NAT unterstützt bzw. welche Gerätschaft kommt hier in Frage? Die 
Lösung sollte in Richtung embedded gehen und idealerweise Platz auf der 
aktuellen µC Platine finden.

Ich hatte die Hoffnung, nach dem Vorbild des xPicos ein Modul zu finden. 
Dem ist jedoch nicht so. Hat hier jemand vielleicht einen Tipp? Das 
Ganze sollte industrietauglich sein.

Zum anderen war meine Überlegung, das bereits verwendete Compute Module 
umzusetzen und als NAT Gateway zwischen externen Ethernet-Port und dem 
KSZ8895 einzusetzen. Das Dispaly soll natürlich optional und abnehmbar 
bleiben, daher stellt sich mir die Frage, ob man die Datenleitungen des 
DSI Ports über Kabel laufen lassen kann (Kabelänge ca. 1,5 Meter), 
sodass es natürlich noch funktioniert.

Soweit erstmal.

Ich freue mich über Ratschläge oder alternative Ansätze :)

Autor: Frank K. (fchk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mach VLANs nach 802.1q auf. Dein Switch kann das.

Dein Microcontroller und das externe Gerät kommen in VLAN 1, untagged
Der externe Port kommt in VLAN 2, untagged
Das Compute Module kommt in VLAN 1 und 2, und diese Switch Port muss 
tagged Pakete (also mit 802.1p/q Tag) senden und empfangen. Das Compute 
Modul natürlich auch. Das spielt dann Router bzw Proxy.

Damit ist der zusätzliche Hardwareaufwand gleich 0.

DSI müsste begrenzt verlängerbar sein, wenn Du geeignete Kabel und 
Stecker verwendest. Das ist übelste Hochfrequenztechnik.

Probiere mal DisplayPort Kabel aus, ansonsten SAS-Kabel. Das müsste 
zumindest von der Bandbreite her einigermaßen passen.

fchk

Autor: Tony S. (tooony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Mach VLANs nach 802.1q auf. Dein Switch kann das.
>
> Dein Microcontroller und das externe Gerät kommen in VLAN 1, untagged
> Der externe Port kommt in VLAN 2, untagged
> Das Compute Module kommt in VLAN 1 und 2, und diese Switch Port muss
> tagged Pakete (also mit 802.1p/q Tag) senden und empfangen. Das Compute
> Modul natürlich auch. Das spielt dann Router bzw Proxy

Hallo Frank,

vielen Dank für dein Feedback! Ich möchte zunächst noch hinzufügen, dass 
der µC mit xPico ebenfalls aus den externen Netzwerk gesteuert werden 
soll. Sprich, aus dem externen Netzwerk und gleichermaßen das CM reden 
mit einem eigenen Protokoll mit dem xPico und damit mit dem µC.

Die Geschichte mit den VLANs hatte ich auch schon mehrmals mir durch den 
Kopf gehen lassen, jedoch fehlt mir hier das Fachwissen wie das Ganze 
genau funktioniert. Konkret meine ich damit, wie ich mit einer 
IP-Adresse von extern die unterschiedlichen Geräte via VLANs jeweils 
erreiche.

Meine Vorstellung sieht so aus:

- xPico hat IP A
- RPi CM hat IP B
- Gerät X hat IP C

-> "universelle" xPico IP durch die alle Komponenten von extern 
angesprochen werden können
-> Anfrage an IP A Port 80 weiter zu CM
-> Anfrage an IP A Port xx weiter zu xPico / seriell zum µC
-> Anfrage an IP A Port yy weiter zu Gerät X

Ich werde mich mal in die VLAN-geschichte tiefer einarbeiten. hast du 
hier ein Link zu einem Beispiel?

EDIT: Das Ganze funktioniert auch dann, wenn das CM nicht am Switch 
angeschlossen ist.

: Bearbeitet durch User
Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VLAN ist sicherlich der eleganteste Weg.
Dabei hat dein RaspberryPi so viele logische Ethernet-Schnittstellen, 
wie du VLANs konfiguriert hat.
Auf dem RPi ein NAT zwischen 2 Schnittstellen zu schalten ist die 
leichteste Übung.

Entspricht eigentlich genau dem im Eingangspost geforderten Scenario, 
nur eben ohne zusätzliche Hardware.

Autor: Tony S. (tooony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Mach VLANs nach 802.1q auf. Dein Switch kann das.
>
> Dein Microcontroller und das externe Gerät kommen in VLAN 1, untagged
> Der externe Port kommt in VLAN 2, untagged
> Das Compute Module kommt in VLAN 1 und 2, und diese Switch Port muss
> tagged Pakete (also mit 802.1p/q Tag) senden und empfangen. Das Compute
> Modul natürlich auch. Das spielt dann Router bzw Proxy.

Ich nochmal dazu. Hatte gerade einen kleinen Denkfehler und hatte deinen 
Vorschlag nochmal richtig gelesen:

Nach deinem Vorschlag bedeutet das aber, dass das CM hier das Routing 
(NAT) macht. Sprich in meinem jetzigen Aufbau ist das nicht möglich 
(alleine nur mit VLANs vom KSZ8895) dies zu realisieren, da das CM mit 
Display nur optional ist. Möglich wäre es wieder dann, wenn das CM 
fester Bestandteil des Hardwareaufbaus ist und das Display lediglich 
optional ist, jedoch aber nicht das CM selbst.

Harry L. schrieb:
> VLAN ist sicherlich der eleganteste Weg.
> Dabei hat dein RaspberryPi so viele logische Ethernet-Schnittstellen,
> wie du VLANs konfiguriert hat.
> Auf dem RPi ein NAT zwischen 2 Schnittstellen zu schalten ist die
> leichteste Übung.
>
> Entspricht eigentlich genau dem im Eingangspost geforderten Scenario,
> nur eben ohne zusätzliche Hardware.

Hallo Harry,

auch dir vielen Dank für deine Rückmeldung. Wie ich hier gerade in 
diesem Post bezüglich Franks Aussage nochmal berichtigt habe, ist also 
das CM mindestend notwendig, da nur mit VLANs durch den KSZ8895 und ohne 
das CM die Geschichte mit einer IP für alles nicht möglich ist, 
entsprechend:

Tony S. schrieb:
> Meine Vorstellung sieht so aus:
>
> - xPico hat IP A
> - RPi CM hat IP B
> - Gerät X hat IP C
>
> -> "universelle" xPico IP durch die alle Komponenten von extern
> angesprochen werden können
> -> Anfrage an IP A Port 80 weiter zu CM
> -> Anfrage an IP A Port xx weiter zu xPico / seriell zum µC
> -> Anfrage an IP A Port yy weiter zu Gerät X

Also unterm Strich muss das CM fester Bestandteil der Anordnung werden 
und nur das Display am CM wird optional. Bedeutet weiterhin das ein 
Umbau so hier sinnvoll ist:

Externes Ethernet <-> ETH A CM // ETH B CM <-> KSZ8895 <-> µC, GerätX,..

Im CM dann die entsprechenden NAT Regel aufstellen und fertig. Da wäre 
dann ja eigentlich auch kein VLAN Setup im KSZ8895 nötig, wenn das CM 
das Routet(?).

Geht ihr so mit?

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tony S. schrieb:
> Frank K. schrieb:
>> Mach VLANs nach 802.1q auf. Dein Switch kann das.
>>
>> Dein Microcontroller und das externe Gerät kommen in VLAN 1, untagged
>> Der externe Port kommt in VLAN 2, untagged
>> Das Compute Module kommt in VLAN 1 und 2, und diese Switch Port muss
>> tagged Pakete (also mit 802.1p/q Tag) senden und empfangen. Das Compute
>> Modul natürlich auch. Das spielt dann Router bzw Proxy.
>
> Ich nochmal dazu. Hatte gerade einen kleinen Denkfehler und hatte deinen
> Vorschlag nochmal richtig gelesen:
>
> Nach deinem Vorschlag bedeutet das aber, dass das CM hier das Routing
> (NAT) macht. Sprich in meinem jetzigen Aufbau ist das nicht möglich
> (alleine nur mit VLANs vom KSZ8895) dies zu realisieren, da das CM mit
> Display nur optional ist. Möglich wäre es wieder dann, wenn das CM
> fester Bestandteil des Hardwareaufbaus ist und das Display lediglich
> optional ist, jedoch aber nicht das CM selbst.

Genau so ist es. Alles andere wäre aber mehr Aufwand.

> Externes Ethernet <-> ETH A CM // ETH B CM <-> KSZ8895 <-> µC, GerätX,..
>
> Im CM dann die entsprechenden NAT Regel aufstellen und fertig. Da wäre
> dann ja eigentlich auch kein VLAN Setup im KSZ8895 nötig, wenn das CM
> das Routet(?).
>
> Geht ihr so mit?

Das CM hat kein Ethernet eingebaut. Wie realisierst Du das, und wieviele 
Ethernet-Interfaces hast Du?

Wenn Du zwei unabhängige Ethernet-Interfaces hast, brauchst Du kein 
VLAN. Nur wenn Du nur ein physikalisches Ethernet am CM hast, brauchst 
Du VLAN, damit die anderen Geräte unter allen Umständen nur und 
ausschließlich über das CM und dessen IP-Adresse erreichbar ist. Du 
musst damit nur ein Gerät gegen Angriffe von außen sichern.

fchk

Autor: Tony S. (tooony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Das CM hat kein Ethernet eingebaut. Wie realisierst Du das, und wieviele
> Ethernet-Interfaces hast Du?
>
> Wenn Du zwei unabhängige Ethernet-Interfaces hast, brauchst Du kein
> VLAN. Nur wenn Du nur ein physikalisches Ethernet am CM hast, brauchst
> Du VLAN, damit die anderen Geräte unter allen Umständen nur und
> ausschließlich über das CM und dessen IP-Adresse erreichbar ist. Du
> musst damit nur ein Gerät gegen Angriffe von außen sichern.

Vielen Dank, jetzt bin ich im Bilde :)

Jetzt habe ich einen LAN9514 am RPi CM, sodass der Pi dadruch an Netz 
kommt, sowie PoE für den Saft. Kurz gesagt, das CM mit PoE / LAN und 
Display ist eine Einheit für sich. Jetzt würde ich das CM mit auf die µC 
Platine verlagern.

Ob ich den RPi mit einem Netzwerkinterface und dann entsprechenden VLANs 
betreibe oder mit zwei Netzwerkinterfaces, würde ich mal abhängig vom 
größeren Aufwand machen, sowie dem Platz auf der Platine (ist stark 
begrenzt). Aktuell tendiere ich zu zwei ETH-Ports am CM durch zwei 
LAN9514 Chips. Hier müsste der eine LAN9514 an den USB des anderen 
LAN9514 nehme ich an? Sollte der Kernel vom Pi ja problemlos mit umgehen 
können?

In ein paar Tagen ist mein Prototypen-Board mit dem KSZ8895 und einem 
Atmega328 daneben da, sowie diversen Jumpern für die 
Standalone-Variante. Da versuch ich mal mittels SPI dort die 
entsprechenden Einstellungen zu setzen für die VLAN Geschichte.

Vielen Dank für eure Hilfe!

Autor: Tony S. (tooony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleiner Nachtrag:

So, ich habe testweise den normalen Raspberry Pi 3 mal als WLAN Router 
eingerichtet und mit NAT regeln einen dahinterliegenden Webserver 
angesprochen. Funktioniert wunderbar! Also kommen an mein CM 2 
Ethernet-Schnittstellen dran.

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tony S. schrieb:
> Also kommen an mein CM 2 Ethernet-Schnittstellen dran.

Hättest du VLAN verstanden, (oder versucht, das zu verstehen) wäre das 
vollkommen unnötig.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.