VPN-Tunnel: Zugriff auf Drucker funktioniert nicht

[PeterPawn]

Schade - hat wirklich niemand eine Idee?

Mir fehlt im Moment die Zeit, um das selbst zu probieren ... ich könnte nur meinen Vorschlag erneuern, daß Du die Antwort-Pakete von Oma's Drucker fälschst und nicht die Broadcasts. Ob das am Ende hilft, weiß ich auch nicht ...

Alles andere muß ich selbst testen ... da hasse ich es einfach, nur zu raten.

 

[igel_igel]

Hi,

ich habe soeben auch die von PeterPawn präferierte Methode ausprobiert und die Druckerantwort gefaked - leider ohne Erfolg.
Hat noch irgendwer irgendeine Idee?

Viele Grüße und gute Nacht

igel_igel

 

[igel_igel]

Es gibt Neues zu berichten:

Auch im zweiten Anlauf hat das Faken der Pakete der Installationssoftware nur so weit funktioniert, dass Omas Drucker zwar auf die gefakten Pakete geantwortet hat, die Software diese Antwort aber scheinbar nicht akzeptiert (will sagen: kein Durchbruch).

Ich habe anschließend PeterPawns Ansatz verfolgt und zur Abwechslung einmal die Antwortpakete von Omas Drucker gefaked.
Auch dies wird von der Software nicht akzeptiert - der Pingpong zwischen Software und Drucker will einfach nicht weitergehen.

Daher beschleicht mich so langsam aber sicher das Gefühl, daß ich bei der Fake-Aktion irgendetwas falsch mache.
Es wäre supernett, wenn Ihr mir einmal über die Schulter schaut und per Wireshark einen Blick auf meine Paketchen werft.

Das Wireshark-File (im tcpdump-Format) mit einem Extrakt der relevanten Pakete findet Ihr hier:
https://www.drop box.com/s/5xycvhfr3yy5xao/ws.bjnp004failextract1.pcap?dl=0 (bitte Leerzeichen in URL vor der Verwendung entfernen)

Das File enthält nur 10 kleine UDP-Pakete, die auszuwerten sind - Ihr müßt Euch also nicht durch Tonnen von Material quälen, um die Nadel im Heuhaufen zu finden. Außerdem gibt's hier zum besseren Verständnis ein paar Erläuterungen zu den Paketen:

Frame 1-6 zeigt die Kommunikation in dem Fall, in dem ich die Pakete der Canon-Installationssoftware gefaket habe:

- Frame 1-2: Original-Such-Broadcast der Canon-Installationsroutine, die wegen der Boadcast-Adressierung die Netzwerkgrenze nicht überschreitet und daher niemals Omas Drucker erreicht
- Frame 3-4: Gefakte Such-Unicastpakete, die tatsächlich durch den VPN-Tunnel Omas Drucker erreichen, denn ...
- Frame 5-6: Omas Drucker antwortet auf die gefakten Pakete. Warum es an dieser Stelle nicht weitergeht (die Canon-Software wäre nun am Zuge), verstehe ich nicht.

Frame 7-10 zeigt den von PeterPawn präferierten Fall - es zeigt die Kommunikation, in welcher ich die Antwortpakete des Druckers fake:

- Frame 7-8: Original-Such-Broadcast der Canon-Installationsroutine, die wegen Boadcast die Netzwerkgrenze nicht überschreitet und daher niemals Omas Drucker erreicht
- Frame 9-10: Die von mir gefakten Antwort-Pakete, die Omas Drucker simulieren sollen ... Warum es an dieser Stelle nicht weitergeht, verstehe ich ebenfalls nicht.

Damit Ihr eine Vorstellung davon habt, wie die Kommunikation zwischen Software und Drucker eigentlich funktionieren sollte (also der "Gut-Fall"), findet Ihr im folgenden einen zweiten Wireshark-Mitschnitt. Darin ist dokumentiert, was passiert, wenn ich die Software für meinen eigenen Canon MX895 Drucker installiere (er steht im lokalen Netz und alles fluppt super):
https://www.dro pbox.com/s/q51oouuwmv9zxh0/ws.bjnp.mx985_workingextract1.pcap?dl=0

Nun bin ich einmal sehr gespannt, was Ihr dazu meint.

Viele Grüße

igel_igel


PS: im Nachgang habe ich die Dropbox-Dateien hier auch als *.zip-Dateien an mein Posting angehängt.

 

[igel_igel]

Ich bin einen guten Schritt weiter:

Nachdem ich keine Idee mehr hatte, welchen Fehler ich beim Faken der Pakete gemacht haben könnte, kam mir der Gedanke, daß Canon tatsächlich seine Software so geschrieben haben könnte, dass diese nur auf "lokale" IP-Pakete reagiert (warum auch immer). Wobei ich hier unter "lokalen IP-Paketen", Pakete aus demjenigen Netzwerksegment verstehe, in dem sich auch die Installationssoftware befindet.

Die Sache war schnell untersucht:
Diesmal habe ich zwar wiederum der Antwortpakete von Omas Drucker gefaked, aber als Absenderadresse eine Adresse aus meinem lokalen Netz genommen.

Ergebnis:
Erstmals reagiert die Software auf diese Pakete und sendete das nächste BJNP-Handshake-Paket an den "gefakten" Drucker.

Vorläufige Erkenntnis:
Zumindest die Installationssoftware wird niemals mit einem Drucker kommunizieren, der nicht im eigenen Netzwerk steht - selbst wenn man sie per gefakten Paketen mit der Nase darauf stößt, wo der Drucker tatsächlich steht - sie baut partout keine Verbindung zu entfernten Druckern auf.

Erste (noch etwas unausgegorene) Lösungsidee:
Schaut also fast so aus, als müßte ich mir einen lokalen "Druckerproxy" in mein eigenes Netz hängen, der alle Pakete an Omas Drucker weiterleitet.

Wer bessere Ideen hat, der möchte sich bitte melden!
Und wer eine gute Windows-Software für diesen Zweck kennt, der möchte mir bitte ebenfalls einen Tipp geben.

Jedenfalls freue ich mich, daß ich endlich einen (Erkenntnis)schritt weitergekommen bin.

Viele Grüße

igel_igel

 

[PeterPawn]

Erste (noch etwas unausgegorene) Lösungsidee:
Schaut also fast so aus, als müßte ich mir einen lokalen "Druckerproxy" in mein eigenes Netz hängen, der alle Pakete an Omas Drucker weiterleitet.

Diesen Proxy könntest Du - zumindest versuchsweise - selbst bauen mit "nc" und ggf. einem SSH-Tunnel o.ä. (wenn Du ohnehin schon ein VPN hast, reicht auch ein "normaler" nc-Tunnel), so wie ich es in dem Edit zu #15 schon mal überlegt hatte.

Wie man über SSH-Tunnel auch UDP-Verkehr an einen anderen Standort bekommt, steht in vielen Tipps im Internet ... wenn Du am Ende eine Konstruktion wie:

nc auf UDP-Port (inkl. BC) <-> nc/ssh als "Transport" zur entfernten Site <-> weiterer nc als UPD-Instanz

hast, sollten die Pakete von der letzten nc-Instanz ja mit einer lokalen IP im Netz vagabundieren.

Ein Problem könnte sich allerdings ergeben, wenn der eigentliche Paket-Inhalt auch noch einmal eine IP-Adresse enthält und diese nicht nur aus dem IP-Header entnommen wird von der Canon-Software.

 

[igel_igel]

Sämtlicher Dank und alle Blumen gehen wieder einmal an PeterPawn für seine guten Ideen.

Nachdem ich nun endlich herausgefunden habe, daß "BB" nicht für "barbecue" sondern für "BusyBox" steht, konnte ich mich erfolgreich weiterhangeln und habe erstaunliche Dinge über meinen roten Kasten im Keller gelesen.

Was das Thema "nc" angeht, so muß ich da wohl erst einmal ein paar Trockenübungen machen.
Auch bin ich nicht ganz sicher, ob ich mnc - Binaries für die Fritzbox bekomme (oder hat die Box auch noch einen Compiler an Bord?).

Wie dem auch sei - ich melde mich, wenn ich weitergekommen bin.

Gruß

igel_igel

 

[sulihari]

@igel_igel

Warum installierst Du nicht einfach den mit Windows gelieferten Treiber der MX 700er serie auf LPT1? Danach kann man den IP Port hinzufuegen.

MfG
sulihari

 

[schnurgly]

Wie wäre es mit Teamviewer? Aber dazu müsste Omas Rechner auch laufen.
Eine andere Möglichkeit: den Drucker per USB-Fernamschluss anschließen und dann per VPN einbinden. Dann hätte man über die FB-IP einen "Netzwerkdrucker". Noch ein Gedanke: Wenn der Drucker über AirPrint eine IP von der FB bekommt, könnte man ihn doch über das IPP-Protokoll und Portforwarding (9100) erreichen.
Oder Oma einen USB-Stick für den Drucker schicken.

 

[igel_igel]

Wow - kaum vergibt man "Blumen", schon melden sich auch andere Helfer zu Wort - nett von Euch!

> Warum installierst Du nicht einfach den mit Windows gelieferten Treiber der MX 700er serie auf LPT1? Danach kann man den IP Port hinzufuegen.

Das werde ich sofort probieren und dann hier wieder berichten. Wenn das funktioniert, so beiße ich Muster in die Tischkante.
(Trotzdem werden obige Netzwerk-Fingerübungen nicht umsonst sein, denn im nächsten Schritt muß ich Omas WLAN-Kamera (IXUS 140) remote auslesen)

> Wie wäre es mit Teamviewer? Aber dazu müsste Omas Rechner auch laufen.

Teamviewer ist keine Option - Oma hat bislang nur die Fritzbox und den Drucker plus besagte IXUS 140 Kamera.
Leider stehen Router und Drucker Platzbedingt ca. 20m auseinander, weshalb ich den Drucker nicht per USB an die FB anbinden kann (danke trotzdem für den Hinweis!)

> Eine andere Möglichkeit: den Drucker per USB-Fernamschluss anschließen und dann per VPN einbinden. Dann hätte man über
> die FB-IP einen "Netzwerkdrucker". Noch ein Gedanke: Wenn der Drucker über AirPrint eine IP von der FB bekommt, könnte
> man ihn doch über das IPP-Protokoll und Portforwarding (9100) erreichen.

Aha - auch das hört sich auch interessant an.
Allerdings soll Omas Drucker nicht nur drucken, sondern vor allem auch scannen können, damit ich Oma bei Korrespondenzen
mit Behörden/Versicherungen & Co unterstützen kann. Bislang liest sie mir die Briefe immer vor ...
Laßt Euch mal einen Steuerbescheid vorlesen und entscheidet dann, ob da Fehler enthalten sind - das ist vielleicht eine Freude ...

Also: frisch ans Werk - Ihr hört von mir - gleiche Stelle, gleiche Welle ....

Viele Grüße

igel_igel

 

[igel_igel]

@sulihari:

> Warum installierst Du nicht einfach den mit Windows gelieferten Treiber der MX 700er serie auf LPT1? Danach kann man den IP Port hinzufuegen.

Treiber auf LPT1 installieren hat ja noch funktioniert, aber wie füge ich dann den IP Port fachgerecht hinzu?

Meine Schritte:

- Drucker nicht als WLAN oder Netzwerkdrucker, sondern als USB-Drucker installieren (klappt natürlich nicht)
- Installationsprogramm abbrechen und dort beim Abbruch das Häkchen bei "Druckeranschluß auswählen" setzen. Weiter mit "Manuelle Wahl"
- LPT1 wählen und Installation beenden

Soweit, so gut.

- sodann wähle ich in der Systemsteuerung (ich habe Win7 x64) den Drucker aus
- unter Druckereigenschaften > Anschlüsse kann ich dann einen neuen Anschluß anlegen

Und genau hier gehe ich verloren:
- Den Anschlußtyp "Canon BJNP"-Port kann ich leider nicht auswählen - gibt Fehlermeldung
- Und den Anschlußtyp "Standard TCP/IP-Port" kann ich zwar auswählen und mit Omas Drucker-IP konfigurieren,
aber dann findet die TCP/IP-Porterkennung den Drucker trotzdem nicht und quittiert mit "Das Gerät wurde im Netzwerk nicht ermittelt".

Tja - und Drucken funktioniert dann auch nicht.

Will sagen: wenn Du mir noch ein paar Tipps und Hinweise in diese Richtung geben könntest, so würde ich mich darüber sehr freuen.
Ich denke die ganze Zeit schon, daß ich irgendetwas gaaaaanz Triviales übersehen haben muß.

Viele Grüße

igel_igel

 

[igel_igel]

Oh halt - ich habe nicht genau genug gelesen: ich soll den mit Windows MITGELIEFERTEN Treiber installieren und testen ...
Sorry - das werde ich nachher nochmals ausprobieren.
Muss jetzt erst einmal ein Stündchen was anderes machen.

Ciao und bis denne

igel_igel

 

[igel_igel]

Das ging schneller als gedacht ...
Allein: das Problem ist dasselbe - also genau wie in Posting #30 geschildert.
Ich bin dann mal ein Weilchen weg ...

 

[schnurgly]

Nimm trotzdem Teamviewer. Dann kannste über Omas Rechner das Multigerät am besten bedienen und hast keine Einschränkungen. Und falls Oma ein PC-Problem hat, kannst Du ihr auch helfen.

 

[sulihari]

Die Hersteller Installationen sind teilweise recht eigenwillig. Mit Windows Treibern die durch die MS Zertifizierung gelaufen sind, sollte das aber funktionieren. Es ist dann aber nur ein Drucker und kein Scanner verfuegbar.

 

[PeterPawn]

@schnurgly:

Nimm trotzdem Teamviewer. Dann kannste über Omas Rechner das Multigerät am besten bedienen und hast keine Einschränkungen. Und falls Oma ein PC-Problem hat, kannst Du ihr auch helfen.

Teamviewer ist keine Option - Oma hat bislang nur die Fritzbox und den Drucker plus besagte IXUS 140 Kamera.

Oma's einziges PC-Problem ist es ja offenbar, daß sie keinen hat ... hältst Du es nicht auch für etwas übertrieben, ihr extra deshalb einen hinzustellen, damit dieses Manko ausgeglichen ist ?

Auch das klingt interessant:

Eine andere Möglichkeit: den Drucker per USB-Fernamschluss anschließen und dann per VPN einbinden.

Aber erlaubt der USB-Fernanschluß-Client von AVM inzwischen wirklich die Auswahl des Gerätes (ich habe den schon lange nicht mehr getestet), wenn das nicht über UPnP gefunden werden kann ? Ich hatte früher mit diesem Programm schon Probleme, wenn es nur darum ging, bei mehreren "sichtbaren" FRITZ!Boxen die richtige auszuwählen und nicht die, die als erste auf den "M-SEARCH"-Request geantwortet hat.

 

[igel_igel]

PeterPawn hat meine Antwort an Schnurgly sehr charmant vorweggenommen - genau so ist es.

Und mit Suliharis Vorschlag habe ich bislang ebenfalls Schiffbruch erlitten (was natürlich auch sehr gut an Kaptain "igel_igel" liegen kann).
By the way: ich sehe dann immer SNMP-Requests in Richtung Oma-Drucker huschen, die von Omas Drucker mit einem ICMP "Destination unreachable (Port unreachable)" beantwortet werden.
Draus kann ich mir keinen rechten Reim machen (wie gesagt: der Drucker ist per Ping erreichbar).

Und da letztendlich die Scannfunktion mindestens genauso wichtig ist wie die Druckfunktion, werde ich mich wohl notgedrungen wieder in das Netz-Twiggle-Twiggle-Hin-Und-Her-Routing-Problem stürzen müssen.
Oh weh ...

 

[PeterPawn]

Draus kann ich mir keinen rechten Reim machen (wie gesagt: der Drucker ist per Ping erreichbar).

Deshalb steht dort "Port unreachable". Windows versucht unter anderem, den Drucker durch eine SNMP-Abfrage (das ist ein Management-Protokoll für Netzwerk-Geräte) zu identifizieren. Wenn da auf dem Gerät aber kein Dienst auf dem SNMP-Port aktiv ist (das ist UDP 161), dann kommt es zu dieser Antwort seitens des Netzwerk-Stacks in Drucker. Das ist immer noch "höflicher", als einfach gar nicht zu antworten, da dann erst eine definierte Zeitspanne vergehen müßte (Timeout), bis der Sender feststellen kann, das er da offenbar vor verschlossenen Toren steht. Mit etwas Pech wird ohne die negative Antwort die Anfrage sogar noch einige Male wiederholt, da es bei UDP (außer der Antwort) keine Information gibt, ob eine Anfrage ihr Ziel erreicht hat und nicht vielleicht schon unterwegs irgendwo verloren gegangen ist.

Noch etwas zur UDP-Weiterleitung per 'nc' ... da braucht man - die Einschränkung, daß die Pakete keine Adressen in der Nutzlast enthalten dürfen, habe ich ja schon erwähnt - eigentlich keine weiteren Kenntnisse zum Netzwerk. Entscheidend ist es, daß die erste Instanz die "Nutzlast" des Broadcast-Paketes aus dem per UDP empfangenen Paket nimmt und über eine Pipe (notfalls nachlesen) an ein anderes Programm weiterleiten kann. Wenn dieses Programm dann seinerseits diese Daten nimmt und über die VPN-Verbindung zur anderen FRITZ!Box weiterleitet, dann wartet dort wieder eine entsprechende Instanz, die diese Daten (diesmal eben über TCP getunnelt von der ersten FRITZ!Box) wieder nimmt und über stdout per Pipe an eine weitere nc-Instanz weiterleitet, die diese Daten dann wieder von ihrer stdin entgegennimmt und per UDP ins Netz entläßt. Das wäre die Theorie ...

Ich würde sogar mal einen Blick in Deinen Packetdump riskieren und dabei versuchen zu ergründen, ob BJNP wirklich keine IP-Adressen in den Nutzdaten eines Paketes durch die Gegend schickt. Aber ich habe auch strenge Prinzipien, was den Zugriff auf Dropbox und andere Cloud-Dienste angeht, erst recht bei fremden Konten und wenn da zehnmal eine Freigabe extra dafür eingerichtet wurde. Warum hängst Du die relevanten Daten nicht einfach in einem passenden Archiv-Format (zip/7z sind sicherlich gängig genug) an einen Beitrag an ? Dann stehen diese Daten auch dann noch zur Verfügung, wenn Du sie mal auf Deinem Dropbox-Account löschen mußt oder (keine Ahnung, ob das so überhaupt läuft) die Freigabe bei Dropbox irgendwann mal ausläuft. Wenn Du vorsätzlich löschen willst, ist das per "Bearbeiten" auch hier jederzeit möglich.

 

[schnurgly]

Sorry, habe nicht genau gelesen, das Oma keinen PC hat. Ich habe die die Bedienungsanleitung des Druckers überflogen und festgestellt, das es wirklich kein echter Netzwerkdrucker ist. Somit wird es schwer, diesen hinter der Fritzbox zu steuern zumal auch die FB keinen echten Printserver zur Verfügung hat. So war mein Gedanke über den USB-Fernanschluss eine Drucker-IP zu bekommen. Leider kann das Multigerät nur über die Mac-Adresse angesprochen werden. Ein Versuch über den Bonjourdienst könnte man noch testen (gibt es auch für Windows) Da muss man wohl auch entsprechende Ports öffnen.
Aber wahrscheinlich braucht Oma für den vollen Funktionsumfang doch einen PC. Oder einen richtigen Netzwerkdrucker, was natürlich eine Preisfrage ist. Oder doch mal öfters bei Oma vorbeischauen

 

[igel_igel]

@PeterPawn:

Danke für die Erläuterungen zu SNMP - ich hatte es schon geahnt - aber Wissen ist natürlich viel besser als ahnen ...
Die UDP-Weiterleitungsgeschichte hoffe ich morgen mit klarem Kopf angehen zu können (wenn das mal was gibt, nach der Vollmondnacht ...)

Was die Wireshark-Mitschnitte angeht, so würde ich die ja gerne hier an meine Beiträge anhängen, aber ich hatte auf die
schnelle keinen Knopp gef.... ahhhhh - da ist er ja: unter "Erweitert" - das war wohl bislang zu hoch für mich ...

Ich versuche sogleich die Wireshark-Mitschnitte noch an meine Beiträge dranzuhängen ... (hast' ja recht mit Deiner (konstruktiven) Kritik - sehe ich genauso).

Tick, tack, tick, tack ...

So - ist erledigt.

@Schnurgly:

Jawohl - AirPrint funktioniert definitiv auch mit dem Drucker (ich hatte den Drucker extra mit diesem Kriterium ausgesucht, weil Oma ggf. noch ein iPad-Mini bekommen soll).
Wenn ich die Netz-Verdreherei nicht hinbekomme, muß AirPrint evtl. der rettende Hafen werden (wenn das mal über die Netzwerkgrenzen hinweg geht).
Weißt Du zufällig, ob man mit diesem Bonjour-Dienst auch den Scanner ablesen/absaugen/ansprechen könnte?
Oder geht damit nur drucken?

Gruß und gut's Nächtle

igel_igel

 

[igel_igel]

Hallo Nachtschwärmer,

also: ich bin nun stolzer Besitzer eines debian-Linux, welches innerhalb einer VMware (= virtuelle Maschine) läuft.
Diese VMware läuft im Bridge-Modus und verpaßt der Netzwerkkarte meines Laptops eine zweite IP.
Ich erhoffe mir, so etwas mehr "Spielwiese" zur Verfügung zu haben.

Netcat habe ich inzwischen auch schon vorwärts & rückwärts ausprobiert (allerdings noch nicht anwendungsbezogen).
Will sagen: ich nähere mich langsam meinem Zwischenziel, die Pakete der Canon-Software via netcat in Omas Netz zu
befördern.

Allerdings befürchte ich, daß ich gleich eine Mütze Schlaf benötige und daher für heute keine bahnbrechenden Erkenntnisse
mehr kommen werden.

Alle treuen Helfer können also heute durchatmen und Kräfte sammeln für morgen oder übermorgen ...

Gut's Nächtli

igel_igel