[gelöst]Drucker druckt v. Win-Clients, nicht Debian-Clients

[debianoli]

Brauchst du überhaupt CUPS auf dem PI? Du könntest den doch als direkten IPP Drucker über Port 9100 einrichten. Ich habe das letztlich auf einem openwrt-Router so gemacht, der als "kleiner" Printserver dienen soll. Seitdem können Windows- und Linux-Clients über den openwrt-Router drucken

Das Paket dafür gibt es in Wheezy: p910nd

Edit: Die Einrichtung ist sehr einfach: http://wiki.openwrt.org/doc/howto/p910nd.server

Man-Pages: http://man.cx/p910nd

[TomL]

Aha, also doch die alte CUPS-Version.

Das kann ich jetzt bestätigen. Ich habe ja noch meinen Laptop, mit dem ich im Moment nix mache, den ich nur letzte Woche für meine Fahrt mit Jessie und Xfce vorbereitet habe. Der ist also hinsichtlich der Cups-Experimente noch ziemlich "untouched". Und dort war noch der Drucker mit lokalen Treiber (damals zum testen) eingerichtet und führt immer noch unverändert zu dem foomatic-Fehler. Nun habe ich gerade den lokalen Cups-Daemon gestoppt, dann in der printers.conf die letzte Stelle der IP geändert, vom Wheezy-Server auf den Jessie-Test-PI und neu gestartet. Und siehe da, der Ausdruck funktioniert einwandfrei.

[Ich betrachte es aus der Sicht vom CUPS-Server, und CUPS kennt vorallem "normal", und das bedeutet, es kommen bearbeitbare Daten an, wie "PDF", und die werden für den Druckertreiber vorbereitet, durch den Druckertreiber gejagt, dabei in eine Sprache verwandelt, die der Drucker versteht, und dann an den Drucker geschickt. Alternativ kennt CUPS noch die Bearbeitungsweise "RAW" ... hier tut CUPS gar nichts, sondern schickt die Daten direkt an den Drucker.

Das ist doch genau das, was ich die ganze Zeit auch gesagt habe..... ... es gibt 2 Cups'e, eins auf dem Client, eins auf dem Server, man kann sich aussuchen, welcher der beiden Kandidaten rendert, es darf aber immer nur einer tun.

Bei mir ist die derzeitige Situation so:
Die Windows-Clients rendern selber, der Server schickt "raw" durch zum Drucker
Die Linux-Clients rendern nicht, sondern schicken Rohdaten, hier muß der Server rendern, bevor er's zum Drucker sendet

Eigentlich ist das doch auch gaaanz einfach. Was bisher nicht funktioniert hat, war, dass die Linux-Clients auch selber rendern, das hat immer zum foomatic-Fehler geführt.

Ich habe jetzt nur ein neues Problem.... wäre ja auch zu schön, wenns einfach klappen würden Ich hatte vor, meinen PC langsam "zurückzubauen", um festzustellen, welche Treiber- und Filterkonstellation funktioniert. Ich wollte die Zusammenhänge reproduzierbar machen, damit ich die gleiche Konstellation auf den beiden anderen PC einrichten kann. Und irgendwann bin ich an dem Punkt angekommen, dass gar nix mehr raus geht zum Server. Ich habe jetzt direkt schon bei mir lokal einen Filterfehler Ich habe jetzt erst mal alles rigoros entfernt, alle Treiber, alle Filter, alle Drucker, weil ich nicht mehr auf die Reihe kriege, was durch die vielen Versuche noch "original" war, und was ich installiert habe. Und ich gebs zu... ausbleibender Erfolg macht zornig... ich habe jetzt auch Cups weggehauen. Was müsste ich jetzt installieren, damit Cups plus Abhängigkeiten wieder so hingestellt wird, wie es war. Im Moment habe ich dieselben Pakete installiert, wie sie auch auf dem Laptop vorhanden sind.... nur fehlt mir jetzt das Web-Interface.... und irgendwie finde ich kein Paket dafür.

Code: Alles auswählen

apt-get install cups cups-server-common cups-client cups-bsd cups-common
apt-get install foomatic-db-compressed-ppds foomatic-db-engine
apt-get install printer-driver-foo2zjs printer-driver-foo2zjs-common

Wenn ich auf den beiden Rechner /usr/share/doc/cups vergleiche, fehlen mir auf meinem PC die online-docs, die ich aber irgendwie vom Laptop auch nicht kopieren kann. Wie installiere ich die?

@Debianoli
Das wäre meine bevorzugte Lösung..... aber mit dem Wiki bin ich erst mal überfordert.... das habe ich nocht nicht kapiert.

[debianoli]

Das liest sich schwerer als es ist. Installier dir doch einfach mal das Programm p910nd auf dem Druckserver, also dem Raspberry Pi.

Wenn auf dem PI keine Firewall läuft, müsste der Port 9100 zum Drucken bereits frei sein. Das kannst du zB mit nmap testen. Einfach in der Konsole die Ports der IP-Adresse des Raspberry PI absuchen lassen:

Code: Alles auswählen

nmap IP_des_PI

Dann nach der Anleitung den Drucker mit der IP-Adresse des PI anlegen und das zuerst unter Linux (geht leichter, WIndows ist das etwas tricky).

Du hast schon immer gleiche IP-Adressen in deinem Netzwerk?

[TomL]

Aber die Entscheidung ist doch gar nicht so schwer. In spätestens 4-5 Wochen ist Jessie stable und wheezy oldstable.
Und noch vorhandene Bugs brauchen doch u.U. für Dich und Deine Nutzung des Systems gar nicht relevant sein, und es werden außerdem täglich welche gefixt.

Das ist eben genau die Frage. Ich habe die auch mal im Raspberrry Forum gestellt. Ich bin nämlich etwas unsicher, ob die Arbeitsweise bei Debian und den permanent aktualisierten Jessie-Quellen wirklich identisch bei Raspian ist. Ich schließe nämlich nicht aus, dass die Pflege der Repos bei Raspian nicht auf so viele Schultern verteilt ist, wie bei Debian. Und was ist, wenn dort vielleicht nur ab und zu mal der jeweils aktuelle Stand eingespielt wird und in längerer Zwischenzeit passiert dann nix? Oder kann das nicht sein? Ich weiss nicht, wie viel aktuelles Jessie jetzt tatsächlich in meinem aktualisierten Pi drinsteckt. Ich finde leider dazu auch keine Infos.

Auf jeden Fall wäre es ein schlechter Tausch, einen funktionierenden Drucker gegen einen instabilen Fileserver einzutauschen, weil vielleicht Raspian-Jessie nicht uptodate ist.

CUPS kann nämlich nicht erkennen, in welchem Zustand die Daten sind. Es schickt dir auch gerne "raw"-Daten noch mal an den Druckertreiber, der dann ne Fehlermeldung produziert.

Nein, das ist falsch. Auf dem Server ist in Cups der Samsung-Treiber eingerichtet. Und trotzdem sendet der Windows-Client gerenderte Daten. Cups auf dem Server erkennt das und macht nichts damit, die CPU-Last für CUPS blitzt ein-, zweimal kürzest mit 1-2% auf.... CUPS erkennt nämlich gerenderte Daten und schickt sie einfach weiter an den Drucker. Anders ist es, wenn mein Jessie-PC druckt. Cups auf dem Server erkennt die Rohdaten und fängt an zu rendern.... die CPU-Last auf dem Server geht für CUPS locker mehrere 10-Sekunden lang auf 100% hoch.

Das liest sich schwerer als es ist. Installier dir doch einfach mal das Programm p910nd auf dem Druckserver, also dem Raspberry Pi.

Ich kriegs nicht hin.... ist doch komplizierter als gedacht... und die Anleitung passt gar nicht. Interessant ist mal wieder, dass keine Fehlermeldung kommt. Also, ich habe p910nd auf dem PI eingerichtet und gestartet. Mit Netstat sehe den Port 9100 im Netz 0.0.0.0. "listen", wie einige andere Ports auch, die funktionieren. Also scheint das ok zu sein. Wenn ich nun vom Client drucke, kommen die 3 Meldungen (sinngemäß), Warte das der Drucker bereit ist, Sende an den Drucker, Auftrag beendet. Also aus Sicht des Clienst ist alles sauber rausgegangen. Nur am Drucker kommt nix an. Die Config /etc/default/p910nd sieht auch ganz anders aus, als in dem Wiki. Ich bin mir nicht mal sicher, ob das so richtig ist.

Code: Alles auswählen

# Printer number, if not 0
# P910ND_NUM=""
P910ND_OPTS="-f /dev/usb/lp0"

# Additional daemon arguments, see man 8 p910nd
P910ND_OPTS=""

# Debian specific (set to 1 to enable start by default)
P910ND_START=1

Nur am Drucker kommt halt nix raus. Äh... und nicht zu vergessen Deine Frage.... ja natürlich, haben alle feste IP's.

[NAB]

Anders ist es, wenn mein Jessie-PC druckt. Cups auf dem Server erkennt die Rohdaten und fängt an zu rendern....

Deine Verwendung von "raw" ist einfach komplett entgegengesetzt zu der Bedeutung, die es bei CUPS hat. Das verwirrt zumindest mich ...und vielleicht auch dein CUPS.

die CPU-Last auf dem Server geht für CUPS locker mehrere 10-Sekunden lang auf 100% hoch.

Das ist zumindest ein Indiz dafür. dass CUPS die Daten eben nicht als "raw" betrachtet, sondern sie durch den Druckertreiber jagt. Mehr aber auch nicht. Steht in den Logs denn nichts, was CUPS da genau macht?

(Der Vorschlag von debianoli klingt verführerisch simpel, bringt dir aber leider auch nichts, wenn deine Jessie-Clients wirklich nicht in der Lage sind, raw-Daten zu senden.)

Welcher Treiber läuft denn nun überhaupt auf Jessie? Der kann ja lokal drucken, aber nicht über das Netzwerk, soweit ich das verstanden habe.

[TomL]

...bringt dir aber leider auch nichts, wenn deine Jessie-Clients wirklich nicht in der Lage sind, raw-Daten zu senden.)

Welcher Treiber läuft denn nun überhaupt auf Jessie? Der kann ja lokal drucken, aber nicht über das Netzwerk, soweit ich das verstanden habe.

Wir drehen uns Kreis... meine Jessie-Clients können derzeit nur RAW drucken. Sobald ich in den Treibereinstellungen etwas anderes als RAW einstelle, kommt dieser Fehler. Das hatte ich doch schon mehrfach beschrieben.
Ich wiederhole mich, bestimmt zum 10. Mal.... Jessie sendet derzeit immer ohne Treiber nur Rohdaten, gerendert wird auf dem Server. Die Windows-Clients senden hingegen gerenderte Daten, der Server schickt diese dann unbehandelt weiter. Und das Server-Cups unterscheidet das perfekt. Das Server-Cups kommt sowohl mit gerenderten Daten und als auch mit Rohdaten perfekt klar. Man kann das ganz zweifelsfrei unterscheiden, wenn man sich die CPU-Last auf den Maschinen anschaut.

Lass uns das beenden, der Fehler ist ja mittlerweile erkannt, es liegt an der Wheezy und Cups-Version des Servers ...mein Customizing ist (da bin ich mir jetzt sicher) korrekt, denn auf dem Jessie-Test-Server funktionieren ja alle Varianten....dort kann ich vorgeben, welcher PC rendert und welcher nix macht, egal ob Server oder Client.

Und debianolis Vorschlag entspricht ja genau dem was ich will....nämlich das der Sever nicht rendern muss. Wenn das funktioniert, brauch ich ja auf dem Server noch nicht mal mehr Cups..... und so sollte es sein. Nur klappt das leider im Moment noch nicht. Wenn das aber klappen würde , wäre gleichzeitig auch sofort der Fehler mit Wheezy behoben., weil ja dann kein altes Wheezy und Cups diesen Fehler produzieren können.

[NAB]

Lass uns das beenden, der Fehler ist ja mittlerweile erkannt,

Gut, gut, mir war nicht klar, dass die Jessie-Server-Lösung für dich akzeptabel ist

Wie war das denn nun mit den unterschiedlichen Treibern? Oder ist das auch schon gelöst?

[debianoli]

Welchen Treiber nimmst du für den Druck auf den Linux-Clients? Den Samsung Unified Driver? Ich habe es auf diesen Weg hinbekommen, mit einem Samsung Drucker per n910pd zu drucken: Linux CLient mit CUPS und Netzwerkdrucker eingerichtet mit Samsung Unified Driver -> n910pd auf Openwrt Router mit Samsung Drucker angeschlossen per USB

Leider war das bei einem Freund, daher kann ich die Config zur Zeit nicht posten. I

Nur zur Sicherheit: Hast du den Druckserver mit nmap abgefragt und geprüft, welche Ports offen sind? /dev/usb/lp0 ist dein Drucker?

n910pd logt seine Errors ins syslog. Du könntest am pi mit

Code: Alles auswählen

tail -f /var/log/syslog

ansehen, ob n910pd Fehlermeldungen ausspuckt.

[TomL]

Wie war das denn nun mit den unterschiedlichen Treibern? Oder ist das auch schon gelöst?

Wenn ich ehrlich bin, muß ich mal wieder Nicht-Verstehen zugeben. Ich habe es gestern und vorgestern nicht mehr hingekriegt, auf meinem Rechner CUPS ans Laufen zu bringen. Der Dienst wurde gestartet, war aber weder mit dem Web-Interface noch vom KDE-Frontend ansprechbar. Ich hatte dann überlegt, dass hier im Forum anzusprechen, aber wegen möglicherweise tagelanges Probieren und immer wieder stundenlange Pausen wegen Warten auf Antworten habe ich mich entschieden, kurzerhand Jessie einmal drüberzubügeln. Nach 2 Stunden lief alles wieder und das Cups-Problem war gelöst.

So, und jetzt die Überraschung... ich habe KEINEN Samsung-Treiber installiert, nicht mal von Hand Gutenprint.... gar nix, nur eben beim Setup "Druckserver" ausgewählt, damit das volle Cups vorhanden ist. Und ich öffne Cups und stelle fest, es kennt meinen Druckertyp... obwohl mein Drucker auf der Gutenprint-Seite eindeutig nicht als unterstützter Drucker gelistet ist. Ich habe nicht den leisesten Schimmer, wie das geht. Und ich kann auf meinem Jessie-PC den Treiber entweder als RAW oder als Samsung einstellen, der Jessie-Druck-Server mit Cups 1.7.5. kann beides... beim ersten rendert er mit hoher CPU-Last, beim zweiten wirds (quasi CPU-neutral) einfach nur durchgeleitet. Mit Jessie auf Client und Server-Seite funktioniert es gut.

[debianoli]

Soviel ich mich erinnere erledigt das printer-driver-splix

Der ist sicher bei dir installiert:

Code: Alles auswählen

dpkg -l | grep splix

[TomL]

Welchen Treiber nimmst du für den Druck auf den Linux-Clients? Den Samsung Unified Driver?

Wenn ich das mal wüsste.... ich habe keinen installiert und es ist trotzdem einer vorhanden, der meinen Drucker mit Namen kennt.

Code: Alles auswählen

thomas@ThomasPC:/usr/lib/cups/driver$ ls -lah
insgesamt 5,8M
drwxr-xr-x  2 root root  4,0K Mär 27 13:06 .
drwxr-xr-x 10 root root  4,0K Mär 27 12:55 ..
-rwxr-xr-x  1 root root   22K Sep 16  2014 dymo
-rwxr-xr-x  1 root root  154K Nov 26 14:00 escpr
-rwxr-xr-x  1 root root   32K Okt  2 22:54 foo2zjs
lrwxrwxrwx  1 root root    29 Mär 24  2014 foomatic -> ../../../bin/foomatic-ppdfile
-rwxr-xr-x  1 root root  540K Okt 16 15:33 foomatic-db-compressed-ppds
-rwxr-xr-x  1 root root   55K Jun 25  2014 gutenprint.5.2
-rwxr-xr-x  1 root root  8,5K Mär  6  2014 m2300w
-rwxr-xr-x  1 root root  4,0M Okt 16 15:29 openprinting-ppds
-rwxr-xr-x  1 root root 1016K Jun 15  2014 postscript-hp
-rwxr-xr-x  1 root root   13K Mär  6  2014 ptouch
-rwxr-xr-x  1 root root  9,4K Okt 15 02:53 pxljr
thomas@ThomasPC:/usr/lib/cups/driver$ 

Ich habe es auf diesen Weg hinbekommen, mit einem Samsung Drucker per n910pd zu drucken: Linux CLient mit CUPS und Netzwerkdrucker eingerichtet mit Samsung Unified Driver -> n910pd auf Openwrt Router mit Samsung Drucker angeschlossen per USB

Leider war das bei einem Freund, daher kann ich die Config zur Zeit nicht posten. I
Nur zur Sicherheit: Hast du den Druckserver mit nmap abgefragt und geprüft, welche Ports offen sind? /dev/usb/lp0 ist dein Drucker?
n910pd logt seine Errors ins syslog. Du könntest am pi mit

Code: Alles auswählen

tail -f /var/log/syslog

ansehen, ob n910pd Fehlermeldungen ausspuckt.

Nee, ich wollte nmap erst mal nicht installieren.... ich tue mich ein wenig schwer, ein Programm für einen einzigen Aufruf auf der Konsole zu installieren. Ich habe mir mit "netstat -tulpen" den Pi angesehen, und da wurde der Port ebenso wie mein OpenVPN und der SSH-Port angezeigt, mit gleichem "Aussehen". Insofern denke ich, dass der Port 9100 ebenso innerhalb des Netzes erreichbar ist, wie die anderen. Und irgendwelche iptables oder andere beschränkende Einträge gibt da nicht.... ist doch nur mein Test-PI.

Ich werde jetzt erst mal das andere Problem lösen, mit dem Upgrade nach Jessie und es zunächst mal grundsätzlich ans Laufen bringen. Und ich würde mich riesig darüber freuen, wenn Du vielleicht irgendwann mal nach einem Besuch Deines Freundes einmal die Konfiguration postet.... das eilt aber nicht. Jetzt, nachdem ich verstanden habe, was auch gehen könnte, wäre das tatsächlich wohl die beste Lösung für mich. Aber wenn erst mal dieser foomatic-fehler grundsätzlich beseitigt ist, ist da ja auch schon mal eine gute Lösung.

[TomL]

Soviel ich mich erinnere erledigt das printer-driver-splix
Der ist sicher bei dir installiert:

Code: Alles auswählen

dpkg -l | grep splix

Jau, das wars...

Code: Alles auswählen

thomas@ThomasPC:/usr/lib/cups/driver$ dpkg -l | grep splix
ii  printer-driver-splix    2.0.0+svn315-4   amd64     Driver for Samsung and Xerox SPL2 and SPLc laser printers
thomas@ThomasPC:/usr/lib/cups/driver$ 

Die sind wohl alle per default im Jessie-Setup enthalten... wieder was dazu gelernt... aber wie soll man denn bloß "splix" mit Drucker und Drucken assoziieren....?

Code: Alles auswählen

thomas@ThomasPC:/usr/lib/cups/driver$ dpkg --get-selections | grep printer
printer-driver-all                              install
printer-driver-brlaser                          install
printer-driver-c2050                            install
printer-driver-c2esp                            install
printer-driver-cjet                             install
printer-driver-dymo                             install
printer-driver-escpr                            install 
printer-driver-foo2zjs                          install
printer-driver-foo2zjs-common                   install
printer-driver-gutenprint                       install
printer-driver-hpcups                           install
printer-driver-hpijs                            install
printer-driver-m2300w                           install
printer-driver-min12xxw                         install
printer-driver-pnm2ppa                          install
printer-driver-postscript-hp                    install
printer-driver-ptouch                           install
printer-driver-pxljr                            install
printer-driver-sag-gdi                          install
printer-driver-splix                            install
system-config-printer                           install
system-config-printer-udev                      install

[debianoli]

Die sind wohl alle per default im Jessie-Setup enthalten... wieder was dazu gelernt... aber wie soll man denn bloß "splix" mit Drucker und Drucken assoziieren....?

Ja, das habe ich mich auch gefragt, als bei meinem Freund den Samsung-Drucker eingerichtet habe. Sein Samsung Laser Printer läuft dafür nur mit den Treibern von Samsung.

Edit: Wie hast du das Drucken über n910pd denn auf dem Client eingerichtet? Bei Cups musst du zB einen "AppSocket/HP JetDirect" Printer wählen und dort als Adresse socket://IP-Adresse_PrintServer:9100 eingeben. Oder du gehst über die Drucker Menüs von Gnome/KDE

Das wird im unteren Teil des Eintrags im Openwrt-Wiki (Link hast du ja) ganz gut beschrieben.

[TomL]

Ich habe beides versucht, und jeweils kontrolliert, was "beim anderen" ankommt, bzw. wie das dort dann aussieht. Das heisst, ich hab den Drucker mit dem KDE-Applet eingerichtet und dann nachgesehen, wie das in Cups aussieht. Und ich habe den Drucker in Cups eingerichtet und kontrolliert, wie es dann im KDE-Applet aussieht. Letztendlich kam immer das gleiche raus, und zwar "socket://10.10.1.5:9100"

Das interessante war ja, dass es auf dem Client völlig planmäßig abgelaufen ist... zuerst auf den Drucker warten, dann senden, dann fertig melden.... ganz ohne Fehler. Aber auf die Idee mit dem p910-Log bin ich noch nicht gekommen.... das muss ich mal kontrollieren.

[NAB]

... aber wie soll man denn bloß "splix" mit Drucker und Drucken assoziieren....?

Zum Beispiel, indem man sich mal den Link auf das Ubuntu-Wiki durchliest, den ich nun schon zwei mal in den Thread gestreut habe:
viewtopic.php?f=31&t=154071&start=30#p1034581

Oder indem man per synaptic mal nach "samsung" sucht.

"nmap" will bei mir übrigens magere vier Pakete extra haben, wenn ich es installiere ... die direkt nach Benutzung wieder zu entsorgen wäre einfach.

[TomL]

Moin Nab

Zum Beispiel, indem man sich mal den Link auf das Ubuntu-Wiki durchliest, den ich nun schon zwei mal in den Thread gestreut habe:
viewtopic.php?f=31&t=154071&start=30#p1034581

Ich habe das natürlich gelesen... sogar schon bei ersten Mal.... so wie ich auch etwa 1000 andere Seiten auf der Suche nach Lösungen gelesen habe. Nur passiert es eben, daß man manchmal Aspekte (wie eben Splix) als nicht relevant bewertet und es damit nicht richtig verinnerlicht. Ich habe eben Splix NICHT selber von Hand installiert, also war das auch anscheinend kein Bestandteil meines Problems.... das Splix trotzdem werkelt war für mich eine totale Überraschung. Sowas passiert eben.

So.... die Frage mit Jessie auf dem Pi ist auch beantwortet.... Jessie ist definitiv keine Lösung für den Pi. Das englischsprachige RPI-Forum ist sich darin einig "Finger weg von Jessie!". Es gibt anscheinend wohl wenig, was noch instabiler als Jessie auf dem Pi ist Also werde ich mich jetzt auf die Lösung von Debianoli konzentrieren.... und über Erfolg und Mißerfolg berichten.

[TomL]

@debianoli
DANKE für diesen Tip!

[NAB]

Ist die Sache jetzt gelöst? Sonst hätte ich hier noch einen weiteren Link, der erklärt, wie man einem CUPS-Server sagt, dass er eingehende Aufträge in die raw queue stecken soll:
https://stackoverflow.com/questions/122 ... -interface

Und hier hatte jemand auf dem Raspberry Pi Erfolg, indem er ein neueres CUPS kompiliert hat:
http://chemdroid.net/en/raspberry-pi/36 ... int-server

[TomL]

Ist die Sache jetzt gelöst?

Ja, ist gelöst.... und zwar richtig gut.... genau so hatte ich mir das gedacht, ohne das ich gewusst hätte wie.

Das lokale Treiber-Problem mit dem foomatic-rip-Fehler ist endlich gelöst. Im Ergebnis siehts jetzt so aus, dass ich während der Druckverarbeitung auf dem RasPi so gut wie keine CPU-Last mehr feststellen kann.... weil jeweils lokal gerendert wird.... perfekt, genau so wie es sein soll. Aber natürlich ging das mal wieder nicht so einfach und glatt durch, natürlich gabs wieder Probleme, die ich nicht nachvollziehen konnte.

Ich habe 3 Jessie-PC umgestellt.... 1 x AMD64, 2 x I386.
Das Setup bei meinem AMD64-PC lief ohne irgendwelche Aufreger einfach durch. Der Splix-Treiber ist installiert und funktionierte auf Anhieb fehlerlos - im ersten Versuch erfolgreich. Ein I386-PC hat den Splix-Treiber sowie einige andere installiert, der andere PC (mit gleichem (!)) Setup nicht. ... Nach dem ich beide auf den gleichen Stand ge'splix'ed habe, musste ich feststellen, dass beide mit diesem Treiber nicht drucken können, der korrekte Drucker ist in der Liste gar nicht enthalten. Ich erinnere: beim AMD64 ist der Drucker enthalten und funktioniert!

Ich haben dann auf den beiden I386-Jessies Splix wieder uninstalled und dafür den Unified-Samsung-Treiber 4.01.17 installiert... erfreulicherweise lief das Setup auf beiden Systemen ohne Besonderheiten durch. Danach wars ein Kinderspiel, der Rest war dann wie bei meinem PC. Im folgenden hier meine Notizen, um das später mal wiederholen zu können, und vielleicht hilfts dem einen oder anderen beim nachbauen.

Code: Alles auswählen

Setup shared Printer (Samsung CLX 3170 Color-Laser) on Raspberry Pi/2 with p910nd (Printer-Daemon)

Setup Print-Server
------------------
root@raspi1:/# lsmod | grep usb                         # USB-Printer exist?
    usblp                  10379  0 

root@raspi1:/# modinfo usblp
    filename:       /lib/modules/3.18.7-v7+/kernel/drivers/usb/class/usblp.ko
    license:        GPL
    description:    USB Printer Device Class driver
    author:         Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, Pete Zaitcev, David Paschal
    srcversion:     45C2AB08A75D23778E99720
    alias:          usb:v04B8p0202d*dc*dsc*dp*ic*isc*ip*in*
    alias:          usb:v*p*d*dc*dsc*dp*ic07isc01ip03in*
    alias:          usb:v*p*d*dc*dsc*dp*ic07isc01ip02in*
    alias:          usb:v*p*d*dc*dsc*dp*ic07isc01ip01in*
    alias:          usb:v*p*d*dc07dsc01dp03ic*isc*ip*in*
    alias:          usb:v*p*d*dc07dsc01dp02ic*isc*ip*in*
    alias:          usb:v*p*d*dc07dsc01dp01ic*isc*ip*in*
    depends:        
    intree:         Y
    vermagic:       3.18.7-v7+ SMP preempt mod_unload modversions ARMv7 
    parm:           proto_bias:Favourite protocol number (int)

root@raspi1:/# ls /dev/usb
    lp0

apt-get install p910nd 
    
nano /etc/default/p910nd                                # Customizing Daemon
    # Printer number, if not 0
    P910ND_NUM=""

    # Additional daemon arguments, see man 8 p910nd
    #P910ND_OPTS=""
    P910ND_OPTS="-f /dev/usb/lp0"

    # Debian specific (set to 1 to enable start by default)
    P910ND_START=1

nano /etc/services                                      # Don't forget to add an entry for the corresponding port
    p910nd          9100/tcp                            # Insert Service

/etc/init.d/p910nd restart                              # Start Daemon
tail -f /var/log/syslog                                 # Dynamically check syslog at first Print-Job from client
    
--------------------------------------------------------------------------------------------------------------------
   
Setup Linux-Client
------------------

Jessie KDE
    - Works with present Splix-Driver

Jessie Xfce
    - Install Samsung-unified-Driver 4.01.17 
    
KDE/Xfce-Printer-Applet
    - Add Printer
    - Select Network-Printer
    - Select AppSocket/JetDirect
    - Set Host (IP Print-Server) 10.10.1.2              # Change IP to your Server-IP
    - Set Port: 9100
    - Select Printer-Driver, Customize Printer-Settings, Ready
    
Cups-Web-Interface
    - Browser: http://localhost:631/admin
    - Add Printer
    - Select AppSocket/JetDirect
    - Insert in Edit-Field: socket://10.10.1.2:9100             

Client-Connect:  socket://10.10.1.2:9100                    
    
---------------------------------------------------------------

Setup Win-Client (7/Prof)
-------------------------

Start -> Devices and Printers
    Add Printer
        Add Local Printer
            Create new Port -> TCP/IP:Port
                Device-Type          TCP/IP
                Hostname / IP        10.10.1.2          # IP RasPi-Printserver without //
                Portname             10.10.1.2
                Uncheck  request Printer
            Next/OK!
            
            Search TCP/IP-Ports perhaps needs some seconds
            
            Additional Informations needed
                - Select Standard (Generic Network-Carc)
                or User-Defined
                - Protocol: RAW
                - Port:     9100
            Next/OK!
            
            Printer-Driver
                - Select Driver                         # Samsung->CLX 3170
                - Input Printer-Name                    # CLX_3170_P9100
            Next/OK!            
            
            Printer added succesful
                Share Printer?
                Default-Printer?
                Print Testpage?
                Yes or No!
            Next/OK!            

[debianoli]

Ich habe 3 Jessie-PC umgestellt.... 1 x AMD64, 2 x I386.
Das Setup bei meinem AMD64-PC lief ohne irgendwelche Aufreger einfach durch. Der Splix-Treiber ist installiert und funktionierte auf Anhieb fehlerlos - im ersten Versuch erfolgreich. Ein I386-PC hat den Splix-Treiber sowie einige andere installiert, der andere PC (mit gleichem (!)) Setup nicht. ... Nach dem ich beide auf den gleichen Stand ge'splix'ed habe, musste ich feststellen, dass beide mit diesem Treiber nicht drucken können, der korrekte Drucker ist in der Liste gar nicht enthalten. Ich erinnere: beim AMD64 ist der Drucker enthalten und funktioniert!

Das ist ein schöner Fehler, der macht richtig Spaß.

Was du in dem Fall noch machen könntest (wenn dir mal langweilig ist ): Debian ist multiarch-fähig, d.h. du kannst unter i386 auch amd64 Programme laufen lassen. Du kannst also unter den i386-PCs den i386-Splix Treiber entfernen und stattdessen den amd64-Splix Treiber installieren.

Meiner Meinung nach sollte das funktionieren.

Grundlagen zu Multiarch: https://wiki.debian.org/Multiarch/HOWTO

[TomL]

Moin @ all

Es ist wie mit dem Wetter... auf ein Hoch folgt zwangsläufig irgendwann auch ein Tief. Und auf zu frühe Euphorie folgt die Ernüchterung. Ich habe heute morgen meinen PC gestartet, um ein paar "kaufmännische" Arbeiten zu erledigen.... und ich habe die Hardware nicht mehr dazu bewegen können, irgendwie zu drucken. Ich habe gestern an den Einstellungen definitiv nichts mehr verändert... keine Chance, es kommt nix raus. Drucke ich via p910nd sehe ich auf meinem PC in Cups, dass der Druck rausgegangen ist, auf dem Server sehe ich im Log die empfangenen Daten und eine völlig normale Verarbeitung.... aber es kommt nix am Drucker raus. Minuten später kommt ein einzelnes Blatt raus mit der enthaltenen Meldung "SPL-C Error - Including Corrupted Data". Selbst ein Druck (wie vorher) über Cups->RAW funktionierte nicht mehr. Und auch dabei keine Fehlermeldungen, beide Cups'e arbeiten einwandfrei. Und trotzdem war Cups auf dem Server nicht zum Drucken zu bewegen, nicht mal mit Restart des Dienstes. Erst nach Entfernen von p910nd und einem Reboot des Servers konnte ich wieder wie vorher in der Linie Client->Cups(RAW) auf Server->Cups(SamsungDriver) drucken.

Ich hake das Thema jetzt endgültig ab. Irgendwann wird Jessie auf dem PI kommen, damit läuft es ..... im Moment bin ich es leid, ich habe bisher schon viel zu viel Zeit für dieses Problem investiert. Das einzige Vorteilhafte daran war "wieder mal viel dazu gelernt".... also besinne ich mich auf "think positive" und freue mich über das gewonnene... und vergesse das, was nicht geht.

[debianoli]

War das von einem Windows-PC aus? Denn da finde ich beim googlen deiner Fehlermeldung das da http://answers.microsoft.com/de-de/wind ... 363d549fc2

Danach ist der Virenschutz schuld.

[NAB]

Vielleicht hätte es geholfen, den Drucker einfach mal aus- und wieder einzuschalten.

[TomL]

@Debianoli
Ich nutze derzeit Windows nur noch, um gelegentlich die automatischen Updates einzuspielen. Hier in dem Fall wars "Jessie".

@Nab
Als ich angefangen habe, war der Drucker ausgeschaltet.... das heisst, ich habe ihn erst unmittelbar vorher eingeschaltet. Und ich hatte ihn zwischendurch wegen der Probleme auch noch mal zum Testen neu gestartet. Den Fehler, daß sich ein USB-Port anscheinend auch "schlafen" legt, wenn sich das End-Gerät automatisch in den Standby versetzt, kennen wir hier schon lange. Insofern ist der Drucker-Neustart immer der erste Handgriff bei Störungen.

[NAB]

Tom, vielleicht magst du dich dann doch noch mal mit diesem Link auseinandersetzen:
https://stackoverflow.com/questions/122 ... -interface