USB-Port im Netzwerk verfügbar machen

[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