Hallo zusammen,
ich möchte physikalisch die Übertragungsrichtung in meinem Ethernet
(100BASE-TX) vorgeben. Da Ethernet in den halb-duplex Modus wechseln
kann, genügt es nicht, einfach das entsprechende Adernpaar (Rx oder Tx)
zu trennen. Außerdem hat der Controller per Auto MDI-X die Möglichkeit,
die Adernpaare zu tauschen (Rx könnte zum Senden verwendet werden oder
umgekehrt).
Mein Ansatz ist es deshalb, vor dem Übertrager einen OpAmp
einzuschleifen. Ich würde also einen einfachen(?) Spannungsfolger
verwenden. Soweit die Theorie. Offen gesagt habe ich aber nicht viel
Erfahrung mit OpAmps. Funktioniert das in der Praxis so?
Welchen OpAmp könnte ich dafür nehmen? Sehe ich das richtig, dass jeder
mit >=125MHZ GBW passen würde? Muss ich noch irgendwas bzgl. der
Frequenzkompensation beachten?
Schöne Grüße
Steffen
Noch einer schrieb:> Willst du eine vorhandene Karte umbauen? Für Eigenentwicklungen> gäbe es> reine physical layer transceiver, mit TX_DATA und TX_ENABLE Eingang.
Ja, ich möchte eine vorhandene Karte umbauen (eine Eigenentwicklung ist
zu aufwändig). Kannst Du mir bitte trotzdem ein Beispiel für solch einen
IC nennen? Evtl. finde ich dann Karten, auf denen so einer verbaut ist
(und kann mir das Umbauen per OpAmp sparen).
Jan Berg schrieb:> Meine Frage zielte darauf ab, dass viele Protokoll einen> Datentransfer> in beide Richtungen zwingend benötigen.
Ach so. Es gibt eine bereits eine lauffähige Lösung. Dort wird der Umweg
über eine optische Übertragung genommen, bei der der entsprechende LWL
nicht angeschlossen ist. Ich suche nach einer günstigeren und
platzsparenderen Lösung.
Falls es Dich interessiert, schau (beispielsweise) mal hier:
http://ephemer1c.wordpress.com/2013/05/16/data-diode/ .
Paul Hamacher schrieb:> Wozu braucht man so was?
In deutschen Wikipedia steht nichts, aber in der englischen:
http://en.wikipedia.org/wiki/Unidirectional_network
Ich würde mich sehr freuen, wenn mir jemand bei meiner Frage
weiterhelfen könnte: Klappt das mit einem OpAmp? Welche wäre dafür
geeignet? Nach welchen Kriterien muss ich schauen? Kann ich da jeden
beliebigen nehmen, der eine GBW von >=125MHz besitzt?
Grüße
Steffen
Steffen Hausinger schrieb:> Hallo zusammen,
...
> Da Ethernet in den halb-duplex Modus wechseln> kann, genügt es nicht, einfach das entsprechende Adernpaar (Rx oder Tx)> zu trennen.
Doch, das tut es, auf Schnittstellen mit getrennten Adernpaaren sind
auch die Signale getrennt. Bei halbduplexen Verbindungen kommt halt das
was Du rein schickst gleich wieder zurück.
> Außerdem hat der Controller per Auto MDI-X die Möglichkeit,> die Adernpaare zu tauschen (Rx könnte zum Senden verwendet werden oder> umgekehrt).
Das ist eher ein Problem, da Du aber eh vorher schon die Autonegotiation
abschalten musst, kannst Du auch Auto MDI-X deaktivieren.
Christian Berger schrieb:> Das ist eher ein Problem, da Du aber eh vorher schon die Autonegotiation> abschalten musst, kannst Du auch Auto MDI-X deaktivieren.
Ja, das stimmt schon. Jedoch schalte ich sie per Software ab. Ich bin
aber explizit auf der Suche nach einer Hardware-Lösung. Also nach etwas,
dass ich vollständig kontrollieren kann.
Die Info mit dem Betrieb per halb-duplex habe ich übrigens von einem
anderen User: Beitrag "Re: Unidirektionale Datenverbindung zwischen zwei Rechnern aufbauen" .
Also man muss ja jetzt keine KLimmzüge mit Opamps machen.
Schonmal darüber nachgedacht 2 Ethernet PHYs miteinander zu verbinden
und das eben nur für eine Richtung?
Die PHYs haben das sognenannte MII Interface.
http://en.wikipedia.org/wiki/Media_Independent_Interface
Steffen Hausinger schrieb:> Welchen OpAmp könnte ich>100MHz: Mein Horoskop sagt, daß diese Signale etwas verschliffen und verzögert
sein könnten durch den OPV.
Meiner Einschätzung nach ist das nicht so trivial, dass man sagen
könnte, das es mit einem OP einfach so funktioniert. Also Finger weg.
Die Leitungscodierung hat meist mehrere Spannungslevel (zumindest bei
GbEth), und das Halb-Duplex macht es nicht einfacher.
Die Idee von Martin
Martin Wende schrieb:> Schonmal darüber nachgedacht 2 Ethernet PHYs miteinander zu verbinden> und das eben nur für eine Richtung?> Die PHYs haben das sognenannte MII Interface.> http://en.wikipedia.org/wiki/Media_Independent_Interface
finde ich sehr gut. Man kann die Phys auch meist ohne FW so einstellen,
dass sie keine Auto-negotiation machen und sich gleich als Halb-Duplex
melden. Am MII Interface kann man das TXEN einfach auf 0 setzen und
somit werden keine Daten mehr gesendet, aber falls notwendig wird die
Leitungscodierung dementsprechend aufrecht erhalten. Ich bin in 10/100
MBit Ethernet leider zu weit weg. Aber wie gesagt, bei 1G Ethernet
(sollte wohl ähnlich sein) ist das ganze nicht gerade einfach.
Wenn du ein Adernpaar kappst, wird das sowieso nichts mehr mit MDI-X,
oder auch nur mit 100Mbit. Oder überhaupt mit Ethernet. Wenn keine
Link-Pulse empfangen werden, denkt der MAC nämlich, es steckt kein Kabel
in der Buchse, und sendet nichts, bzw. der Treiber meldet dann, daß die
Schnittstelle tot ist. Link Pulse kann man fälschen, dann klappt
zumindest 10Mbit. Oder man konfiguriert den Chip fest auf 100Mbit
Vollduplex und irgendeinen Testmodus, damit er das Fehlen der Link-Pulse
ignoriert. Dazu braucht man aber wahrscheinlich den Quelltext des
Treibers.
Wenn du das schon mal mit optischem Ethernet gemacht hast, gehe ich
davon aus, daß mit den höheren Protokollschichten alles geklärt ist. Für
IP z.B. (TCP kann man ja eh vergessen) muß man da ja die ARP-Tabelle von
Hand bestücken.
abc123 schrieb:> Meiner Einschätzung nach ist das nicht so trivial, dass man sagen> könnte, das es mit einem OP einfach so funktioniert. Also Finger weg.>> Die Leitungscodierung hat meist mehrere Spannungslevel (zumindest bei> GbEth), und das Halb-Duplex macht es nicht einfacher.
Bei twisted-pair bis 100Mbit ist das Halbduplex nur künstlich, d.h. die
MACs beider Seiten halten sich an die Regel, nicht gleichzeitig zu
senden (wg. Rückwärtskompatibilität); es ist trotzdem für jede Richtung
genau ein Adernpaar vorhanden.
Mit mehreren Spannungsleveln sollte ein OP als grundsätzlich analoges
Bauteil ja einigermaßen klarkommen. Und wenn er für den Frequenzbereich
grundsätzlich geeignet ist, sollte er das Signal auch nicht schlimmer
verschleifen als 100m Kabel das tun. Verzögerung spielt auch keine
Rolle: der Empfänger kann ja nicht wissen, wann gesendet wurde.
Steffen Hausinger schrieb:> Ja, ich möchte eine vorhandene Karte umbauen
Du hast also einen normalen PC und suchst dafür eine passende
Netzwerkkarte die Du umbauen kannst?
Wird glaube ich gar nicht mehr einfach, denn Du kannst ja nicht einfach
auf PCI/PCIe-Ebene irgendwas blocken, sondern Du musst zwischen MAC und
PHY und dort die passenden Leitungen unterbrechen. Und schon seit
einigen Jahren sind MAC und PHY bei PC-Netzwerkkarten in einem
gemeinsamen IC untergebracht. Du kommst also nicht so einfach an die
nötigen Verbindungen.
Etwas eigenes mit 2 PHY-ICs und nem µC der die konfiguriert hochzuziehen
wäre zwar möglich, ich halte es aber nicht für wirtschaftlich.
Du schreibst ja daß Du schon erfolgreich LWL-Medienkonverter einsetzt.
Die Schiene würde ich weiter gehen und dort nach günstigen Komponenten
suchen. Die Dinger sind echt nicht mehr teuer:
Je 2 Stück von
http://www.ebay.de/itm/311072659260 und
http://www.ebay.de/itm/301307563515
zusammen sollten es eigentlich tun, das wären ca. 60 EUR insg. Geht
wahrscheinlich noch günstiger, das waren jetzt nur 3 Minuten Suche.
Mit einer selbstentwickelten Lösung dürfte es erst billiger werden wenn
Du viele Hundert Stück brauchst.
Soweit ich weiß, verwendet Airbus solche "Datendioden" um die beiden
Ethernet-Bordnetze für Cockpit und Infotainment zu trennen. Es können
nur Daten vom Cockpit Richtung Kabine fließen, um z.B. Höhe und
Geschwindigkeit anzuzeigen. Andersherum ist eine Beeinflussung
elektrisch ausgeschlossen.
Sicherlich gibt es noch mehr solcher Anwendungsfälle und daher auch
günstige Lösungen.
Alexander Schmidt schrieb:> Airbus
[...]
> daher auch> günstige Lösungen.
Ich glaube nicht daß "Airbus" und "günstige Lösung" zusammenpasst.
Im Flugzeug hast Du außerdem kein normales Ethernet, da steckt noch jede
Menge spezifische QoS-Technik, Priorisierung, Bandbreitengarantien etc.
schon auf den unteren Layern.
Es gibt aber wirklich noch mehr sinnvolle Anwendungsfälle für sowas,
auch mit ganz normaler PC-Technik: z.B. ein Logging-Server bei dem man
sichergehen will, daß er nicht über das Netz manipuliert werden kann.
Es gibt doch kleine managebare Switche, wie zB den HP Procurve 1810-8G
v2. Damit sollte so etwas hinzubekommen sein. Du kannst zB den Traffic
an einem Port zusätzlich an einen anderen ausleiten (Port Mirroring).
Wenn dann der Mirror Port in einem anderen VLAN ist, müsstest Du Deine
Konfiguration haben.
fchk
Frank K. schrieb:> Wenn dann der Mirror Port in einem anderen VLAN ist, müsstest Du Deine> Konfiguration haben.
Nein, weil sich das nach wie vor alles auf der Software-Ebene abspielt
und Software bekanntermaßen "angreifbar" ist. Ich finde es erstaunlich
wie wenig Verständnis es für den Fragesteller hier gibt. So ungewöhnlich
ist die Anforderung nämlich nicht, und ich wünschte mir, dass sich die
Industrie mit ihren Atomkraftwerken, Staudämmen und was es sonst noch so
an "gefährlichen" Einrichtungen gibt, eine Scheibe davon abschneiden
würde, anstatt alles willenlos ans Internet zu hängen, weil Fernwartung
ja so bequem ist.
Spätestens seit Stuxnet sollte doch bekannt sein was man mit reiner
Software alles anstellen kann. Und da helfen VLANs und
Treibermanipulationen nicht weiter, weil es prinzipiell angreifbar
ist.
Mit freundlichen Grüßen,
Karol Babioch
Vielen Dank für Eure Antworten. Ich hatte geplant, den OpAmp zwischen
PHY IC und Übertrager Baustein einzusetzen. Das hätte den Vorteil, dass
es günstig und platzsparend ist. Schade, dass das nicht ohne Weiteres
funktioniert.
Ich werde mir die Idee mit den 2x PHY MII Bausteinlösung von Gerd E.
diese Woche anschauen!
Grüße
Steffen
Du suchst einen "Network Tap".
Für Glasfaser und 10/100Mbit geht das rein passiv, für Kupfer Gigabit
leider nicht so leicht.
Da du den etwas zweckentfremden willst und nicht Daten mitschnorcheln,
müsstest du ggf. am anderen Ende ein Dummy-Device hängen, damit der
Quellrechner einen Link aufbaut. Im einfachsten Fall kann das ein dummer
kleiner Switch sein.
Am Mirror Port greifst du dann dein Nutzsignal ab.
Jedwedes Verbindungsorientiertes Protokoll auf höheren Ebenen ist damit
natürlich ohnehin raus, denn antworten geht ja nicht.
>z.B. ein Logging-Server bei dem man>sichergehen will, daß er nicht über das Netz manipuliert werden kann.
In dem man verhindert das er Daten senden kann? Hier würde das
Datenempfangen wohl eher ein Sicherheitsproblem darstellen...
gruß Jonas
Dir ist aber schon klar, dass über diese "Diode" das heute übliche
TCP/IP-Protokoll nicht funktioniert? Zu jedem gesendeten Datenpaket
gehört ein Acknowledge, und das kommt dann nicht durch. Darüber hinaus
besteht der Grundgedanke bei CD/MA darin, erst am Bus zu lauschen und
nur zu senden, wenn dort gerade Ruhe ist.
RX-Only wäre möglich. D.h. ein Netzwerksniffer, der den Datenverkehr
nicht beeinflußt. Aber Du scheinst ja TX-Only haben zu wollen.
