foren24.at

Hallo,

habe einen Brother HL-5250DN per Kabel an meinem Router hängen und der
Drucker hat per DHCP eine feste IP zugewiesen bekommen. Der Drucker ist
permanent eingeschaltet und schaltet bei Nichtnutzung nach einer
bestimmten Zeit auf "Slep" (Stromsparmodus - alle Kontrolleuchten aus).
Bisher war mein Hauptrechner ein iMac, der per Ethernet am Router hing.
Jetzt habe ich komplett auf Laptop umgestellt mit Airport-Verbindung.
Deshalb ergab sich folgendes Problem:

Wenn der Drucker im Sleep-Modus einen Druckauftrag erhält, wachte der
Drucker auf und der Auftrag wird abgearbeitet. Das funktioniert jedoch
nur, wenn der Druckauftrag von einem Rechner kommt, der per Ethernet am
Router hängt. Über WLAN/Airport funktioniert das nicht. In den
Systemeinstellungen-Drucken & Faxen wird der Drucker unter WLAN mit
grünem Punkt angezeigt und als "bereit" ausgewiesen.

1) Aus- und wieder Einschalten des Druckers bringt nichts.
2) Ein Neustart des MBPs schafft ebenfalls Abhilfe.
3) Schließe ich an das MBP ein Ethernetkabel an, auch wenn ein
Druckauftrag unter WLAN noch aussteht und der Druckerspooler "Drucker
suchen ..." anzeigt, wird dann der Drucker sofort gefunden und der
Ausdruck startet.
4) Ziehe das Ethernetkabel nach einem Ausdruck ab und drucke dann wieder
über Airport, klappt der Ausdruck.
5) Den Drucker vor einem WLAN-Druckversuch über die "Go"-Taste
aufzuwecken, führt nicht zum Erfolg.

Bin ratlos und möchte vermeiden, jedes Mal ein Ethernetkabel einstecken
oder einen Neustart ausführen zu müssen, um den Drucker zu triggern.

Aktuelle Firmware des Routers D-Link DI-524UP ist drauf.
Auf dem MBP ist OS 10.6.4

Wo ist Abhilfe zu suchen?

Grüße

Maurice

Am 30.08.2010 11:09 Uhr schrieb Maurice Bonnet:

Bin ratlos und möchte vermeiden, jedes Mal ein Ethernetkabel einstecken
oder einen Neustart ausführen zu müssen, um den Drucker zu triggern.

Aktuelle Firmware des Routers D-Link DI-524UP ist drauf.
Auf dem MBP ist OS 10.6.4

Schneeleo hat einen noch immer nicht ganz behobenen Bug bei der
Namensauflösung von internen Adressen. Kannst du den Drucker überhaupt
anpingen, wenn er gerade nicht gefunden wird?

Wo ist Abhilfe zu suchen?

In den Druckereinstellungen IP-Adresse statt Hostnamen angeben. Einmal
den Cache der Directoryservices löschen hilft bei mir dauerhaft:

$ dscacheutil -flushcache
--
Gerald

Maurice Bonnet schrieb in

1) Aus- und wieder Einschalten des Druckers bringt nichts.

Äh, aber der Drucker wird doch nach dem Wiedereinschalten nicht etwa
sofortigst im "sleep"-Modus sein?

2) Ein Neustart des MBPs schafft ebenfalls Abhilfe.

Fehlt da ein "nicht"? Zumindest das "ebenfalls" klingt ein wenig nach
Widerspruch.

3) Schließe ich an das MBP ein Ethernetkabel an, auch wenn ein
Druckauftrag unter WLAN noch aussteht und der Druckerspooler "Drucker
suchen ..." anzeigt, wird dann der Drucker sofort gefunden und der
Ausdruck startet.

Was sagt die Ausgabe von "lpstat -t" bzw. "lpstat -t | grep '://'" bzgl.
"Gerät"? Bitte den kompletten Device-URI posten.

4) Ziehe das Ethernetkabel nach einem Ausdruck ab und drucke dann wieder
über Airport, klappt der Ausdruck.
5) Den Drucker vor einem WLAN-Druckversuch über die "Go"-Taste
aufzuwecken, führt nicht zum Erfolg.

Gerade wegen 4) und 5) würde ich doch sehr stark am Subject (Problem auf
Seite des Druckers) zweifeln. Das riecht nach einem reinen Mac-seitigen
Problem, siehe Geralds Hinweise/Anregungen.

Gruss,

Thomas

Gerald Eíscher wrote:

Kannst du den Drucker überhaupt
anpingen, wenn er gerade nicht gefunden wird?

Bekomme bei 10 Pingversuchen (mit Netzwerkdienstprogramm) diese
Rückmeldung:
======================= schnipp =======================
„Ping“ wurde gestartet …

ping: sendto: No route to host
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
PING 192.168.0.102 (192.168.0.102): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8

--- 192.168.0.102 ping statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss
======================= schnapp =======================

Sieht wohl nicht so gut aus.

In den Druckereinstellungen IP-Adresse statt Hostnamen angeben. Einmal
den Cache der Directoryservices löschen hilft bei mir dauerhaft:

So wie es aussieht, war das ein Volltreffer. Habe schon ein paar Mal
getestet und es hat funktioniert. Pingen klappt dann (natürlich) auch.
Vielen Dank.

Grüße

Maurice

Thomas Kaiser wrote:

Fehlt da ein "nicht"? Zumindest das "ebenfalls" klingt ein wenig nach
Widerspruch.

Das ebenfalls war verkehrt, sorry. Hatte erst eine andere Reihenfolge
der Aufzählungen.

Was sagt die Ausgabe von "lpstat -t" bzw. "lpstat -t | grep '://'" bzgl.
"Gerät"? Bitte den kompletten Device-URI posten.

Möchtest du das noch wissen? (siehe Antwort auf Gerald).

Grüße

Maurice

Maurice Bonnet schrieb am 31.08.2010 in

Thomas Kaiser wrote:

Was sagt die Ausgabe von "lpstat -t" bzw. "lpstat -t | grep '://'" bzgl.
"Gerät"? Bitte den kompletten Device-URI posten.

Möchtest du das noch wissen? (siehe Antwort auf Gerald).

Ja. Nebst knapper Beschreibung, was Du jetzt konkret gemacht hast
(dscacheutil oder Drucker anders angesteuert).

Gruss,

Thomas, der sich wieder in seiner generellen Ablehnung von MacOS X
10.x.0 - 10.x.4 bestätigt sieht, angesichts solcher Bugs...

Thomas Kaiser wrote:

Möchtest du das noch wissen? (siehe Antwort auf Gerald).

Ja. Nebst knapper Beschreibung, was Du jetzt konkret gemacht hast
(dscacheutil oder Drucker anders angesteuert).

lpstat -t | grep '://'
Gerät für _192_168_0_1: lpd://192.168.0.1/lp1
Gerät für _192_168_0_102: lpd://192.168.0.102/
Gerät für Adobe_PDF: pdf://distiller
Gerät für Brother_HL_5250DN_series:
dnssd://Brother%20HL-5250DN%20series._pdl-datastream._tcp.local./?bidi

Also: anfangs - bei der Ersteinrichtung - hatte ich dem Drucker zwar
eine feste IP zugewiesen (durch DHCP), der Drucker hat sich aber über
Bonjour in den Systemeinstellungen Drucken und Faxen beim Einrichten
"gemeldet", den hatte ich genommen - das ist wohl der lezte
Druckereintrag.
dnssd://Brother%20HL-5250DN%20series._pdl-datastream._tcp.local./?bidi

Der lpd://192.168.0.1/lp1 ist noch ein ehemals eingesetzter USB-Drucker,
der per USB am Router hing (DL 524-UP)

Nach Geralds Beitrag habe ich dann den lpd://192.168.0.102/
eingerichtet, der Brother direkt über die IP angesprochen. Das ging dann
auch. Als es dann einmal - aus mir nicht ersichtlichen Gründen - nicht
funktionierte, habe ich den dscacheutil-Befehl ausführen lassen. Wollte
es auch kleinschrittig mahcne, um wirklich zu wissen, was es ist, aber
wie gesagt, als das mal nicht klappte, habe ihr vertrauend auf Gerald
den dscacheutil-Befehl eingesetzt.

Jetzt klappt es, wie es soll.

Grüße

Maurice

Maurice Bonnet schrieb am 03.09.2010 in

Also: anfangs - bei der Ersteinrichtung - hatte ich dem Drucker zwar
eine feste IP zugewiesen (durch DHCP), der Drucker hat sich aber über
Bonjour in den Systemeinstellungen Drucken und Faxen beim Einrichten
"gemeldet", den hatte ich genommen - das ist wohl der lezte
Druckereintrag.
dnssd://Brother%20HL-5250DN%20series._pdl-datastream._tcp.local./?bidi

So soll's eigentlich auch sein. Drucker sich über (m)DNS selbst
annoncierend, auswählen, fertig. In dem Fall ist es völlig wurscht, ob
Du ihm manuell oder per DHCP 'ne statische Adresse gibst oder nicht
(DHCP sorgt in nahezu allen Implementierungen bei Geräten wie Druckern
dafür, daß die auch im "dynamischen" Modus immer die selbe Adresse
haben). Es braucht noch nicht mal ein DHCP-Server zu existieren und es
würde trotzdem klappen (Drucker und Mac würden sich dann beide eine
Adresse aus dem Bereich 169.254.0.0/16 wählen und die Namensauflösung
trotzdem klappen ). Wenn da nicht
dieser Snow Leopard Bug wäre -- peinlich für Apple.

Nach Geralds Beitrag habe ich dann den lpd://192.168.0.102/
eingerichtet, der Brother direkt über die IP angesprochen. Das ging
dann auch. Als es dann einmal - aus mir nicht ersichtlichen Gründen -
nicht funktionierte, habe ich den dscacheutil-Befehl ausführen lassen.

Der kann in dem Szenarium mit Adressierung per IP-Adresse keine Wirkung
haben. Du hättest genauso auch Rechte Reparieren spielen können ;-)

Gruss,

Thomas

Thomas Kaiser wrote:

(DHCP sorgt in nahezu allen Implementierungen bei Geräten wie Druckern
dafür, daß die auch im "dynamischen" Modus immer die selbe Adresse
haben)

Ah, das wusste ich nicht. Deshalb habe ich eine feste IP zugewiesen, da
ich hier ab und an mit verschiedenen Laptops ausdrucken muss und ich
annahm, dass die IP bei dynamischer Zuweisung wechseln könnte und ich
jedes Mal den Drucker erst suchen lassen müsste. Wieder etwas gelernt.

Wenn da nicht dieser Snow Leopard Bug wäre -- peinlich für Apple.

Bin mal gespannt, wie lange Apple den weiter mit rumschleppt.

Grüße

Maurice

Maurice Bonnet schrieb am 05.09.2010 in

Thomas Kaiser wrote:

(DHCP sorgt in nahezu allen Implementierungen bei Geräten wie
Druckern dafür, daß die auch im "dynamischen" Modus immer die selbe
Adresse haben)

Ah, das wusste ich nicht. Deshalb habe ich eine feste IP zugewiesen, da
ich hier ab und an mit verschiedenen Laptops ausdrucken muss und ich
annahm, dass die IP bei dynamischer Zuweisung wechseln könnte und ich
jedes Mal den Drucker erst suchen lassen müsste. Wieder etwas gelernt.

Naja, DHCP ist zwar vom Design her nicht sonderlich robust, was
Störungen bzw. Sabotage betrifft (man kann ein Netz durch einen falsch
konfigurierten DHCP-Server ziemlich simpel lahmlegen -- aber der Aspekt
ist im Heimnetz zu vernachlässigen). Aber Mechanismen, daß Clients
idealerweise immer die gleiche IPA bekommen, sind natürlich im Standard
vorgesehen.

Inital fragt ein Client per DHCPDISCOVER im Netz an, welche DHCP-Server
am Start sind, und was die so anbieten, wwählt dann den aus, der ihm am
Besten schmeckt (bspw. weil der die längste Lease-Dauer anbietet) und
befragt den direkt nach weiteren Parametern. Nach der Hälfte der Lease
fragt der Client genau diesen Server per DHCPREQUEST nochmal direkt an
und bekundet Interesse an der weiteren Verwendung der Adresse. Wenn der
Server nicht antwortet, darf der Client die Adresse behalten, muß aber
spätestens nach 7/8 der Lease-Dauer nochmal per Broadcast alle
verfügbaren DHCP-Server bzgl. Adresse fragen (kann ja auch sein, daß der
ursprüngliche DHCP-Server deshalb nicht mehr antwortet, weil er
ausgeschalten wurde).

D.h. das "Geheimnis" quasi statischer IPA-Zuordnungen ist ein
ausreichend großer Pool an verfügbaren Adressen gepaart mit einer dazu
passenden Lease-Dauer. Clients, die innerhalb der Lease-Dauer wieder
beim DHCP-Server anfragen, werden dann auch wieder die identische IPA
bekommen, wenn die denn noch frei ist (Voraussetzunge: ausreichend
großer Pool von Adressen konfiguriert).

Wenn da nicht dieser Snow Leopard Bug wäre -- peinlich für Apple.

Bin mal gespannt, wie lange Apple den weiter mit rumschleppt.

Yep. *Gerade* für Apple peinlich: Die hatten vor 25 Jahren eine
Protokollfamilie am Start (AppleTalk, damals noch LocalTalk genannt),
die so Blödsinn wie die Beschäftigung mit irgendwelchen numerischen
Adressen seitens des Endanwenders komplett überflüssig machte. Die
Geräte haben sich selbständig Adressen verteilt, sich im Netz mit Namen
publiziert, wurden mit eben diesen Namen im Netz gefunden und genutzt
(und ob sich nun unter der Haube irgendwelche Adressen geändert haben
oder nicht, war völlig wurscht, weil protokollimmanent immer eine
entsprechende passende Zuordnung existent war).

Mit der allmählichen Ablösung von AppleTalk durch TCP/IP war wiederum
Apple mit einer der Vorreiter, diese Komfortmerkmale von AppleTalk in
die TCP/IP-Welt zu bringen. Eben damit so ein anachronistischer Scheiß
wie "Adressen an Geräten einstellen" finalmente der Vergangenheit
angehört. Und theoretisch geht das ja auch alles ganz wunderhübsch mit
Bonjour: Null Notwendigkeit, sich mit irgendwelchen IP-Adressen zu
beschäftigen. Die Geräte publizieren sich per mDNS/DNS-SD im Netz,
werden über diese Namen gefunden und angesprochen. Und was unter der
Haube passiert (und sei's sogar, daß der Drucker alle paar Tage eine
andere IPA hätte) braucht nicht zu interessieren.

Dagegen sprechen solche dämlichen Bugs, die einfach nicht gefixt werden
(und parallel die anachronistische Holzkopf-Denke von Hobby-Admins,
denen schlecht wird bei der Vorstellung, daß irgendwer anders als sie
selbst irgendwelche Adressen in ihrem Netz vergeben -- damit meine ich
nicht Dich sondern so Leute, die in der TCP/IP-Steinzeit hängengeblieben
sind und Selbstadministration von Geräten ablehnen, meist mit dem
Totschlagargument "Das hat irgendwann schon mal nicht funktioniert" :-)

Gruss,

Thomas