Ich suche nach einer (Freeware-)Linux-Anwendung möglichst mit
Source-Code oder einer Möglichkeit mit Linux-Hausmitteln (z.B. bash) dem
System eine virtuelle Schnittstelle auf der einen Seite zur Verfügung
stellen zu können und diese auf der anderen über TCPIP-Socket-Verbindung
mit einem Hardware-Konverter verbinden zu können. Meine Internet-Suche
diesbezüglich hat mir für Linux keinen Erfolg gebracht. com0com unter
sourceforge scheint nur für Windows bestimmt zu sein. Gibt es etwas
entsprechendes kostenlos auch für Linux?
Hintergrund ist folgender: Eine Anwendung, dessen Umprogrammierung
kostspielig oder sogar unmöglich wäre, spricht einen Barcode-Scanner
über serielle Schnittstelle an. Das Protokoll ist echtzeitunkritisch,
sehr einfach und ohne Hardware-Handshake. Nun hat der Rechner, auf dem
diese zum Laufen kommen wird aber nur eine einzige serielle
Schnittstelle und die wird bereits durch eine andere, wesentlich
aufwendigere Verbindung, blockiert. Eine Erweiterung ist
bauformspezifisch nicht möglich. Die Lösung wäre eine entsprechende
Proxy-Anwendung, die einen Konverter über Ethernet anbindet.
Hat jemand für mich eine Lösung?
Sven, danke. USB-Serial geht leider nicht, da der Hardware-Konverter
verwendet werden muß. Der hat den physischen Com-Port und stellt selbst
über Ethernet einen TCPIP-Socket zur Verfügung. Entweder als Listener
oder als Client.
Socat klingt sehr interessant und ich werde versuchen mehr darüber zu
erfahren. Beim googlen nach dog finde ich aber nichts brauchbares. Hast
Du einen Link für mich zum Nachlesen?
Ich denke, socat kann eine Fragestellung lösen aber ich habe immer noch
die nach der Bereitstellung eines virtuellen Ports, damit ich die
fertige Anwendung damit verbinden lassen kann anstatt sich direkt mit
/dev/ttyS0 zu verbinden. Wie sieht ein entsprechendes Beispiel aus?
(Ich bin noch Linux-Anfänger)
Naja, "dog" ist quasi eine Weiterentwicklung von "cat"... oder evtl.
"war" eine Weiterentwicklung, ich finds auch nirgendwo mehr.
Als Ersatz für dein tty-Dingens reicht vermutlich schon eine einfache
Pipe:
Habe ich das richtig verstanden, daß ich mit mkfifo() z.B. mit
pathname="/dev/ttyS99" eine "virtuelle Schnittstelle" für meine
Anwendung zur Verfügung stellen kann, die ich dann mit socat "anzapfen"
kann? Also die eine Seite von socat auf "device" und die andere auf "TCP
socket" einstellen? Diese Lösung klingt für mich wirklich gut und
einfach, wenn es wirklich so geht.
Ist mkfifo auch als command line tool verfügbar oder muß ich den Aufruf
in meine eigene Anwendung mit aufnehmen? Und wie bekommt man eine solche
als Device erscheinende Pipe-Datei wieder weg? Mit dem Ende meiner
Anwendung als Prozeß?
Worin unterscheiden sich mkfifo und mknod? Beides scheint FIFO's in
ähnlicher Weise erzeugen zu können.
Und gibt es keine Probleme, wenn die Anwendung sich mit
Lese-Schreib-Zugriff mit /dev/tty99 verbindet? Wie können Senden und
Empfangen dann mit socat auseinander gehalten werden? Eine FIFO ist
scheinbar nicht ausreichend, es wird eine für jede Datenrichtung
benötigt. Da gibt es aber das Problem, daß die Anwendung die
bidirektionale Kommunikation mit nur einem Device-Namen aufbaut.
Ich habe nun in den Manual-pages von socat folgendes gelesen:
1
PTY
2
Generates a pseudo terminal (pty) and uses its master side.
3
Another process may open the pty's slave side using it like
4
a serial line or terminal.
Das klingt so, als wenn es meine Frage nach einer virtuellen seriellen
Schnittstelle beantworten könnte. Aber die Frage lautet nun: Wie geht
das, die "pty's slave side" nutzen? Entsteht vielleicht ein Device-File
/dev/ptyXX, das man dann anstatt eines /dev/ttyS99 verwenden könnte? Und
wenn das so ist, wie kann man den Namen vorherbestimmen?
Sven, hast Du socat selbst schon einmal verwendet und hast damit
vielleicht auch eigene Erfahrungen? Die würden mich interessieren. Meine
Lösung muß nämlich, einmal getestet und vielfach implementiert, die
nächsten ca 20 Jahre in produktiver Industrieumgebung zuverlässig
funktionieren.
Manfred wrote:
> Ich habe nun in den Manual-pages von socat folgendes gelesen:>
1
PTY
2
> Generates a pseudo terminal (pty) and uses its master side.
3
> Another process may open the pty's slave side using it like
4
> a serial line or terminal.
> Das klingt so, als wenn es meine Frage nach einer virtuellen seriellen> Schnittstelle beantworten könnte.
Jubb.
> Aber die Frage lautet nun: Wie geht> das, die "pty's slave side" nutzen?
Naja, wie du schon erkannt hast, hat eine normale PIPE zwei Enden: In
eines schreibste rein (Schreibzugriff), und das genau solange, wie am
anderen Ende jemand rausliest (Lesezugriff).
Ein PTY hat dagegen quasi vier Enden, zwei "innen" (Master) und zwei
"außen" (Slave). Normalerweise werden die beiden inneren Enden vom
Gerätetreiber bedient und die äußeren beiden siehst du dann als
Gerätedatei in /dev.
In diesem Fall bedient SOCAT die inneren beiden Enden (z.B. durch
Weiterleitung) und konstruiert dir eine Gerätedatei (/dev/pty..) für die
äußeren beiden Enden.
> Entsteht vielleicht ein Device-File> /dev/ptyXX, das man dann anstatt eines /dev/ttyS99 verwenden könnte?
Ja, in /dev/pty...
> Und wenn das so ist, wie kann man den Namen vorherbestimmen?
Vorbestimmen garnicht, aber SOCAT kann dir zusätzlich einen Link
konstruieren, der auf die Gerätedatei zeigt. Dessen Namen kannste dann
angeben.
> Sven, hast Du socat selbst schon einmal verwendet und hast damit> vielleicht auch eigene Erfahrungen? Die würden mich interessieren.
Jo, lieb bislang immer recht problemlos -- genaueres Studium der
Anleitung natürlich vorausgesetzt. Gerade der Fork- und Reuse-Kram ist
wichtig, damit SOCAT nicht nach der ersten erfolgreichen Verbindung
abschaltet.
> Meine> Lösung muß nämlich, einmal getestet und vielfach implementiert, die> nächsten ca 20 Jahre in produktiver Industrieumgebung zuverlässig> funktionieren.
Testen kannst nur du sie.
Vielfache Implementierung gestaltet sich relativ simpel, du musst dich
nur an die GNU General Public License halten, unter der SOCAT vertrieben
wird.
Inwieweit SOCAT funktioniert, wirst du dann selbst beurteilen müssen.
Und in 20 Jahren wirst du mit SOCAT auch keine Probleme kriegen. Der
Entwickler wird SOCAT schon so bald nicht aufgeben. Wenns dann doch hart
auf hart kommt, hast du in jedem Fall die Quelltexte des Programms,
sodass du selbst Fehler beheben (lassen) kannst und das Programm auf
andere Betriebssysteme portieren kannst.
Im Gegensatz zu kommerziellen Programmen hast du halt was Brauchbares in
den Händen.
Literatur:
http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txthttp://lists.infodrom.org/linux-stammtisch/2006/0680.html
Vielen Dank an alle, die mir Tips gegeben haben. Auch für die Hinweise
auf fork, reuse, die zwei Enden innen und außen und die GNU
Lizenzbedingungen; muß ich mir für meine Zwecke noch einmal genau
durchlesen, ob das bereits abgedeckt ist oder ob ich noch individuell
anfragen muß.
socat ist tatsächlich die Antwort auf alle meine Fragen zum Thema.
socat ist echt gut. Habe ich außer unter Fedora Linux sogar schon
unter cygwin compiliert und gebunden. Einfach nur ausgepackt,
*./configure* aufgerufen und danach make und schon war das Ergebnis
einsatzbereit. Das mit pty für bidirektionale Kommunikation
funktioniert wie gewünscht. - Auch wenn ich das jetzt doch nicht mehr
brauche, zum Testen und Zusammenführen von Log-Dateien sowie zum
"Füttern" meiner pipe, mit der mein Tool "von außen" im laufenden
Betrieb gesteuert werden kann, werde ich socat weiterhin verwenden
können.
Nochmals danke für den Tip mit socat.
inetd bzwl xinetd werde ich demnächst auch noch kennenlernen, damit
kann man wohl auch einen Teil dessen tun, was socat auch kann. Hat damit
vielleicht auch schon jemand Erfahrungen gesammelt?
[x]inetd ist etwas anderes. Es kommuniziert nicht selbst, sondern
startet bei Verbindungsanfragen aus dem Netzwerk andere Programme, die
dann die eigentliche Kommunikation übernehmen. Diese anderen Programme
sind typischerweise Server für die einzelnen Netzwerkprotokolle, also
bspw. FTP- oder Telnet-Server. Für spezielle Anwendungen könnte solch
ein Server auch socat bzw. ein anderes Programm, dem mit Hilfe von socat
eine Socket-Schnittstelle verpasst wurde, sein.
http://de.wikipedia.org/wiki/Inetdhttp://www.xinetd.org/
Danke für die Info. Scheint sich ja dann ganz gut zu ergänzen, um nicht
alle Prozesse gleichzeitig laufen lassen zu müssen sondern nur nach
Bedarf jeweils zu starten - von einem einzigen Prozeß ausgehend.
