Drucker wacht über Airport nicht auf

[Maurice Bonnet]

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

[Gerald Eíscher]

Post by 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?

Post by Maurice Bonnet
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

[Maurice Bonnet]

Post by Gerald Eíscher
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.

Post by Gerald Eíscher
In den Druckereinstellungen IP-Adresse statt Hostnamen angeben. Einmal

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]

Post by Maurice Bonnet
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?

Post by Maurice Bonnet
2) Ein Neustart des MBPs schafft ebenfalls Abhilfe.

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

Post by Maurice Bonnet
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.

Post by Maurice Bonnet
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

[Maurice Bonnet]

Post by Thomas Kaiser
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.

Post by Thomas Kaiser
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

[Thomas Kaiser]

Post by Maurice Bonnet

Post by Thomas Kaiser
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...

[Maurice Bonnet]

Post by Thomas Kaiser

Post by Maurice Bonnet
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

[Thomas Kaiser]

Post by Maurice Bonnet
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 <http://de.wikipedia.org/wiki/Zeroconf>). Wenn da nicht
dieser Snow Leopard Bug wäre -- peinlich für Apple.

Post by Maurice Bonnet
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

[Maurice Bonnet]

Post by Thomas Kaiser
(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.

Post by Thomas Kaiser
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

[Thomas Kaiser]

Post by Maurice Bonnet

Post by Thomas Kaiser
(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).

Post by Maurice Bonnet

Post by Thomas Kaiser
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

[Florian Zschocke]

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"

Das hat mit Steinzeit nichts zu tun. Ich verwende schlicht keine
komplexen Protokolle wenn Sie mir keinen Mehrwert oder aber eine
Arbeitserleichterung bringen. Das ist einfach nur pragmatisch. Dieser
thread gibt mir doch recht. Die mDNS Annonce funktioniert in einigen
Situationen nicht. Zeroconf ist für mich eh eine Nullnummer, solange
es nicht einen Zeroconf Router gibt, der in der Lage ist eine
Netztopologie zu annoncieren. Was hilft es mir wenn ich Drucker und
andere Clients finde aber das Internet nicht. Ohne DHCP (oder
statische Adressen) geht es also eh nicht. Das ein Client bei DHCP
immer die selbe Adresse bekommt, kann ich auch nicht bestätigen. Bei
vielen Home-Routern die ich getestet habe reicht ein Neustart des
Routers und das stimmt nicht mehr. Dann bekommt zuverlässig die erste
IP wer als erster danach fragt. Es kann sein das ich an dieser Stelle
etwas altbacken bin. Das aber nicht weil ich andere Methoden nicht
getestet hätte, sondern weil ich wieder dazu zurückgekehrt bin.
Du bist halt eher der Theoretiker und ich der Praktiker. Entsprechend
wird unsere Arbeitswelt aussehen.

Gruß Florian

P.S.: Es würde Dir gut stehen, Du würdest mal Deine Polemik weglassen.
Du kommst sonst rüber wie jemand mit einer sozialen Behinderung.
Wenn Du ein Problem mit mir hast, darfst Du mir auch gerne persönlich
schreiben.

[Peter Brülls]

Post by Florian Zschocke

Post by Thomas Kaiser
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"

Das ein Client bei DHCP
immer die selbe Adresse bekommt, kann ich auch nicht bestätigen. Bei
vielen Home-Routern die ich getestet habe reicht ein Neustart des
Routers und das stimmt nicht mehr. Dann bekommt zuverlässig die erste
IP wer als erster danach fragt. Es kann sein das ich an dieser Stelle
etwas altbacken bin.

Oder eben - sorry - steinzeitlich. Wenn der Router sowas nicht kann, ist
er doch schlichtweg veraltet und gehört ausgetauscht.

[Daniel Krebs]

Post by Florian Zschocke
P.S.: Es würde Dir gut stehen, Du würdest mal Deine Polemik weglassen.
Du kommst sonst rüber wie jemand mit einer sozialen Behinderung.

Das usenet ist nunmal keine Kuschelbude.
Du musst schon entscheiden, ob Du etwas lernen oder beleidigt sein
willst.
Daniel

[Florian Zschocke]

Post by Daniel Krebs

Post by Florian Zschocke
P.S.: Es würde Dir gut stehen, Du würdest mal Deine Polemik weglassen.
Du kommst sonst rüber wie jemand mit einer sozialen Behinderung.

Das usenet ist nunmal keine Kuschelbude.
Du musst schon entscheiden, ob Du etwas lernen oder beleidigt sein
willst.
Daniel

Nach langer Überwindung. Mit Dir würde ich dann doch lieber kuscheln!
Florian

[Maurice Bonnet]

Post by Maurice Bonnet
Bin mal gespannt, wie lange Apple den weiter mit rumschleppt.

Jetzt bin ich mal gespannt. Komme ich heute nach Hause, meint meine
Frau, der Ausdruck über den iMac (10.5.8) ginge auch nicht mehr. Da
werde ich mal prüfen, ob ich das rekonstruieren kann, sprich, ob der
Namenauflöse-Bug auch in 10.5.8 vorliegt.
Vor Wochenende geht da aber gar nichts - neuer Job, jeden Tag 11-13
Stunden außer Haus, dann kommt erstmal Familie.

Grüße

Maurice

[Gerald Eíscher]

Post by Maurice Bonnet
Jetzt bin ich mal gespannt. Komme ich heute nach Hause, meint meine
Frau, der Ausdruck über den iMac (10.5.8) ginge auch nicht mehr. Da
werde ich mal prüfen, ob ich das rekonstruieren kann, sprich, ob der
Namenauflöse-Bug auch in 10.5.8 vorliegt.

Den Bug hatte ich mit 10.5.8 noch nicht, erst mit Schnee Leo.

[Maurice Bonnet]

Post by Gerald Eíscher
Den Bug hatte ich mit 10.5.8 noch nicht, erst mit Schnee Leo.

Also, nun mehrmals versucht.
Wenn ich vom iMac mit 10.5.8 via Airport auf dem Netzwerkdrucker drucken
möchte ohne Zuweisung der IP sondern interen Namensauflösung, dann
klappt das ebenso wenig wie das beim MacBook Pro 10.6.4 der Fall war.
Stecke ich das Ethernetkabel beim iMac rein, springt der Drucker an und
los geht's.

Zumindest in meinem Fall stimmt deine Aussage nicht. Oder liegt es doch
am Router?

Maurice

[Thomas Kaiser]

Post by Maurice Bonnet

Post by Maurice Bonnet
Bin mal gespannt, wie lange Apple den weiter mit rumschleppt.

Jetzt bin ich mal gespannt. Komme ich heute nach Hause, meint meine
Frau, der Ausdruck über den iMac (10.5.8) ginge auch nicht mehr. Da
werde ich mal prüfen, ob ich das rekonstruieren kann, sprich, ob der
Namenauflöse-Bug auch in 10.5.8 vorliegt.

Das ist übrigens der größte Fehler, den man bei Problemsuche machen
kann: Aufgrund irgendeines anderen vermeintlich ähnlichen Ereignisses
mit (fehlleitenden) Vermutungen in eine bestimmte Richtung am Start
sein.

Geh unvoreingenommen und methodisch vom Simplem zum Komplexen ran. Der
Drucker druckt nicht, fertig. Kann an allem Möglichen liegen (bspw.
Drucker nicht eingeschaltet ;-)

Konsole.app und /var/log/cups/error.log sind Dein Freund.

Gruss,

Thomas

[Maurice Bonnet]

Post by Thomas Kaiser
Das ist übrigens der größte Fehler, den man bei Problemsuche machen
kann: Aufgrund irgendeines anderen vermeintlich ähnlichen Ereignisses
mit (fehlleitenden) Vermutungen in eine bestimmte Richtung am Start
sein.

Da haste Recht. Wenn mein Auto nicht anspringt, baue ich ja auch nicht
erst den Vergaser auseinander, auch wenn das bei der letzten Karre die
Ursache war.

Post by Thomas Kaiser
Kann an allem Möglichen liegen (bspw.
Drucker nicht eingeschaltet ;-)

Diese Fehlerquelle konnte ausgeschlossen werden.
Nun, Fehlerbehebung ist erfolgt - ein Ausdruck musste her. Habe einfach
ausgedruckt. Ich würde gerne den Fehler rekonstruieren.

Grüße

Maurice