Netzwerkdruck mit MiNT - suche Hilfe beim lpr setup

[Heinz Schmidt]

Hallo zusammen,

heute habe ich mich weider mit dem Netzwerkdruck unter MiNT befaßt. Grundsätzlich funktioniert das auch ... allerdings nicht automatisch.

Mein Setup:
- EasyMint 1.72 mit Kernel 1.7.0
- Dateien aus MiNT 98: /etc/printcap, lpd, lpr, lprm, lpq, lpspool

Ablauf:
- lpspool und lpd starten beim booten automatisch (können auch von Hand gestartet werden)
- Programm druckt über NVDI (z.B. Luna)
- NVDI druckt in Datei /pipe/HP880C
- pipe wird von lpspool ausgelesen und Druckdatei / -auftrag wird nach /var/spool/HP880C kopiert

... soweit so gut
... jetzt sollte lpd die Datei im spool Verzeichnis ausdrucken
... passiert aber nicht
... statt dessen wirft lpspool die Fehler:
"/usr/ucb/lpr: connect: file not found"
"jobs queued, but can not start deamon"
... wenn ich jetzt lpd (neu) starte, wird der Druckauftrag abgearbeitet

Wie aus den Sourcen von lpd leicht zu ersehen ist, schaut lpd beim Start nach, ob es aktuelle Druckaufträge gibt und arbeitet sie ab. Ich nehme an, das lpspool (leider haben wir davon die Sourcen nicht) nach dem Erstellen der Datei(en) im spool Verzeichnis mittels lpr Kommando das Drucken via lpd auslösen möchte. Nur leider fehlt dazu irgend eine Datei und ich weis nicht welche.

Wer kann mir mit schlauen Ideen helfen? Hat jemand vielleicht eine laufenden Mint 98 Installation mit funktionierendem Netzwerkdruck zum vergleichen?

Wenn jemand mit basteln möchte, fasse ich auch gerne die bis zum o.g. Stand notwendigen Schritte zusammen.

Edit:
Wenn ich lpr im Bash Fenster benutze, bekomme ich die gleichen Fehlermeldungen wie oben. Beispiel:

Code: [Auswählen]

cat /etc/hosts | /usr/ucb/lpr -PHP880C
/usr/ucb/lpr: connect: file not found
jobs queued, but cannot start deamon.

Edit 2:
Mit Hilfe von lpc kann man sich den Status des Druckers ansehen:

Code: [Auswählen]

lpc status HP880C
   queuing is enabled
   printing is enabled
   1 entry in spool area
   no deamon present
Das paßt zu meinem Fehlerbild. Der prozess lpd ist zwar aktiv aber irgendwie nicht ereichbar. Wenn ich den deamon mit lpc neustarte, passiert das gleiche wie oben beschrieben ... die vorhandenen Druckaufträge werden gedruckt ... dann ist der deamon wieder nicht erreichbar.

Es geht also auf die Frage zurück, wie erfolgt die Kommunikation mir dem lpd und wie wird seine Erreichbarkeit geprüft? Mittels netstat sehe ich zumindest folgendes:

Code: [Auswählen]

netstat -a
Active TCP connections
Proto     Recv-Q     Send-Q     Local-Address          Foreign-Address          State
TCP       0          0          *.printer              *.*                      Listen

Gruß Heinz

[Heinz Schmidt]

So, ich habe noch etwas weiter geforscht. Freundlicherweise enthält die MiNT 98 CD auch die Sourcen für das LPD Paket incl. man pages. Das hilft schon mal.

In der man page zum lpd steht:

Code: [Auswählen]

/dev/printer socket for local requests
Da es bei mir kein /dev/priner gibt, nehme ich an, das damit die Voraussetzung für die Kommunikaton mit dem deamon fehlt.

Ich habe leider keine Ahnung wie /dev/printer angelegt wird. Wenn ich das richtig verstehe ist das /dev Dateisystem nur zur Laufzeit vorhanden. Durch irgend ein Programm müßte also bei dessen Start /dev/printer angelegt werden. Richtig?

Gruß Heinz

[Heinz Schmidt]

Hallo zusammen,

für alle, die lpd auch aufsetzen wollen (und nicht die Mint mailing Liste lesen):

- LPD mit Sourcen, Binärpaketen und man pages gibt es hier zum herunterladen
- ich habe aus der man pages, internet Infos und meinen Tests ein paar Stichpunkte zusammengestellt und hier angehängt

Gruß Heinz

[Latz]

Hi,
ich habe zwar kein Netzwerk-Drucker (kann aber ja noch kommen),
auf jeden Fall mal vielen Dank für Deine Pionierarbeit!
Ich habe hier auf MiNT 1-18-cur /dev/lp (durch lp.xdd) und /dev/prn.
Dumm gefragt: Lässt sich damit vielleicht was vereinfachen?
Latz

[Heinz Schmidt]

Hallo Latz,

Ich habe hier auf MiNT 1-18-cur /dev/lp (durch lp.xdd) und /dev/prn.

guter Gedanke und gute Frage. Hast Du eine Ahnung wo ich zu lp.xdd eine Doku finde? Ich habe keinen Plan, wie man damit umgeht, es konfiguriert und benutzt.

Möglicherweise ist lp.xdd sogar Teil meines Problems, weil es /dev/lp bereitstellt und ich in meiner /etc/printcap auch /dev/lp als Ziel angegeben habe. Vielleicht kommen sich da lpd und lp.xdd ins Gehege.

Wieder was zum ausprobieren :-)

Gruß Heinz

[Heinz Schmidt]

Nun gut,

ich habe lp.xdd weggelassen, weil es nur für Parallel-Drucker notwendig ist. Daher habe ich nach dem Start von Mint kein /dev/lp mehr. Das ist soweit in Ordnung bzw. wie erwartet.

Nach dem Start von lpd habe ich allerdings immer noch kein /dev/lpd. Ich hatte erwartet, das lpd beim Start eine socket erstellt, die wie in der /etc/printcap bennannt /dev/lp heißt. Ist aber nicht so. Ein anderes device in der /etc/printcat einzutragen nutzt auch nichts.

Leider kann ich (mangels Programmierfähigkeiten) aus den Sourcen des LPD Paketes nicht erkennen wie die erstellte Socket heißen sollte, wo ich sie finde. Daher habe ich auch keine Ahnung wie ich das testen kann.

Könnte bitte einer der C-Programmierer mal in die Sourcen (s.o.) sehen und mich erleuchten?

@ m0n0 könntest Du vielleicht ein paar Minuten dafür investieren? Das Thema Netzwerk, Sockets und IP unter Mint hast Du doch bestens drauf.

Gruß vom verzweifelten Heinz

[Heinz Schmidt]

Hallo zusammen,

wieder ein kleines Stückchen weiter.

Der lpd erzeugt beim start die Socket

Code: [Auswählen]

/tmp/.printer
Das klappt auch auf meinem Milan. Leider funktioniert der connect auf diese Socket nicht. Warum verstehe ich noch nicht ... habe ja auch keine Ahnung von Sockets ;-)

Der Teil in startdeamon.c, der die o.g. Fehlermeldung ausgibt ist:

Code: [Auswählen]

if (connect(s, (struct sockaddr *)&sun, strlen(sun.sun_path) + 2) < 0) {
perr("connect");
(void) close(s);
return(0);
}
Es schlägt also wie gesagt das Verbinden mit der Socket fehl. Wenn jemand dazu eine Idee hat, immer her damit.

Ich schreibe das alles parallel auch auf der Mint Mailing Liste, da sind ja auch einige Programmierer unterwegs.

Gruß Heinz

[Arthur]

Hallo Heinz, klasse wie Du dich da hinein kniest. Ich bin gespannt wann das Drucken übers Netz funktioniert. Bitte weiter so.

[m0n0]

Wenn jemand dazu eine Idee hat, immer her damit.

rückgabe wert von von connect abfangen:

long error = connect(...) ;
if( error < xyz )  {
printf("connect: %d\n", error );
 ...
}

[Heinz Schmidt]

Hallo zusammen,

heute habe ich mal wieder ein paar Stunden für das Thema spendiert und als C-Dummy im Quelltext herumgebastelt.

Unter dem Strich ist nicht viel dabei herausgekommen. Klar ist, das der connect-Aufruf für die socket -1 zurückliefert. Was laut Doku bedeutet, das der Verbindungsversuch nicht erfolgreich war.

Die Ursache für den nicht erfolgreichen Verbindungsversuch soll per Fehlercode in der Variable "errno" übermittelt werden. Im Quelltext der Funktion startdaemon.c wird das auch alles schön behandelt:

Code: [Auswählen]

static void
perr(msg)
char *msg;
{
extern int errno;
extern char *name;
char *strerror();

(void)printf("%s: %s: %s\n", name, msg, strerror(errno));
}
Die Funktion

Code: [Auswählen]

... strerror(errno));übersetzt den zurückgegebenen Fehlercode in "file not found".

Weil ich damit nicht viel anfangen kann und den tatsächlichen Fehlercode wissen wollte, habe ich das ganze mal geändert in:

Code: [Auswählen]

... errno);
Da "errno" ja als int definiert ist, habe ich als Ergebins einen sinnvollen Zahlenwert erwartet, den ich dann z.B. mit Hilfe dieser Liste hätte interpretieren können.

Leider bekomme ich aber totalen Kaudawelsch heraus und bin mal wieder ratlos.

Code: [Auswählen]

/usr/ucb/lpr: connect: »µ»...
Irgendwelche Ideen, Hinweise, ...?

EDIT:
Muss ich "errno" für die Ausgabe anders formatieren? >>> JA

Nun ja, ich bin halt ein C-DAU ... da ich ja nun mit printf einen integer / Zahlenwert ausgeben möchte, sollte ich den auch nicht als string formatieren. Folglich muss ich für errno die Formatierung von %S auf %d ändern.

Code: [Auswählen]

 (void)printf("%s: %s: %d\n", name, msg, errno);
Und das ganze spuckt mir dann als Fehlercode die 33 aus

Code: [Auswählen]

/usr/ucb/lpr: connect: 33 ... was in der Doku die ich gefunden habe, leider nicht beschrieben ist.

Also einen kleinen Schritt weiter gekommen ... aber dann auch wieder nicht  

Gruß Heinz

[m0n0]

Hallo,

perror wird schon die korrekte Fehlerbeschreibung liefern. Wenn dort steht "File not found" - dann ist es so. Ich würde mir ausgeben lassen welche Datei ( in diesem fall eine spezielle "Datei" - ein socket ) versucht wird zu öffnen. Das kann entweder beim erstellen des sockets sein ( Funktion socket() ) - oder beim connect die remote "adresse".  Einfach mal die Parameter an beide funktionen ausgeben lassen und wenn da irgendwas nach Pfad / Socket datei aussieht - dann kontrollieren ob die Datei wirklich nicht da ist. Wenn sie nicht da ist, dann dafür sorgen das entweder die richtige datei geöffnet wird, oder die datei wirklich dort ist. Wenn sie dort ist... dann schauen ob die Berechtigungen den gewünschten Zugriff auf die Datei zulassen ( evt. mit chmod anpassen...?)

[afalc060]

hab mal gegoogelt
http://mail.opensolaris.org/pipermail/dtrace-discuss/2006-April/001479.html
vielleicht hilft die liste ja was

[Heinz Schmidt]

Hallo m0no,

...
Ich würde mir ausgeben lassen welche Datei ( in diesem fall eine spezielle "Datei" - ein socket ) versucht wird zu öffnen. Das kann entweder beim erstellen des sockets sein ( Funktion socket() ) - oder beim connect die remote "adresse".  Einfach mal die Parameter an beide funktionen ausgeben lassen und wenn da irgendwas nach Pfad / Socket datei aussieht ...

Ja, das habe ich mir auch gedacht. Allerdings stehe ich da gerade wieder auf dem Schlauch. Wie bekomme ich den Inhalt von "(struct sockaddr *)&sun"  so verpackt, das ich ihn leserlich ausgeben kann?

Bei "s" handelt es sich ja um ein int Wert, das bekomme ich hin ;-) aber bei  struct sonstwas stehe ich im Wald.

Gruß Heinz

[Heinz Schmidt]

Hallo zusammen,

der socket path (sun.sun_path) lautet /tmp/.printer. Die Datei (socket) wird von lpd beim Start angelegt und ist auch aktiv, wie ich aus folgendem Kommando schließe:

Code: [Auswählen]

netstat -f unix
...
Proto   Flags   Type    State         Recv-Q   Address
unix    ACC     STREAM  UNCONNECTED   0        u:\tmp\.printer

Daher gehe ich jetzt mal davon aus, das die socket an sich i.O. ist, aber beim Zugriff von lpr dieser die Datei / socket nicht findet oder nicht öffnen kann.

Ich habe etwas mit den Zugriffsrechten experimentiert. Das hilft aber leider auch nicht. Egal ob die group auf root, deamon oder lp steht. Auch der setzen der Zugriffsrechte auf 777 oder 6777 (suid) hilft nicht.

Gruß Heinz