Unidirektionale Datenverbindung zwischen zwei Rechnern aufbauen

Was du dabei auch noch bedenken solltest: Du hast dann keinerlei 
Kontrolle, ob die Daten auch fehlerfrei beim Empfänger angekommen sind. 
Du müßtest dann also ein Protokoll mit FEC einsetzen, damit der 
Empfänger wenigstens eine Möglichkeit der Korrektur bei 
Übertragungsfehlern hat.

> USB-Stick mit Hardware-Schreibschutz
gibt es denn so etwas?

> Das Ganze ist übrigens privat.
damit ist die Anforderung vermutlich Blödsinn.

Mach es über Netzwerk, dort über eine Firewall (kann auch eine klein Box 
sein) nur UDP in einer Richtung zulassen und gut ist.

Bei Unidirektionale hast du aber immer noch das Problem, das du nicht 
weißt ob die Daten wirklich richtig angekommen sein.

Tim R. schrieb:
> Was du nicht erwähnt hast, was dort rüber gehen soll. Wenn du von
> langsam sprichst, dann solltest du auch mal eine Größenordnung angeben
> oder wozu das ganze geeignet sein soll

Die Verbindung soll Daten transportieren,  keine Echtzeit notwendig. Die 
Größe variiert, schätzungsweise <500MB. Ist halt eine Zeitfrage (500 MB 
dauern einen halben Tag bei 115200 kbaud, wenn ich mich nicht verrechnet 
habe).

npn schrieb:
> Du müßtest dann also ein Protokoll mit FEC einsetzen, damit der
> Empfänger wenigstens eine Möglichkeit der Korrektur bei
> Übertragungsfehlern hat.

Das stimmt leider, liegt aber in der Natur der Sache (kein Rückkanal). 
Ein "ACK" wäre naturlich toll. Kennst Du da ein Protokoll? Ansonsten 
muss ich halt mit Prüfsummen arbeiten.

Peter II schrieb:
> Das Ganze ist übrigens privat.
>
> damit ist die Anforderung vermutlich Blödsinn.

Möglicherweise, aber was ist schon sinnvoll?

Martin Schlüter schrieb:
> Das könnte ein in die
> RS232 Leitung eingeschleifter Mikrocontroller mit 2 UARTS tun. Daten in
> der richtigen Richtung werden ungeprüft durchgereicht, und auf dem
> Rückkanal werden nur wohldefinierte Zeichen/Sequenzen weitergereicht,
> das kann man ja z.B. auf XON/XOFF, Datenpaket war OK, Datenpaket war
> fehlerhaft bitte wiederholen, u.ä. reduzieren.

Weitere Idee, um das noch weiter zu vereinfachen:
Es wäre doch auch möglich, nur den Rückkanal über den µC zu geben, wenn 
der Hin-Kanal sowieso alles durchreicht, oder?

Martin SchlüterEmpfängerinBeitrag #3776653:
> Hallo,
>
> zu RS232 hätte ich da eine Idee: Da das kappen des Rückkanals eigentlich
> immer zu Problemen führt, die Übertragung kann nicht auf Korrektheit
> geprüft werden, keine Flusssteuerung, ... sollte schon eine
> Kommunikation in beide Richtungen möglich sein, der Rückkanal darf aber
> nur für die obengenannten Zwecke benutzt werden. Das könnte ein in die
> RS232 Leitung eingeschleifter Mikrocontroller mit 2 UARTS tun. Daten in
> der richtigen Richtung werden ungeprüft durchgereicht, und auf dem
> Rückkanal werden nur wohldefinierte Zeichen/Sequenzen weitergereicht,
> das kann man ja z.B. auf XON/XOFF, Datenpaket war OK, Datenpaket war
> fehlerhaft bitte wiederholen, u.ä. reduzieren.
>
> Mit freundlichem Gruß - Martin

Gute Idee! Der Empfänger könnte die Daten einfach spiegeln. Der uC würde 
dann auf das Echo prüfen von dem, was er zuvor gesendet hat!

Bevor hier weiter spekuliert wird bräuchte man eigentlich mal Infos vom 
TS um was für Daten es sich handelt. Dann kann man über ein geeignetes 
Übertragungsmedium nachdenken.

Steffen Hausinger schrieb:
> Das stimmt leider, liegt aber in der Natur der Sache (kein Rückkanal).
> Ein "ACK" wäre naturlich toll. Kennst Du da ein Protokoll? Ansonsten
> muss ich halt mit Prüfsummen arbeiten.

Eine Prüfsume nützt dir nichts, denn sie sagt dir nur, dass ein (oder 
auch mehrere) Fehler aufgetreten ist (oder sind). Für eine FEC mußt du 
die Daten redundant senden, damit auch eine Korrektur möglich ist. Der 
Empfänger muß also in der Lage sein, aus dem empfangenen Datenstrom 
herauszufinden, welche Daten falsch sind und diese durch richtige Daten 
zu ersetzen.
Was es da für Möglichkeiten / Protokolle gibt, findest du hier:
http://en.wikipedia.org/wiki/Forward_error_correction
Hier stehen auch noch ein paar Infos:
http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur

Eigentlich sollte sowas auch mit Ethernet gehen. 10 oder 100 Mbit mit 
einem doofen Hub dazwischen. Das Empfangsaderpaar von der unsicheren 
Seite wird am Hub nicht angeschlossen. Die Übertragen erfolgt dann mit 
UDP Broadcast Paketen.
Es muss natürlich genug Redundanz vorhanden sein um Fehler zu 
korrigieren.

Wie tragisch sind bei deiner Übertragung fehlende Pakete?

z.B. bei einer Audio Live Übertragung würde ein kurzer Aussetzer ja kaum 
auffallen.

Mach es nicht so kompliziert.
TX geht beim unsicheren PC auf ein max232 und wird dann einfach 
zurückgeschickt.
Sichere PC hat ein HW remote loopackmit repeater (wichtig) und 
unsicherer nur ein rx.
Sollte HW flusssteuerung notwendig sein, dann muss ein UC mit buffer 
inzwischen geschälten werden.
Stromversorgung für max232 muss vom PC genommen werden. Default pull up 
nicht vergessen.

Türöffner schrieb:
> Eigentlich sollte sowas auch mit Ethernet gehen. 10 oder 100 Mbit

Klar und der PC geht dann in den half duplex mode, dieser braucht nur 
ein Adernpaar und du merkst es nicht mal.


> Wie tragisch sind bei deiner Übertragung fehlende Pakete?
>
> z.B. bei einer Audio Live Übertragung würde ein kurzer Aussetzer ja kaum
> auffallen.

Ichhabe mir gerade überlegt (um mal bei der RS232 zu bleiben), daß es 
doch noch viel einfacher wäre, wenn es auf der Senderseite ein Programm 
gibt, das nur (blockweise zum Beispiel) Daten senden kann und lediglich 
Steuerdaten empfangen kann (ACK / NAK). Und auf der Empfängerseite kann 
das Programm nur Daten empfangen und sie dann ledglich bestätigen oder 
neu anfordern. Die Programme wären relativ leicht zu programmieren, man 
muß kein FEC-Protokoll implementieren, sondern nur eine CRC auswerten 
und bei Fehler den Datenblock nochmal anfordern. Alles andere läßt man 
weg. Da könnte doch ein potentieller Schädling, der sich auf dem 
Empfänger-Rechner befindet, nichts auf dem Sende-Rechner anrichten. Oder 
sehe ich das falsch?
Klar müßten dann zwei kleine Progrämmchen für die beiden PCs geschrieben 
werden, aber das sollte doch kein Problem sein...
Habe ich was übersehen oder nicht beachtet?

Steffen Hausinger schrieb:
> USB-Stick mit Hardware-Schreibschutz

Das ist in der Regel zwar ein mechanischer Schalter, der aber auch nur 
in Software ausgewertet wird.

Ich habe eine Zeitlang Daten vom Krypto-Notebook zum normalen PC (und 
andersherum) per CD-R transportiert. CD-brenner war in beiden vorhanden. 
Und daß man von demn 700MB teilweise nur ein paar Kilobyte nutzt, jo 
mei...

Einfach eine SD-Karte nehmen. Im Quell-Rechner beschreiben, im 
Ziel-Rechner auslesen. Bevor sie wieder in den Quell-Rechner kommt, in 
der Kamera formatieren. Wenn du der nicht traust, baust du dir mit einem 
Arduino mit SD-Shield einen SD-Formatierer - der wird sicher von nichts 
befallen.

Schnell, guenstig und ausreichend paranoid.

Ich würd's seriell über einen USB/RS232-Konverter machen: Die Hardware 
ist schnell gestrickt, die Treiber gibt's auch und sicher ist es, weil 
nur ein darauf spezialisiertes Programm überhaupt etwas mit der 
Verbindung anfangen kann. Der FTD232r kann 3MBaud/s, damit sind 2MBit/s 
drin, schnell genug, umm 500MByte in erträglicher Zeit zu übertragen. 
Mit Protokoll, damit Übertragungsfehler erkannt werden - anders macht 
das keinen Sinn.

Quack+ schrieb:
> Einfach eine SD-Karte nehmen.

Hat auch einen Mikroprozessor und ist damit für wahre Paranoiker 
ungeeignet. :-)

Siebzehn Zu Fuenfzehn schrieb:
> Sowas daemliches. Man kann sich ja auch darauf beschraenken, nur
> Daten
> und keine Programme zu uebertragen

Du weißt ja nicht, was er überhaupt damit machen will. Wenn es 
beispielsweise eine Art Datensicherung sein soll, dann können natürlich 
auch Programme dabei sein. Ein Backup wäre wenig sinnvoll, wenn die 
Programme nicht mitgesichert werden.

radiostar schrieb:
> Mit Protokoll, damit Übertragungsfehler erkannt werden - anders macht
> das keinen Sinn.

dann kann er auch gleich Netzwerk machen und braucht sich nicht zu 
kaufen um dann doch nur 3mbit/s zu übertragen.

Dann muss er die Einbahnstraße nur in Form von Software umsetzen.

Ich wollte zum Spaß schreiben:
Nimm ein Gbit LWL und zieh einen Stecker.

Jetzt gibts das wirklich:
http://www.giac.org/paper/gsec/2848/unidirectional-networking/104817

Steffen Hausinger schrieb:
> aber erstmal ging es darum, überhaupt eine Lösung zu finden.

Du musst dir darüber klar sein, dass eine Lösung wie etwa ein 
Lichtleiter ohne Rückkanal in ein Dilemma führt: es gibt keine 
Verifizierung der übertragenen Daten, die Übertragung ist also nicht 
sicher gegen Fehler aller Art. Führst du eine Prüfung und Rückmeldung 
ein, ist die Diodenwirkung aufgehoben.

Georg

Georg schrieb:
> die Übertragung ist also nicht
> sicher gegen Fehler aller Art.

Dann codiert man die Daten halt geeignet.

Ist ja nicht so, daß "Rückmeldung" zwingend wäre, um Übertragungsfehlern 
entgegenwirken zu können.

Gustav schrieb:
> Ist ja nicht so, daß "Rückmeldung" zwingend wäre, um Übertragungsfehlern
> entgegenwirken zu können.

Ganz so einfach ist es nicht. Das sendende System würde es nicht mal 
merken, wenn die Verbindung überhaupt nicht mehr besteht. Also müsste 
der Admin immer wieder mal nachsehen (am anderen Ende), ob überhaupt 
noch was ankommt, und ob es korrekt ist.

Georg

Man könnte auch in festen Zeitabständen eine Datei senden die ein 
Verzeichnis der gesendeten Dateien und deren Prüfsummen enthält die seit 
der letzen Datei dieser Art eingegangen sein sollten.

chris schrieb:
> loopackmit

Was ist das?

Sollte heissen loopback mit.
Ein HW loopback mittels max232 welcher vom PC seine vcc bezieht.
So wird das Signal empfangen und zurück gesendet.
Der sichere PC kann so erkennen dass die Daten richtig angekommen sind 
oder nicht und weiters ob der remote PC an oder aus ist. Auch werden 
normalerweise die x Pakete vor dem Ausschalten nachträglich invalidiert.

Nö,
alles was man dann weis ist das der Empfangende PC den MAX mit Strom 
versorgt.
Der kann auch grade mit einer BIOS Fehlermeldung da stehen, oder bei Win 
mit einem Bluescreen

Der unsichere PC könnte mit RTS und DTR vier Zustände signalisieren 
00-01-10-11. Dies könnte in Kombination mit einer CRC (besser noch 
Reed-Solomon-Codes) zur Fehlererkennung und Transferwiederholung genutzt 
werden.

Das Problem mit dem Rückkanal ist dass ein Programm damit auf dem 
sicheren Rechner so SW nachladen kann. In so einem falle wie schon 
geschrieben UC mit grossen buffer dazwischen ist nötig, ansonsten ist es 
viel zu einfach dies zu umgehen. Dann kann auch HW flow zwischen UC und 
unsicheren PC verwendet werden. Dieser UC sollte dann die Möglichkeit 
haben den ma232 auszuschalten.

chris schrieb:
> In so einem falle wie schon
> geschrieben UC mit grossen buffer dazwischen ist nötig

Im Endeffekt beschreibst du hier eine externe Firewall, die nur 
bestimmte Telegramme durchlässt.
Sowas lässt sich auch bei Ethernet mit einer externen Firewall 
realisieren.

Wobei man da mit genug Paranoia auf das Herstellungsland der Firewall 
achten muß damit man weis welcher Geheimdienst da eine Backdoor hat.

hp-freund schrieb:
> Man könnte auch in festen Zeitabständen eine Datei senden die ein
> Verzeichnis der gesendeten Dateien und deren Prüfsummen enthält die seit
> der letzen Datei dieser Art eingegangen sein sollten.

Wenn die Verbindung unterbrochen ist, kommt die ja auch nicht an. Man 
müsste also beim Empfänger noch ein Time Out installieren und die Datei 
automatisch auswerten, sonst ist dem Admin nicht damit geholfen.

Georg

00 - Ready Zustand
01 - Daten Angekommen Checksumme OK (Daten konnten durch redundanz 
gerettet werden) zusätzlich wenn das signal nach Transfer und einer 
gewissen Latenz nich kommt kein empfänger da
10 - Daten haben Checksummen Fehler Wiederholungsanfrage
11 - was weiß ich...