USB-Port im Netzwerk verfügbar machen

[Helmi]

Hallo,

ich habe an einem Rechner einen Dongle am USB stecken, den ich für eine Software benötige.
Auf einem anderen Rechner hab ich die selbe Software am Laufen, nur ohne Dongle, was diese Software in einen Demomode schaltet.

Meine Frage:
Ist es möglich den USB-Port des Rechners mit dem gesteckten Dongle im Netzwerk, dem anderen Rechner zur Verfügung zu stellen?
So dass der zweite Rechner übers Netzwerk auf den USB-Port des ersten Rechners zugreift und so auf den Dongle.

Die Idee dahinter: Der Dongle bleibt an einem Rechner gesteckt, aber beide Rechner können uneingeschränkt an der Software arbeiten.

[Bummi]

Mhhhhh, es gibt schon Netzwerkdongles, aber ob der Hersteller der Software welche Du einsetzt dies so angedacht hat, klingt erst mal unseriös...

[Helmi]

wenn ich richtig nachdenk klingt mein Vorhaben schon etwas unseriös..

[rollstuhlfahrer]

Selbst bei Netzwerklösungen (also 1 USB-Port fürs LAN) gibt es Einschränkungen. So kann immer nur einer gleichzeitig auf die USB-Buchse zugreifen. Die USB-Spezifikationen sollten das auch nicht zulassen.
Stell dir mal vor, du bist nach deinem Kenntnisstand im Gespräch mit einer anderen Person. Plötzlich platzt eine zweite in das Gespräch hinein und verlangt von dir, dass du sie gleichberechtigt zur ersten behandelst, du aber nur eine Person abarbeiten kannst.


Bernhard

[BUG]

Mir ist so, als hätte ich sowas wie USB über Netzwerk schon mal als (Kurz-)Test in der c't gesehen, das wurde auch für Dongles beworben. Der USB-Port ist dabei nur mit einem Computer "verbunden". Die Buchsen waren, soweit ich mich erinnere, aber eine extra Hardware.

Kann aber auch sein, dass ich mich täusche ...

EDIT: gefunden: Dongleserver

[rollstuhlfahrer]

Es bleibt aber dabei: 1 USB-Gerät immer nur an einem Rechner gleichzeitig.

Bernhard

[BUG]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1073353)

Es bleibt aber dabei: 1 USB-Gerät immer nur an einem Rechner gleichzeitig

Jup, das meinte ich mit: mit einem Computer "verbunden". Hab mich etwas unklar ausgedrückt.

Ist halt die Frage, was er möchte:
Die Software gleichzeitig auf 2 Rechnern mit 1 Dongle betreiben -> höchstwahrscheinlich illegal plus technisch kaum umsetzbar.
Die Software abwechselt auf 2 Rechner betreiben, ohne den Dongle physisch umstecken zu müssen -> könnte legal sein plus umsetzbar.

[Assarbad]

Zitat:

Zitat von Helmi (Beitrag 1073324)

Die Idee dahinter: Der Dongle bleibt an einem Rechner gesteckt, aber beide Rechner können uneingeschränkt an der Software arbeiten.

Neben den lizenzrechtlichen Bedenken, dürfte es da protokolltechnisch ein paar Hürden geben, obwohl ich bei USB-Treibern zugegebenermaßen nicht so fit bin wie bei anderen Themen. Aber ich frag mal nach, wenn ich es nicht vergesse. Kenne da jemanden bei Sony Ericsson in Schweden, der sich super mit USB-Treibern auskennt.

[hathor]

Ich gehe davon aus, dass eine dongle-geschützte Software für Einzelplatzrechner
über das Timing leicht erkennen kann, ob der Dongle "hardwarenah" vorhanden ist.

[Morphie]

Ich würde das ganze eher über einen Terminal-Server oder so lösen... Bzw. den Rechner, der den Dongle hat als Terminal Server benutzen. (RDP aktivieren)
So hat man eben die gleichen Voraussetzungen auf "beiden" PCs.

[Helmi]

Hallo,

Danke für die Antworten!

Es geht nur darum, dass ich abwechselnd einmal auf den einem und einmal auf dem anderen Rechner arbeiten möchte, ohne den Dongle jedesmal mitnehmen zu müssen. Ich nehme an dass es rechtlich kein Problem darstellt, da ja niemand anders daran arbeitet und ich das nur für mich brauche.

@BUG:
Ich werd mir mal den Link anschauen. Danke dafür

[Uwe Raabe]

Eine Software-Lösung findest du hier.

Bleibt natürlich immer die Frage, ob die Software, die den Dongle abfrägt, auch damit funktioniert. Aber dafür gibt es ja eine Trial-Version.

[mkinzler]

Mehrere Rechner können dann aber höchstwahrscheinlich auch nicht parallel verwendet werden.

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1073415)

Mehrere Rechner können dann aber höchstwahrscheinlich auch nicht parallel verwendet werden.

Das ist ja auch lizenzrechtlich nicht erlaubt! Sollte ein Zugriff über das Netzwerk erlaubt sein, liefert der Hersteller meistens auch die nötige Software mit, den Dongle anderen Rechnern zur Verfügung zu stellen.

Die Softwarelösung hat m.E. aber den Vorteil, daß man per Trial ausprobieren kann, ob die Software den Dongle über das Netzwerk überhaupt akzeptiert. Ich vermute auch, diese Lösung könnte etwas billiger sein, als die Hardware-Variante.

[Helmi]

Zitat:

Zitat von Uwe Raabe (Beitrag 1073385)

Eine Software-Lösung findest du hier.

Bleibt natürlich immer die Frage, ob die Software, die den Dongle abfrägt, auch damit funktioniert. Aber dafür gibt es ja eine Trial-Version.

Ich habe die Softwarelösung ausprobiert - leider ohne Erfolg.
Das schlimme war eigentlich auch, dass mein Dongle dann gar nicht mehr erkannt wurde, auch nicht am reel steckenden Platz.

Ich bleib lieber dabei dass ich den Dongle in der Hosentasche von Rechner zu Rechner trage.

[Assarbad]

Zitat:

Zitat von Helmi (Beitrag 1073469)

Ich bleib lieber dabei dass ich den Dongle in der Hosentasche von Rechner zu Rechner trage.

Falls es ein Trost ist, USB-Dongles sind üblicherweise deutlich robuster als ihre LPT-Vorfahren. ;)

(letztere waren bei häufigem An- und Abstecken weitaus gefährdeter)

[Helmi]

Zitat:

Zitat von Assarbad (Beitrag 1073470)

Falls es ein Trost ist, USB-Dongles sind üblicherweise deutlich robuster als ihre LPT-Vorfahren. ;)

Danke für den Trost ;-)

[sx2008]

Eigentlich ein "Skandal", dass Windows es nicht von Hause aus zulässt serielle, parallele und USB-Schnittstellen über das Netzwerk freizugeben.
Bei Druckern und Verzeichnissen ist es doch auch möglich.
Das gehört eigentlich zur Kernkompetenz eines Betriebssystems (virtuelle Treiber, Umleiten von Treiberdaten).

[Assarbad]

Zitat:

Zitat von sx2008 (Beitrag 1073507)

Eigentlich ein "Skandal", dass Windows es nicht von Hause aus zulässt serielle, parallele und USB-Schnittstellen über das Netzwerk freizugeben.
Bei Druckern und Verzeichnissen ist es doch auch möglich.
Das gehört eigentlich zur Kernkompetenz eines Betriebssystems (virtuelle Treiber, Umleiten von Treiberdaten).

Unmotiviertes Windows-Bashing? Cool! Aber vielleicht klärst du uns noch schnell auf warum die anderen Betriebssysteme (Linux, BSDs, MacOS X) das nicht bringen ... ist ja schließlich eine Kernkompetenz :zwinker:

[messie]

Mal dumm nachgefragt: wie greift man denn auf USB-Dongles zu? Ist das auch ein Dateizugriff, wie bei seriellen Ports?

Ich habe einen neuen Router bekommen (die Geschichte dazu erzähle ich später weiter), der bietet einen USB-Port mit verschiedenen Serverfunktionen. Vielleicht kann man damit etwas drehen.

Grüße, Messie

[Assarbad]

Zitat:

Zitat von messie (Beitrag 1073511)

Mal dumm nachgefragt: wie greift man denn auf USB-Dongles zu? Ist das auch ein Dateizugriff, wie bei seriellen Ports?

Jain. Auch bei anderen ist es kein "Dateizugriff". Ähnlich wie bei unixoiden Systemen werden aber die gleichen Funktionen benutzt, wobei DeviceIoControl (und Freunde) auf Windows in unixoiden Systemen ihre Entsprechung in ioctl() finden.

Ich versuch's mal zu umreissen und den Zusammenhang darzustellen.

Wenn du meinst, daß du auf C:\Windows\System32\kernel32.dll zugreifst, greifst du eigentlich auf das Gerät zu welches in den DOS-Namensraum als C: eingeblendet wurde. Der echte Name ist meistens \Device\HarddiskVolumeX (wobei X üblicherweise eine Ziffer ist). "\" bezieht sich hier auf den echten Namensraum in NT-Systemen. Dort sind alle möglichen Objekte aufzufinden, inklusive der Registry. Ich empfehle das Tool WinObj von Sysinternals.

Du greifst also auf das Gerät \Device\HarddiskVolumeX zu, wobei der Name eben einem "Device Object" (DO) gehört und man zwischen PDOs (Physical Device Objects) und CDOs (Control Device Objects) unterscheidet (es gibt auch noch VDOs, wobei die Abgrenzung zu CDOs eher künstlich ist).

Kleiner Ausflug: wenn man einen Treiber, egal welcher Coleur, schreibt gibt es meist auch ein CDO, ein PDO muß es aber nicht geben. Bspw. ein Dateisystemfiltertreiber (FSFD) welcher sich bspw. an das oben genannte Gerät hängt. Dieser Filtertreiber hat aus praktischen Gründen üblicherweise ein CDO (beliebiger Name) über welches man per CreateFile, DeviceIoControl und CloseFile zugreifen kann (wir bleiben mal nur beim Win32-Subsystem).

Da das Gerät aber C: ist, bliebe die Frage wie du an die Daten von kernel32.dll kommst?! Nunja, der I/O Manager sieht einen Pfad und eine Anfrage an diesen Pfad hier sowas wie \??\C:\Windows\System32\kernel32.dll ...

Das löst er mit dem Object Manager erstmal auf, so daß wir bei dem Pfad \Device\HarddiskVolumeX\Windows\System32\kernel32. dll landen (so sehen bspw. Filtertreiber den Pfad auch üblicherweise). Da der I/O Manager aber ab \Device\HarddiskVolumeX\ nicht mehr weiter weiß, übergibt er an das Gerät \Device\HarddiskVolumeX den Pfad \Windows\System32\kernel32.dll, wobei der zuständige Treiber (üblicherweise ein Dateisystemtreiber) dann dafür zuständig ist diesen Pfad zu interpretieren und so weiter ...

Bei Netzlaufwerken gehen alle Anfragen üblicherweise durch ein einzelnes Gerät, also nichtmal nach Laufwerk getrennt wie man das von Festplatten kennt.

Bei COM und LPT ist es nun so, daß die Geräte bereitstehen, weil schon ein Treiber existiert der die PDOs erzeugt. Und zwar stehen sie unter echtem Namen bereit, als auch im DOS-Namensraum. Und aufgrund des letzteren kannst du über eine symbolische Verknüpfung (nicht mit dem gleichnamigen Konzept in Dateisystemen verwechseln!) aus dem Win32-Subsystem darauf zugreifen.

Prinzipbedingt geht das mit allerlei Geräten, denn die Grundfunktionen lesen und schreiben sowie einige andere finden sich bei allen Geräten wieder, egal ob wirklich implementiert oder mit Standardbehandlungsroutine versehen. Siehe:

• IRP_MJ_CREATE
• IRP_MJ_CLOSE
• IRP_MJ_READ
• IRP_MJ_WRITE

... ich empfehle einen Blick ins WDK. Die üblichen Funktionen haben IRP_MJ_* als Namen (MJ == major). Bei weiteren Fragen können wir ja einen Mod bitten das hier abzutrennen.

Zitat:

Zitat von messie (Beitrag 1073511)

Ich habe einen neuen Router bekommen (die Geschichte dazu erzähle ich später weiter), der bietet einen USB-Port mit verschiedenen Serverfunktionen. Vielleicht kann man damit etwas drehen.

Läuft der Router auf Windows?

[mkinzler]

Zitat:

dass Windows es nicht von Hause aus zulässt serielle, parallele und USB-Schnittstellen über das Netzwerk freizugeben.
Bei Druckern und Verzeichnissen ist es doch auch möglich.

So grunsätzlich nicht geht es ja auch nicht. RDP-Sitzungen können ja teilweise auf lokale Ports zugreifen

[sx2008]

Zitat:

Zitat von Assarbad (Beitrag 1073509)

Unmotiviertes Windows-Bashing? Cool!

Gegenfrage: wenn sich ein Drucker ganz einfach freigeben lässt, warum geht das nicht mit anderen Geräten bzw. Schnittstellen?
Ein Terminalserver kann z.B. die serielle & paralle Schnittstelle des Clients benützen.
Man kann sogar Plug&Play-Geräte (also USB) umleiten.
Das heisst also die Technik des Umleitens ist da.
Die Idee auch andere Schnittstellen ausser Drucker freigeben zu können muss bei Microsoft schon vor vielen Jahren vorhanden gewesen sein.
Das meinte ich mit "Skandal"; vorhandene Softwaretechnik, die wirklich Sinn machen würde wird nicht zur Verfügung gestellt.

[Assarbad]

Zitat:

Zitat von sx2008 (Beitrag 1073520)

Gegenfrage: wenn sich ein Drucker ganz einfach freigeben lässt, warum geht das nicht mit anderen Geräten bzw. Schnittstellen?

Weil sich jede der Schnittstellen unterscheidet, sowohl von Latenzzeiten die im Protokoll erlaubt sind als auch bzgl. anderer Merkmale. Der Drucker den du scheinbar freigibst, ist deswegen nicht als Gerät freigegeben. Will heißen, auch wenn du vom Client aus Druckjobs senden kannst, hängt deswegen nicht an der einen Seite das Gerät wirklich dran, weil das nämlich schon oft genug deswegen nicht ginge, weil lt. Protokoll nur ein Rechner auf das Gerät zugreifen kann (hier der Druckserver).

Vielmehr wird der Client in die Lage versetzt einen für den freigegebenen Drucker verständlichen (Postscript, PCL ...) Job an den Druckerserver zu schicken, welcher dann die eigentliche Kommunikation auf der Ebene vornimmt auf der du deine Argumentation anbringst.

Falls du nicht ganz verstehst was ich meine, stell dir jetzt einen LPT-Dongle vor, der übers Netz freigegeben wird. Müßte ja deiner Argumentation nach gehen, da die Technologie vorhanden ist. Aber es handelt sich um eine andere Geräteklasse und die Lösungen die ich kenne waren alle bisher immer spezifisch auf eine Geräteklasse zugeschnitten.

Zitat:

Zitat von sx2008 (Beitrag 1073520)

Ein Terminalserver kann z.B. die serielle & paralle Schnittstelle des Clients benützen.

Was sind die höchsten Datenraten für einen LPT- oder COM-Port? Und jetzt frag dich nochmal warum eSATA noch nicht übers Netzwerk existiert. Es ist einfach nicht sinnvoll, obwohl bei sowas wie USB sicherlich "Lizenzpolitik" auch eine Rolle spielen wird.

Zitat:

Zitat von sx2008 (Beitrag 1073520)

Man kann sogar Plug&Play-Geräte (also USB) umleiten.

Scanner, Kameras? Das muß recht neu sein, war mir nicht bewußt. Einerlei, rein vom Treibermodell her und so weiter, müßte sich das alles je nach Geräteklasse nochmal unterscheiden. Sprich: nur weil ein USB-Drucker geht, muß die USB-Kamera noch lange nicht gehen ...

Zitat:

Zitat von sx2008 (Beitrag 1073520)

Das heisst also die Technik des Umleitens ist da.

... eingeschränkt da, ja.

[hathor]

Anmerkungen:

LPT-Dongle: ich hatte mal einen LPT-Dongle, der enthielt einen 50kHz-Generator, der nur über direkten Anschluss funktionierte.

Scanner über Netzwerk funktionieren:
Ich habe einen USB-Hub mit WLAN(MEDION USB-Hub (E89030, MD 86097)), an dem eine HDD, ein Scanner und ein Netzwerkdrucker über USB angeschlossen sind - und alles wird von meinen Notebooks genutzt über WLAN.

[Assarbad]

Zitat:

Zitat von hathor (Beitrag 1073528)

Scanner über Netzwerk funktionieren:
Ich habe einen USB-Hub mit WLAN(MEDION USB-Hub (E89030, MD 86097)), an dem eine HDD, ein Scanner und ein Netzwerkdrucker über USB angeschlossen sind - und alles wird von meinen Notebooks genutzt über WLAN.

Interessant. Da würden mich glatt die Interna interessieren ...

Kannst du zufälligerweise herausbekommen wie das Ding bei Massenspeichern kommuniziert? Mich würde nämlich wundern wenn da nicht ein kleiner Sambaserver werkelt ... aber man weiß halt nie :)

[hathor]

http://www.acer-userforum.de/hardwar...d-86097-a.html

Die Software steckt im Client-Programm MD 86097 W-LAN USB Remote Hub.
Es listet angeschlossene Geräte auf, die dann über eine Checkbox aktiviert werden können.
Es kann immer nur ein Computer zugreifen.
Wenn ich die HDD brauche, aktiviere ich nur die HDD, der Drucker oder Scanner kann dann von einem anderen User genutzt werden.
Es ist ein LINUX-System im WLAN-HUB (Open Source).

[Assarbad]

Ich danke dir für die Info! :thumb:

[hathor]

Die Dokumentation (nur TXT-Files, mit Wordpad öffnen) des LINUX-BS ist gezipped über 2MB.

Hochladen geht zu Zeit nicht, obwohl 5MB erlaubt sind. Versuche es später/morgen noch einmal, falls Interesse besteht...

[Reinhard Kern]

Hallo,

mal zurück zum USB-Dongle: wenn es sich um eine seriöse Lösung handeln soll, bekommt man von den meisten Herstellern teurer Programme alternativ eine "Floating License". Der Dongle befindet sich an einem Server, auf dem eine Lizenz-Verteil-Software als Service läuft, und die Clients im Netzwerk können (über normale Netzwerkfunktionen) eine Lizenz anfordern. Hat man z.B. 3 Lizenzen und 5 Clients, so kann an allen Clients gearbeitet werden, aber nur an 3 gleichzeitig. Das ist so ungefähr die fairste Form der Verdongelung. Nebenbei spielt es dabei auch garkeine Rolle, ob der Dongle über USB oder sonstwie angeschlossen ist. Nicht alle, aber die meisten liefern eine Floating License auch als Einzellizenz.

Gruss Reinhard

[muenster]

Hallo,

genau die gleichen Probleme gibt es bei der Virtualisierung von Servern. Auch wenn der lokale USB Port durchgeleitet wird gibt es Dongles, die dann nicht mehr erwartungsgemäß arbeiten. Es lohnt sich also parallel nach USB und Virtualisierung zu suchen. Habe den SEH USB Server im Einsatz, mit einem Dongle gehts, mit dem Anderen nicht. Der Hersteller sagt, das er es wüsste und dafür eine Lösung hat (kostenfrei, sehr löblich). Vllt. erst mal schauen, ob der Dongle überhaupt für den Einsatz am USB Server geeignet ist.

Viele Grüße