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?
socat oder dog. Oder ein USB-nach-Seriell-Konverter für 5 Euro von HAMA?
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:
1 | man mkfifo |
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.txt http://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/Inetd http://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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.