Virtueller Serial Port Splitter gesucht Win10

[Torsten C. (torsten_c)]

Hallo zusammen,
eigentlich eine 'Allerweltsfrage', aber ich finde keine Antwort:

Ich möchte einen 'virtual com port' mitschneiden. Der USB-Stick DV4mini 
verhält sich wie ein USB-VCOM und über ein Terminal will ich den 
Datenverkehr mitschneiden.

Unter Windows 7 hatte ich das schon öfter gemacht. Aber unter Win10 
läuft com0com nicht und ich finde auch keine Alternative.

Kaufsoftware könnte ich mir vorstellen, wenn es im Trial keine 
Einschränkungen gibt oder falls jemand von konkreten positiven 
Erfahrungen berichten kann.

Hat jemand einen Tipp?

VG Torsten

[Rufus Τ. F. (rufus)]

Torsten C. schrieb:
> Aber unter Win10 läuft com0com nicht

Auf der com0com-Seite selbst ist bizarrerweise Reklame für ein 
kommerzielles Produkt von Eltima zu finden:

http://com0com.sourceforge.net/

Sowas habe ich auch noch nicht gesehen.


Das eigentliche Problem dürften signierte Treiber sein. Die soll es 
für com0com hier geben:

http://pete.akeo.ie/2011/07/com0com-signed-drivers.html

(da steht zwar als Datum was von 2011, die Treiber aber sind vom Juni 
2016)

[Torsten C. (torsten_c)]

Das gute: Cool, klappt! :-) Danke, Rufus!

Das schlechte: Ich hatte wohl einen Denkfehler: Man müsste das 
DV4mini-Control-Panel (das betreffende Programm) dazu bringen, sich 
statt mit COM8 (Bild) mit CNCA0 oder CNCB0 zu verbinden, weil man 
geöffnete Ports gar nicht aufsplitten (anzapfen) kann.

Ich probiere mal, ob ich mit WireShark USBPcap was sehe. Aber eigentlich 
wollte ich die Daten in Echtzeit haben, nicht aus einer Log-Datei.

[Rufus Τ. F. (rufus)]

Torsten C. schrieb:
> COM8 (Bild) mit CNCA0 oder CNCB0 zu verbinden

Du kannst die Dinger auch umbenennen, so daß Dein abzuhörendes Programm 
auch die com0com-Ports akzeptieren sollte.

[STM32 (Gast)]

Schau mal nach hub4com, das gibt es auch im Umfeld von com0com... ist 
ein scriptconfigurierbarer Hub, mit dem Du in sämtliche 
Himmelsrichtungen routen kannst.

[Torsten C. (torsten_c)]

@STM32: So wie in Variante 1?

Ich behaupte mal: Das geht mit hub4com nicht. Oder bin ich zu blöd?

Es wäre aber cool, wenn das ginge. :)

Variante 2 wäre ohne hub4com:
* Ein neues Paar aus CNCX und COM8 erzeugen.

* Logger mit COM 8 verbinden
  (der ist dann belegt und wird nicht mehr gefunden)

* Im Logger CNCX TX an COM8 RX streamen (und loggen)
      … und COM8 TX an CNCX RX streamen (und loggen)

* Programm "SUT1" starten, das findet dann nur COM9
  … hoffentlich.

Das könnte gehen. Ich probiere das morgen mal,
mit einem Logger in C#.NET, wenn es keine bessere Idee gibt.

Ich hoffe, dass nicht auch noch DTR, CTS, RI usw. verbunden werden 
müssen.

[STM32 (Gast)]

Ich behaupte, es geht.

Nur zusammengetippelt, ohne Gewähr:
hub4com.exe --baud=115200 --octs=on --odsr=on --route=\\.\COM9 \\.\CNCA1 
\\.\COM9 \\.\CNCB1

[Torsten C. (torsten_c)]

STM32 schrieb im Beitrag #4734687:
> --route=\\.\COM9 \\.\CNCA1 \\.\COM9 \\.\CNCB1

Und dann geht COM9 TX bei COM8 RX an? ?!

Und wohin geht COM8 TX?

Falls das ein Tippfehler war, vielleicht meintest Du:
* --route=\\.\COM9 \\.\CNCA1 \\.\COM8 \\.\CNCB1
                                    ¯
Dann ginge COM8 TX zwar an CNCB1 RX, aber immer noch nicht an COM9 RX,
so wie ich das verstehe.

Mit zwei Terminals sehe ich noch kein Land.

Ein 'man in the middle' scheint leider nötig. :-(

[Helen (Gast)]

May be this
http://www.virtual-null-modem.com/

[Torsten C. (torsten_c)]

Danke, Helen.
Wie gesagt: Über ein Terminal-Programm (zwei Terminal-Fenster) will ich 
den Datenverkehr mitschneiden.

Ich finde keinen Hinweis, dass man mit 'virtual-null-modem.com' die 
beiden TX-Streams 'anzapfen' und auf zwei weitere Ports leiten kann. 
Siehe auch Variante 1 im Bild oben.

[STM32 (Gast)]

... ich hatte ja gesagt, nur schnell zusammengetippelt...


nocheinBeispile:
hub4com.exe --baud=115200 \\.\COM1 \\.\COM21 \\.\COM23 \\.\COM25 
--route=0:1 --fc-route=0:1 --route=1:0 --fc-route=1:0 --route=0:2 
--route=1:3


Bei diesem Aufruf hast Du 4 Ports. Du routest jetzt

Com 1 <=> Com 21
Com 1  => Com 23
Com 21 => Com 25


Du kannst also wirklich in alle Himmelsrichtungen, okay?

[Torsten C. (torsten_c)]

Aaaaa! Jetzt habe ich das Konzept von hub4com.exe endlich verstanden.

Logisch:
* Die Port-Paare bleiben bestehen.
* Man benötigt 3 Port-Paare
* hub4com öffnet und blockiert die angegebenen Ports.

Also müssen die Terminals sich mit den Gegenseiten der Port-Paare 
verbinden (blaue Pfeile).

Danke für Deine Hartnäckigkeit, STM32 und auch nochmal an Rufus.

SUT1 findet COM9 und es klappt nun auch mit den Terminals. :)

[STM32 (Gast)]

Torsten C. schrieb:
> * Die Port-Paare bleiben bestehen.
> * Man benötigt 3 Port-Paare
> * hub4com öffnet und blockiert die angegebenen Ports.

Genau. Stell Dir einfach vor, die Portpaare seien Kabel, die Du in einen 
Hub steckst. Intern routen tust Du mit dem Script.

Torsten C. schrieb:
> Danke für Deine Hartnäckigkeit, STM32

Keine Ursache. Hilf halt auch mal anderen ;-)

[Rufus Τ. F. (rufus)]

Torsten C. schrieb:
> auch nochmal an Rufus.

Danke; ich werd's vermutlich selbst demnächst brauchen und bin insofern 
schon mal froh darum, das Windows-10-Problem gelöst zu haben.

Reiner Eigennutz also ...

[Torsten C. (torsten_c)]

Es ist zum Mäuse melken. :-(

Mit Putty klappt es.
Will ich nun ein C#-Programm verbinden, dann geht es nicht.

Kann das damit zusammen hängen, dass weder am CN2A-RX noch am CN1A-RX 
(siehe Bild) ein RX angeschlossen ist?
Also daran, dass CN1B-TX und CN2B-TX ins 'leere' gehen?

System.IO.Ports.SerialPort.DataReceived() wird ausgelöst, aber
System.IO.Ports.SerialPort.BytesToRead ist immer == 0.

Auch System.IO.Ports.SerialPort.BaseStream.BeginRead() ruft nie den 
Delegaten auf.

Die Variante mit dem BeginRead()-Delegaten, die auch nicht auf 
empfangene Zeichen reagiert, habe ich von:
http://www.sparxeng.com/blog/software/must-use-net-system-io-ports-serialport

[STM32 (Gast)]

Ich hab mir das C#-Beispiel nicht angeguckt, aber auf Anhieb hätte ich 
die Handshakesignale im Verdacht....

[Torsten C. (torsten_c)]

SerialPort.Handshake steht auf "Handshake.None".
Schade, das kann also nicht die Ursache sein.

PS: Für --route=0:2 und --route=1:3 gibt es oben ja kein entsprechendes 
"--fc-route". Ich wüsste auch nicht, womit man den Flow-Control 
verbinden sollte.

Oder sollte ich für "--fc-route" vielleicht noch zwei weitere Port-Paare 
einrichten, wo dann z.B. Putty dran hängt? ?!

[STM32 (Gast)]

Schau Dir mal die Ruhezustände der Handshakeleitungen an. Putty ist da 
sehr robust, was das anbelangt. Es kann schon sein, daß unter DOTNET die 
Schniittstellensignale anders oder eben interpretiert werden.

[Torsten C. (torsten_c)]

STM32 schrieb im Beitrag #4736365:
> Schau Dir mal die Ruhezustände der Handshakeleitungen an.

Meinst Du die Properties im C# SerialPort?
Mach ich heute Nachmittag, aber wie bringt mich/uns das weiter?

Oder meinst Du noch eine andere Anzeige-Möglichkeit,
die ich nicht kenne?

[STM32 (Gast)]

Naja, ich meinte, daß, dadurch das der Ruhezustand nicht durchgeroutet 
wird, eventuell der Port eventuell aktive Handshakes sieht.

[Jürgen (Gast)]

Auch wenn der Thread schon älter ist noch eine kostenlose Alternative 
eines VSPE. Nachteil: Wird nur an lizenzierte Funkamateure abgegeben 
aber wer einen DV4mini nutzt (Hotspot für digitale Voicemodes auf VHF 
und UHF) hat eine solche Lizenz.

Einfach mal nach K5FR VSPM googeln. Auf der Seite wird man aufgefordert 
ihn mit angabe des Rufzeichens zu kontaktieren und er schickt dann eine 
Kopie per eMail.

Ich nutze die Software um meinen RedPitaya SDR auch über meine 
Logbuchsoftware per CAT steuern zu können. Dazu brauchte ich ein Comport 
Paar das die Software PowerSDR mit meinem Logger verbindet.

Gruß und 73´s ... Jürgen DF___