SCSI Scanner nachtraeglich einschalten (SUSE 7.1)
Hallo zusammen, nachdem ich schon seit dem Umstieg von 6.4 auf 7.1 mit diesem Problem lebe und bisher in der Liste leider keine Loesungsmoeglichkeit gefunden habe, versuche ich es nun doch mal mit einer Frage an Euch. Wenn ich meinen SCSI Scanner EPSON GT-7000 bei laufenden PC einschalte und das Script 'rescan-scsi-bus.sh' (von Kurt Garloff) laufen lasse, erscheinen in '/var/log/messages' folgende Zeilen: Feb 4 20:22:19 obelix kernel: Vendor: EPSON Model: SCANNER GT-7000 Rev: 1.14 Feb 4 20:22:19 obelix kernel: Type: Processor ANSI SCSI revision: 02 Feb 4 20:22:19 obelix kernel: Attached scsi generic sg6 at scsi0, channel 0, id 0, lun 0, type 3 Jedoch auch nach dem Umklemmen von /dev/scanner -> /dev/sg6 findet keines der Scantools (xsane, xscanimage) einen Scanner. Unter 6.4 hat ein aehnliches Vorgehen noch funktioniert. Was muss ich noch machen, dass ich den Scanner so nutzen kann ?? ('sgcheck' gibt's unter 7.1 nicht) Ich habe mir mal die geladenen Module in beiden Faellen angesehen (Scanner beim booten eingeschaltet/Scanner nachtraeglich eingeschaltet) und KEINE Unterschiede gefunden. Sprich es ist kein zusaetzliches Modul am laufen wenn der Scanner beim booten einge- schaltet war. Hat jemand Tipps in welcher Richtung ich suchen soll ?? Gruesse Werner Franke ------------------ Weitere Infos: --------------------------- Kernel: 2.4.19 (selbst compeliert, SCSI ist fest drin) ------------------------------------------ (Scanner ist beim booten eingeschaltet) root@obelix (bash) lsmod Module Size Used by snd-pcm-oss 37008 2 (autoclean) snd-mixer-oss 10736 1 (autoclean) [snd-pcm-oss] NVdriver 1066448 10 (autoclean) parport_pc 15312 1 (autoclean) lp 6032 0 (autoclean) ipv6 126368 -1 (autoclean) mousedev 3904 0 (unused) hid 13232 0 (unused) input 3168 0 [mousedev hid] usb-uhci 21536 0 (unused) snd-emu10k1-synth 3840 0 (unused) {gekuerzt} snd 23712 0 [snd-pcm-oss snd-mixer-oss ... soundcore 3376 8 [snd] ide-scsi 7600 0 nls_iso8859-1 2880 1 (autoclean) nls_cp437 4384 1 (autoclean) vfat 9456 1 (autoclean) fat 29472 0 (autoclean) [vfat] ------------------------ (Scanner war beim booten ausgeschaltet und 'rescan-scsi-bus.sh' ist gelaufen) (wfranke obelix tcsh) [40] find-scanner find-scanner: found processor "EPSON SCANNER GT-7000 1.14" at device /dev/scanner find-scanner: found processor "EPSON SCANNER GT-7000 1.14" at device /dev/sg6 root@obelix (bash) ls -l /dev/sg6 crw-rw-rw- 1 root disk 21, 0 Jan 19 2001 /dev/sg6 (wfranke obelix tcsh) [48] cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: RICOH Model: CD-R/RW MP7060S Rev: 1.50 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 02 Lun: 00 Vendor: ARCHIVE Model: VIPER 150 21531 Rev: -004 Type: Sequential-Access ANSI SCSI revision: 01 Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: SEAGATE Model: ST12400N SUN2.1G Rev: 8720 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 05 Lun: 00 Vendor: SEAGATE Model: ST34520N Rev: 1498 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: EXABYTE Model: EXB-8200 Rev: 425A Type: Sequential-Access ANSI SCSI revision: 01 Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: EPSON Model: SCANNER GT-7000 Rev: 1.14 Type: Processor ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: SAMSUNG Model: DVD-ROM SD-616F Rev: F101 Type: CD-ROM ANSI SCSI revision: 02
Hallo, Am Mon, 2003-02-10 um 10.34 schrieb Werner Franke:
Hallo zusammen, Wenn ich meinen SCSI Scanner EPSON GT-7000 bei laufenden PC einschalte und das Script 'rescan-scsi-bus.sh' (von Kurt Garloff) laufen lasse, erscheinen in '/var/log/messages' folgende Zeilen:
Feb 4 20:22:19 obelix kernel: Vendor: EPSON Model: SCANNER GT-7000 Rev: 1.14 Feb 4 20:22:19 obelix kernel: Type: Processor ANSI SCSI revision: 02 Feb 4 20:22:19 obelix kernel: Attached scsi generic sg6 at scsi0, channel 0, id 0, lun 0, type 3
Jedoch auch nach dem Umklemmen von /dev/scanner -> /dev/sg6 findet keines der Scantools (xsane, xscanimage) einen Scanner. Unter 6.4 hat ein aehnliches Vorgehen noch funktioniert.
Wenn ich meine 7.3 beim booten beobachte, setzt die noch die Rechte auf das Scanner Device neu, evtl. fehlen den Programmen ja nur die entsprechenden Rechte. Da würde ich auch mal den Vergleich zwischen den beiden Verfahren machen.
Was muss ich noch machen, dass ich den Scanner so nutzen kann ??
Gruß Jens
Hallo Jens, Jens Keizer wrote on Montag, 10. Februar 2003 10:43 about Re: SCSI Scanner nachtraeglich einschalten (SUSE 7.1):
Jedoch auch nach dem Umklemmen von /dev/scanner -> /dev/sg6 findet keines der Scantools (xsane, xscanimage) einen Scanner. Unter 6.4 hat ein aehnliches Vorgehen noch funktioniert.
Wenn ich meine 7.3 beim booten beobachte, setzt die noch die Rechte auf das Scanner Device neu, evtl. fehlen den Programmen ja nur die entsprechenden Rechte.
Ich würde sagen, dass die Rechte auf dem sg-Device entscheidend sind. Ich "mount" bzw. "unmounte den Scanner immer mit folgendem Script: #!/bin/sh # file: /bin/scanner # (U) Mount the scanner # Marcus Roeckrath # 19.02.02 ScannerDevice="" if grep "Scanner" /proc/scsi/scsi > /dev/null ; then echo "Unmounte Scanner" rm -f /dev/scanner ScannerDevice=`grep -n "Scanner 636A4" /proc/scsi/sg/device_strs | cut -f 1-1 -d ":"` if [ "$ScannerDevice" != "" ] && (echo $ScannerDevice | grep -qs [678]) ; then ScannerDevice=sg$[ $ScannerDevice-1 ] chmod 0640 /dev/$ScannerDevice fi echo "scsi remove-single-device 1 0 6 0" > /proc/scsi/scsi if grep "Scanner" /proc/scsi/scsi > /dev/null ; then ScannerDevice=`grep -n "Scanner 636A4" /proc/scsi/sg/device_strs | cut -f 1-1 -d ":"` if [ "$ScannerDevice" != "" ] && (echo $ScannerDevice | grep -qs [678]) ; then ScannerDevice=sg$[ $ScannerDevice-1 ] ln -sf /dev/$ScannerDevice /dev/scanner chmod 0660 /dev/$ScannerDevice fi echo "Could not unmount Scanner! Scanner is mounted to $ScannerDevice" sleep 5 else echo "Scanner unmounted" fi else echo "Mounte Scanner" echo "scsi add-single-device 1 0 6 0" > /proc/scsi/scsi if grep "Scanner" /proc/scsi/scsi > /dev/null ; then rm -f /dev/scanner ScannerDevice=`grep -n "Scanner 636A4" /proc/scsi/sg/device_strs | cut -f 1-1 -d ":"` if [ "$ScannerDevice" != "" ] && (echo $ScannerDevice | grep -qs [678]) ; then ScannerDevice=sg$[ $ScannerDevice-1 ] ln -sf /dev/$ScannerDevice /dev/scanner chmod 0660 /dev/$ScannerDevice else echo "scsi remove-single-device 1 0 6 0" > /proc/scsi/scsi echo "Could not mount Scanner!" sleep 5 fi echo "Scanner mounted to $ScannerDevice" else echo "Could not mount Scanner!" sleep 5 fi fi sleep 1 -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Mailer/BBS/Fax : +49-2536-9943 (V34, X75) FidoNet: 2:2449/523 E-Mail : marcus.roeckrath@gmx.de WWW : http://home.foni.net/~marcusroeckrath/
Hallo Jens, Jens Keizer wrote:
Hallo,
Am Mon, 2003-02-10 um 10.34 schrieb Werner Franke:
Hallo zusammen, Wenn ich meinen SCSI Scanner EPSON GT-7000 bei laufenden PC einschalte und das Script 'rescan-scsi-bus.sh' (von Kurt Garloff) laufen lasse, erscheinen in '/var/log/messages' folgende Zeilen:
Feb 4 20:22:19 obelix kernel: Vendor: EPSON Model: SCANNER GT-7000 Rev: 1.14 Feb 4 20:22:19 obelix kernel: Type: Processor ANSI SCSI revision: 02 Feb 4 20:22:19 obelix kernel: Attached scsi generic sg6 at scsi0, channel 0, id 0, lun 0, type 3
Jedoch auch nach dem Umklemmen von /dev/scanner -> /dev/sg6 findet keines der Scantools (xsane, xscanimage) einen Scanner. Unter 6.4 hat ein aehnliches Vorgehen noch funktioniert.
Wenn ich meine 7.3 beim booten beobachte, setzt die noch die Rechte auf das Scanner Device neu, evtl. fehlen den Programmen ja nur die entsprechenden Rechte. Da würde ich auch mal den Vergleich zwischen den beiden Verfahren machen.
Nein, die Rechte muessten schon passen. Ich habe das extra nochmal nachgesehen, weil ich wusste, dass da auch Schreibrechte notwendig sind. 'sg6' war das gemeldete Scanner-Device beim nachtraeglichen SCSI Scan. root@obelix (bash) ls -l /dev/sg6 crw-rw-rw- 1 root disk 21, 0 Jan 19 2001 /dev/sg6 Uebrigends habe ich unter root mal versucht ueber modprobe sg ein solches Modul zu laden. Ein Modul 'sg' gibt's bei mir nicht. ???? Gruss Werner
On 10 Feb 2003 at 11:07, Werner Franke wrote: [...]
Nein, die Rechte muessten schon passen.
Laut Deiner ersten Mail waren die Rechte OK.
Ich habe das extra nochmal nachgesehen, weil ich wusste, dass da auch Schreibrechte notwendig sind. 'sg6' war das gemeldete Scanner-Device beim nachtraeglichen SCSI Scan.
root@obelix (bash) ls -l /dev/sg6 crw-rw-rw- 1 root disk 21, 0 Jan 19 2001 /dev/sg6
Uebrigends habe ich unter root mal versucht ueber
modprobe sg
ein solches Modul zu laden. Ein Modul 'sg' gibt's bei mir nicht. ????
Was denn nu? Du sagtest, das Du SCSI fest im Kernel hast. Gilt das auch für SCSI "Zusatzfeatures" wie generic-support? Das macht nämlich das Modul sg.o IMO brauchst Du den generic Support auch für den Scanner. Wenn Du den fest im Kernel hast, gibt es das Modul natürlich nicht. Da ich mit sane und Konsorten nicht arbeite (das habe ich hier auch nicht sofort ans rennen bekommen): Hast Du mal vuescan probiert? Das läuft hier astrein (http://www.hamrick.com) Andreas
Hallo Andreas, Andreas Kyek wrote:
On 10 Feb 2003 at 11:07, Werner Franke wrote:
[...]
Nein, die Rechte muessten schon passen.
Laut Deiner ersten Mail waren die Rechte OK.
Ich habe das extra nochmal nachgesehen, weil ich wusste, dass da auch Schreibrechte notwendig sind. 'sg6' war das gemeldete Scanner-Device beim nachtraeglichen SCSI Scan.
root@obelix (bash) ls -l /dev/sg6 crw-rw-rw- 1 root disk 21, 0 Jan 19 2001 /dev/sg6
Uebrigends habe ich unter root mal versucht ueber
modprobe sg
ein solches Modul zu laden. Ein Modul 'sg' gibt's bei mir nicht. ????
Was denn nu? Du sagtest, das Du SCSI fest im Kernel hast. Gilt das auch für SCSI "Zusatzfeatures" wie generic-support? Das macht nämlich das Modul sg.o
IMO brauchst Du den generic Support auch für den Scanner. Wenn Du den fest im Kernel hast, gibt es das Modul natürlich nicht.
Warscheinlich habe ich's fest reincompelliert. Aber das muss ich erst nachsehen.
Da ich mit sane und Konsorten nicht arbeite (das habe ich hier auch nicht sofort ans rennen bekommen): Hast Du mal vuescan probiert? Das läuft hier astrein (http://www.hamrick.com)
Naja, ich moechte nicht unbedingt noch'n Tool installieren. Die sane Tools arbeiten ja astrein (wenn der Scanner beim booten eingeschaltet war). Noch koennte es ja klappen, dass ich's auch noch nachtraeglich hinbekomme. Gruesse Werner
Hallo zusammen, Werner Franke wrote:
Hallo Andreas,
Andreas Kyek wrote:
On 10 Feb 2003 at 11:07, Werner Franke wrote:
[...]
Nein, die Rechte muessten schon passen.
Laut Deiner ersten Mail waren die Rechte OK.
Ich habe das extra nochmal nachgesehen, weil ich wusste, dass da auch Schreibrechte notwendig sind. 'sg6' war das gemeldete Scanner-Device beim nachtraeglichen SCSI Scan.
root@obelix (bash) ls -l /dev/sg6 crw-rw-rw- 1 root disk 21, 0 Jan 19 2001 /dev/sg6
Uebrigends habe ich unter root mal versucht ueber
modprobe sg
ein solches Modul zu laden. Ein Modul 'sg' gibt's bei mir nicht. ????
Was denn nu? Du sagtest, das Du SCSI fest im Kernel hast. Gilt das auch für SCSI "Zusatzfeatures" wie generic-support? Das macht nämlich das Modul sg.o
IMO brauchst Du den generic Support auch für den Scanner. Wenn Du den fest im Kernel hast, gibt es das Modul natürlich nicht.
Warscheinlich habe ich's fest reincompelliert. Aber das muss ich erst nachsehen.
Nachgesehen. Habe den generic Support fest reincompelliert. Hat jemand 'ne Ahnung nach was xsane eigendlich genau sucht um einen Scanner zu ermitteln ?? Vielleicht kann ich hier ansetzen ? Gruss Werner
Hallo, On Tue, 11 Feb 2003, Werner Franke wrote:
Nachgesehen. Habe den generic Support fest reincompelliert.
Hat jemand 'ne Ahnung nach was xsane eigendlich genau sucht um einen Scanner zu ermitteln ?? Vielleicht kann ich hier ansetzen ?
Versuch doch mal 'xscanimage <treiber>:/dev/sg6'. Bei Treiber eben "mustek" oder was auch immer angeben... -dnh -- Error in module Engineer: Buzzword overload. System malfunction immanent. Amok mode initiated. Please leave the building immediately. [Jochen Lillich in dasr]
Hallo David, David Haller wrote:
Hallo,
On Tue, 11 Feb 2003, Werner Franke wrote:
Hat jemand 'ne Ahnung nach was xsane eigendlich genau sucht um einen Scanner zu ermitteln ?? Vielleicht kann ich hier ansetzen ?
Versuch doch mal 'xscanimage <treiber>:/dev/sg6'. Bei Treiber eben "mustek" oder was auch immer angeben...
Danke. Das hat geholfen. Wenn ich also den Scanner erst nach dem Booten einschalte, danach den SCSI Bus neu nach neuen Geraeten scanne und aktiviere, dann funktionieren die Sane-Tools nur dann, wenn ich beim Aufruf den Treiber und das Device angebe. xsane epson:/dev/scanner xscanimage epson:/dev/scanner Habe meine KDE Icons entsprechend erweitert. Gruesse Werner Franke
Hallo Liste, hallo Werner Franke, Werner Franke:
Hallo David,
David Haller wrote:
[Tipp,wie's klappt]
Danke. Das hat geholfen. Wenn ich also den Scanner erst nach dem Booten einschalte, danach den SCSI Bus neu nach neuen Geraeten scanne und aktiviere, dann funktionieren die Sane-Tools nur dann, wenn ich beim Aufruf den Treiber und das Device angebe.
xsane epson:/dev/scanner xscanimage epson:/dev/scanner
Habe meine KDE Icons entsprechend erweitert.
Habe den Thread mit größtem Interesse verfolgt, da schon immer mit demselben Problem lebend. Allerdings: ich scan übers Netz! mmmhhhh und steh' jetzt vor dem Problem, das dem saned mitteilen zu müssen, damit der das sane entsprechend startet. Den zitierten Aufruf einfach mal so in der inetd.conf serverseitig mitgeben hatte keine Wirkung. Genauso, wie bei normalen Start nach dem scsi-scan wird der saned sofort beendet.[1] Auch nach der Ergänzung des Servereintrags in der /etc/sane.d/net.conf des client geschah nichts. Hier kam nichtmal die Anfrage beim Server an. Die man-pages geben sich recht zugeknöpft - jetzt wird's interessant! :o)) [1]server message: Feb 17 18:09:45 labor saned[10526]: init: access by saned-user@kassandra.goellesberg accepted Feb 17 18:09:45 labor saned[10526]: quit: exiting weiß da sonst noch wer was zu??
Gruesse Werner Franke
auch Gruß fs -- Beste Grüße von der Schwäbischen Alb _Das_ MailingListenarchiv für suse-linux: http://marc.theaimsgroup.com/?l=suse-linux&r=1&w=2 und viele viele andere: http://marc.theaimsgroup.com
Hallo, On Mon, 17 Feb 2003, Friedrich Strohmaier wrote:
Werner Franke:
David Haller wrote:
[Tipp,wie's klappt] [..] Habe den Thread mit größtem Interesse verfolgt, da schon immer mit demselben Problem lebend. Allerdings: ich scan übers Netz! mmmhhhh und steh' jetzt vor dem Problem, das dem saned mitteilen zu müssen, damit der das sane entsprechend startet.
Wie sieht denn die /etc/sane.d/dll.conf aus?
Den zitierten Aufruf einfach mal so in der inetd.conf serverseitig mitgeben hatte keine Wirkung. Genauso, wie bei normalen Start nach dem scsi-scan wird der saned sofort beendet.[1]
Ich verwende saned nicht und kenne mich damit gar nicht aus, aber(*g*), ich finde folgendes in der manpage: ==== /usr/local/etc/sane.d/saned.users If this file contains lines of the form user:password:backend access to the listed backends is restricted. A backend may be listed multiple times for different user/password combinations. The server uses MD5 encryption if supported by the client ==== [Note: das /usr/local faellt bei SuSE-RPMs wohl weg, die Datei waere in /etc/sane.d anzulegen] Das ":backend" ist dann genau der "Treiber", z.B. 'mustek' oder 'epson' oder oder... Achso: welches frontend verwendest du eigentlich? HTH, -dnh -- Was brauchst du Geld, wenn du dag° hast? [WoKo in dag°]
Hallo Liste, hallo David Haller, David Haller:
Hallo,
On Mon, 17 Feb 2003, Friedrich Strohmaier wrote: [..]
mit demselben Problem lebend. Allerdings: ich scan übers Netz! mmmhhhh und steh' jetzt vor dem Problem, das dem saned mitteilen zu müssen, damit der das sane entsprechend startet.
Wie sieht denn die /etc/sane.d/dll.conf aus?
na wie immer!! *dg* /etc/sane.d/dll.conf client: net /etc/sane.d/net.conf client: <server> /etc/sane.d/dll.conf server: snapscan /etc/sane.d/snapscan.conf server: /dev/sg0
Den zitierten Aufruf einfach mal so in der inetd.conf serverseitig mitgeben hatte keine Wirkung. Genauso, wie bei normalen Start nach dem scsi-scan wird der saned sofort beendet.[1]
Ich verwende saned nicht und kenne mich damit gar nicht aus, aber(*g*), ich finde folgendes in der manpage:
====
hier hörte bei mir der Bildschirm auf ;o)
/usr/local/etc/sane.d/saned.users If this file contains lines of the form
user:password:backend
access to the listed backends is restricted. A
^^^^^^^^^^^^^^ d.h ich kann die Benutzung des backends auf bestimmte Benutzer _beschränken_ - das ist nun beileibe nicht mein Problem [1]
backend may be listed multiple times for different user/password combinations. The server uses MD5 encryption if supported by the client ====
[Note: das /usr/local faellt bei SuSE-RPMs wohl weg, die Datei waere in /etc/sane.d anzulegen]
negativ!
Das ":backend" ist dann genau der "Treiber", z.B. 'mustek' oder 'epson' oder oder...
Achso: welches frontend verwendest du eigentlich?
xsane [1] hätt' ich bloß die Finger davon gelassen! - Werner, was musst Du auch mit so'n Zeug anrücken, mensch!! :o)) Jetzt tut's nämlich gar nicht mehr. message server: Feb 19 00:13:03 labor saned[1865]: connect from 192.168.22.33 (192.168.22.33) Feb 19 00:13:03 labor saned[1865]: main: starting debug mode (level 128) Feb 19 00:13:03 labor saned[1865]: main: trying to get port for service `sane' (getservbyname) Feb 19 00:13:04 labor saned[1865]: main: port is 6566 Feb 19 00:13:04 labor saned[1865]: main: socket () Feb 19 00:13:04 labor saned[1865]: main: setsockopt () Feb 19 00:13:04 labor saned[1865]: main: bind () Feb 19 00:13:04 labor saned[1865]: main: bind failed: Address already in use sagt mir schon sowas von nix Local geht's aber übers' Netz hat's jetzt aufgehört. früher sah die message immer so aus: Feb 18 01:18:27 labor saned[19337]: connect from 192.168.22.33 (192.168.22.33) Feb 18 01:18:27 labor saned[19337]: check_host: access by remote host: 192.168.22.33 Feb 18 01:18:27 labor saned[19337]: init: access by saned-user@kassandra.goellesberg accept ed
HTH,
kommt noch! %-)
-dnh
fs -- Beste Grüße von der Schwäbischen Alb _Das_ MailingListenarchiv für suse-linux: http://marc.theaimsgroup.com/?l=suse-linux&r=1&w=2 und viele viele andere: http://marc.theaimsgroup.com
Hallo, On Wed, 19 Feb 2003, Friedrich Strohmaier wrote:
David Haller:
On Mon, 17 Feb 2003, Friedrich Strohmaier wrote: [..]
mit demselben Problem lebend. Allerdings: ich scan übers Netz! mmmhhhh und steh' jetzt vor dem Problem, das dem saned mitteilen zu müssen, damit der das sane entsprechend startet.
Wie sieht denn die /etc/sane.d/dll.conf aus?
na wie immer!! *dg* /etc/sane.d/dll.conf client: net
ok, soweit ich der Doku entnehme.
/etc/sane.d/net.conf client: <server>
keine Ahnung.
/etc/sane.d/dll.conf server: snapscan ^^^^^^^^ ist das auch das richtige backend??
/etc/sane.d/snapscan.conf server: /dev/sg0
Richtiges device? [..]
/usr/local/etc/sane.d/saned.users
[..]
[Note: das /usr/local faellt bei SuSE-RPMs wohl weg, die Datei waere in /etc/sane.d anzulegen]
negativ!
Wie meinen? Ich seh oben nur /etc/sane.d/...
Das ":backend" ist dann genau der "Treiber", z.B. 'mustek' oder 'epson' oder oder...
Nochmal: teste doch mal ob eine explizite Angabe des backends in der saned.users was hilft.
Achso: welches frontend verwendest du eigentlich?
xsane
Das kenne ich leider nicht. Kannst du alternativ mal mit xscanimage testen? Das gehoert halt zu sane-frontends selbst...
[1] hätt' ich bloß die Finger davon gelassen! - Werner, was musst Du auch mit so'n Zeug anrücken, mensch!! :o)) Jetzt tut's nämlich gar nicht mehr.
message server:
Feb 19 00:13:03 labor saned[1865]: connect from 192.168.22.33 (192.168.22.33) Feb 19 00:13:03 labor saned[1865]: main: starting debug mode (level 128) Feb 19 00:13:03 labor saned[1865]: main: trying to get port for service `sane' (getservbyname) Feb 19 00:13:04 labor saned[1865]: main: port is 6566 Feb 19 00:13:04 labor saned[1865]: main: socket () Feb 19 00:13:04 labor saned[1865]: main: setsockopt () Feb 19 00:13:04 labor saned[1865]: main: bind () Feb 19 00:13:04 labor saned[1865]: main: bind failed: Address already in use
sagt mir schon sowas von nix
Das bedeutet, dass auf dem Port (6566) schon ein Programm lauscht -- vermutlich ein saned ;) Hast du da noch ne "alte" saned-Instanz am laufen? Laeuft saned eigentlich via inetd oder "standalone"? -dnh --
Ich kann mich zur not auch selber verformen. Nö, das erledige ich jetzt. *erledig* Heh! Was hast du da gemacht? Schau mal wie eingedrückt ich jetzt ausseh. *Boink! Boink! Boink! * (Nach dag° hüpf!) [WoKo und Michael Hoffmann in dag°]
Hallo Liste, hallo David Haller, Ich muss noch erwähnen, dass die Angaben in dieser und meiner letzten Mail sich auf das bei _eingeschaltetem_ Scanner gebootete System beziehen - also die Konfiguration mit der's vorher funtionierte! (um nicht alle Fehlersymptome durcheinander zu haben) David Haller:
Hallo,
On Wed, 19 Feb 2003, Friedrich Strohmaier wrote:
David Haller:
[..]
Wie sieht denn die /etc/sane.d/dll.conf aus?
na wie immer!! *dg* /etc/sane.d/dll.conf client: net
ok, soweit ich der Doku entnehme.
/etc/sane.d/net.conf client: <server>
keine Ahnung.
nach meinem Verständnis wird hier das scanner-backend "net" mit der Adresse im Netz versorgt
/etc/sane.d/dll.conf server: snapscan
^^^^^^^^ ist das auch das richtige backend??
<Ausgabe> server $ xscanimage <Inquiry-button> [snapscan] Inquiry results: Scanner: Color FlatbedScanner_90117 hardware config: 0x9d ...weitere Eigenschaften... </Ausgabe>
/etc/sane.d/snapscan.conf server: /dev/sg0
Richtiges device?
... also auch richtig?!
[..]
/usr/local/etc/sane.d/saned.users
[..]
[Note: das /usr/local faellt bei SuSE-RPMs wohl weg, die Datei waere in /etc/sane.d anzulegen]
negativ!
Wie meinen? Ich seh oben nur /etc/sane.d/...
sorry, habe die datei so angelegt, wie beschrieben ohne irgendein Resultat (keine (positive) Änderung, keine Änderung in den messages) und es hat nicht funktioniert => "negativ" habe dazu noch was interessantes gefunden in <man 5 sane-dll> ... This backend expects device names of the form: backend:device Where backend is the name of the backend and device is the name of the device in this backend that should be addressed. If the device name does not contain a colon (:), then the entire string is treated as the device string for the default backend. The default backend is the backend listed last in the configuration file (see below) or the first pre-loaded backend (if any). ... </man 5 sane-dll> Das hat doch was mit dem Ursprungsproblem zu tun -> das heißt doch, dass nach dem rescan sane dazu gebracht werden muss die /etc/sane.d/dll.conf neu einzulesen ... nicht weiter verfolgt ..
Das ":backend" ist dann genau der "Treiber", z.B. 'mustek' oder 'epson' oder oder...
Nochmal: teste doch mal ob eine explizite Angabe des backends in der saned.users was hilft.
leider nein! s.o.
Achso: welches frontend verwendest du eigentlich?
xsane
Das kenne ich leider nicht. Kannst du alternativ mal mit xscanimage testen? Das gehoert halt zu sane-frontends selbst...
oben gemacht am Server. am Client: <Ausgabe> client $ xscanimage [xscanimage] No scanners were identified. [..] </Ausgabe>
[1] hätt' ich bloß die Finger davon gelassen! - Werner, was musst Du auch mit so'n Zeug anrücken, mensch!! :o)) Jetzt tut's nämlich gar nicht mehr.
message server:
Feb 19 00:13:03 labor saned[1865]: connect from 192.168.22.33 (192.168.22.33) Feb 19 00:13:03 labor saned[1865]: main: starting debug mode (level 128) Feb 19 00:13:03 labor saned[1865]: main: trying to get port for service `sane' (getservbyname) Feb 19 00:13:04 labor saned[1865]: main: port is 6566 Feb 19 00:13:04 labor saned[1865]: main: socket () Feb 19 00:13:04 labor saned[1865]: main: setsockopt () Feb 19 00:13:04 labor saned[1865]: main: bind () Feb 19 00:13:04 labor saned[1865]: main: bind failed: Address already in use
sagt mir schon sowas von nix
Das bedeutet, dass auf dem Port (6566) schon ein Programm lauscht -- vermutlich ein saned ;)
<Ausgabe> server # netstat -n Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 192.168.22.11:1025 192.168.22.11:6010 ESTABLISHED tcp 0 0 192.168.22.11:22 192.168.22.33:36459 ESTABLISHED tcp 0 0 192.168.22.11:22 192.168.22.33:36683 ESTABLISHED tcp 0 0 192.168.22.11:22 192.168.22.33:36542 ESTABLISHED tcp 0 0 192.168.22.11:6010 192.168.22.11:1025 ESTABLISHED Active UNIX domain sockets (w/o servers) Proto RefCnt Flags Type State I-Node Path unix 9 [ ] DGRAM 1063 /dev/log unix 2 [ ] DGRAM 3744 unix 2 [ ] DGRAM 3267 unix 2 [ ] DGRAM 3186 unix 2 [ ] DGRAM 3184 unix 2 [ ] DGRAM 3174 unix 2 [ ] DGRAM 3010 unix 2 [ ] DGRAM 1634 </Ausgabe> Ich kann nix finden ...
Hast du da noch ne "alte" saned-Instanz am laufen?
<Ausgabe> server # ps -aux | grep sane root 2080 0.0 0.7 1620 556 pts/0 S 15:05 0:00 grep sane </Ausgabe> ... also nix
Laeuft saned eigentlich via inetd oder "standalone"?
inetd <Ausgabe> :o)) server # grep -v ^# /etc/inetd.conf | grep -v ^$ time stream tcp nowait root internal time dgram udp wait root internal sane stream tcp nowait root /usr/sbin/tcpd /usr/sbin/saned -s128 login stream tcp nowait root /usr/sbin/tcpd in.rlogind #ok,ok :o) </Ausgabe> mhhh immer noch interessant!! :o)) Danke mal bis hierher!
-dnh
fs -- Beste Grüße von der Schwäbischen Alb _Das_ MailingListenarchiv für suse-linux: http://marc.theaimsgroup.com/?l=suse-linux&r=1&w=2 und viele viele andere: http://marc.theaimsgroup.com
Hallo Liste, hallo Friedrich Strohmaier, hi ;o) Friedrich Strohmaier:
Hallo Liste, hallo David Haller,
Ich muss noch erwähnen, dass die Angaben in dieser und meiner letzten Mail sich auf das bei _eingeschaltetem_ Scanner gebootete System beziehen - also die Konfiguration mit der's vorher funtionierte!
(um nicht alle Fehlersymptome durcheinander zu haben)
gilt weiter! zur Technik: Gerät: Acer prisa 620s also SCSI backend:snapscan System: server: suse8.0 prof. auf cyrix 166+ (highend :o)) ) remote client: Aldi-Süd Läppi (okt 01) suse 8.0 prof. sane 1.0.7 von der DVD beide [ganz viele Informationen, die das Problem nicht erhellen konnten]
mhhh immer noch interessant!! :o)) Danke mal bis hierher!
... Heureka, ich hab's!! - Danke David für die Frage :o)) David Haller:
Laeuft saned eigentlich via inetd oder "standalone"?
inetd
<Ausgabe> :o)) server # grep -v ^# /etc/inetd.conf | grep -v ^$ time stream tcp nowait root internal time dgram udp wait root internal sane stream tcp nowait root /usr/sbin/tcpd /usr/sbin/saned -s128 ^^^^ ... </Ausgabe>
ich war damals bei der Einrichtung der Verlockung der manpage erlegen: man 1 saned: However, if your system uses tcpd(8) for additional security screening, #wer wollte das nicht!! ;o)# you may want to disable saned access control by putting ``+'' in saned.conf and use a line of the following form in /etc/inetd.conf instead: sane stream tcp nowait saned.saned /usr/sbin/tcpd saned ... das "putting ``+''.." brachte letztendlich die Erlösung von unerklärlichen Authentifizierungsanforderungen. den Weg dahin fand ich, in dem ich der Doku entlockte, wie man saned und die backends gesprächig macht: remoteClient $> SANE_DEBUG_NET=255 scanimage -L sagt so einiges, was im "net"-backend vorgeht, während scanimage die Liste der verfügbaren Scanner erstellt ... ... device `net:labor:snapscan:/dev/sg0' is a Color FlatbedScanner_9 flatbed scanner ... zeigte, dass der Scanner erreichbar war... scan eingeleitet mit remoteClient $> SANE_DEBUG_NET=255 scanimage [net].... [net] sane_open: net_open [net] sane_open: authorization required [net] do_authorization: dev=0x8051a00 resource=snapscan$MD5$14... [net] do_authorization: invoking auth_callback, resource = net:labor:snapscan$MD5$14... Authentification required for resource net:labor:snapscan. Enter username: Enter password: ..... ... wollte, dass ich mich zu erkennen gebe. Konnte aber nicht in Erfahrung bringen als wer ich gewünscht war... scanserver #> SANE_DEBUG_<DEIN_BACKEND>=255 /usr/sbin/saned -d128 macht sowohl den saned als auch .. Dein backend auskunftsfreudiger. In man sane-<dein_backend> steht Genaueres. Wie gesagt: die obige Korrektur brachte meine "Workstation" wieder an den Scanner. Drei Fragen bleiben offen: - im Standalone-modus des saned ließ sich der auth-request auch mit der beschriebenen Änderung der /etc/saned.conf nicht abstellen. - nachdem mittels der Änderung der /etc/saned.conf wieder _ein_ Scan gelaufen war, gings auch wieder mit der alten Einstellung ("+" raus erlaubter remotehost rein) - sieht nach bug aus?? - die Ursprüngliche Fragestellung: "wie geht's, wenn der Scanner erst bei hochgefahrener Maschine eingeschaltet wird" - über's Netz? ... wird nachgeliefert - falls es eilt: bitte anschreiben! uff! :o)) fs -- Beste Grüße von der Schwäbischen Alb _Das_ MailingListenarchiv für suse-linux:http://marc.theaimsgroup.com/?l=suse-linux&r=1&w=2 und viele viele andere: http://marc.theaimsgroup.com
Hallo, On Mon, 17 Feb 2003, Werner Franke wrote:
David Haller wrote:
On Tue, 11 Feb 2003, Werner Franke wrote:
Hat jemand 'ne Ahnung nach was xsane eigendlich genau sucht um einen Scanner zu ermitteln ?? Vielleicht kann ich hier ansetzen ? Versuch doch mal 'xscanimage <treiber>:/dev/sg6'. Bei Treiber eben "mustek" oder was auch immer angeben...
Danke. Das hat geholfen.
*g*
Wenn ich also den Scanner erst nach dem Booten einschalte, danach den SCSI Bus neu nach neuen Geraeten scanne und aktiviere, dann funktionieren die Sane-Tools nur dann, wenn ich beim Aufruf den Treiber und das Device angebe.
xsane epson:/dev/scanner xscanimage epson:/dev/scanner
Spricht ja eigentlich auch nix dagegen, das generell so zu verwenden. Nochmal fuer's Archiv: die Syntax ist: xscanimage <treiber>:<device> (wobei dies offenbar auch fuer 'xsane' und wohl auch 'scanimage' gilt).
Habe meine KDE Icons entsprechend erweitert.
*g* -dnh -- Wer unkasprige Kaspereien verbreitet darf sich nicht wundern wenn der grosse Kasper mit der Klatsche zuschlägt. [Woko° in dag°]
Hallo, Am Die, 2003-02-18 um 01.15 schrieb David Haller:
Hallo,
On Mon, 17 Feb 2003, Werner Franke wrote:
David Haller wrote:
On Tue, 11 Feb 2003, Werner Franke wrote:
Hat jemand 'ne Ahnung nach was xsane eigendlich genau sucht um einen Scanner zu ermitteln ?? Vielleicht kann ich hier ansetzen ? Versuch doch mal 'xscanimage <treiber>:/dev/sg6'. Bei Treiber eben "mustek" oder was auch immer angeben...
Danke. Das hat geholfen.
*g*
Wenn ich also den Scanner erst nach dem Booten einschalte, danach den SCSI Bus neu nach neuen Geraeten scanne und aktiviere, dann funktionieren die Sane-Tools nur dann, wenn ich beim Aufruf den Treiber und das Device angebe.
xsane epson:/dev/scanner xscanimage epson:/dev/scanner
Spricht ja eigentlich auch nix dagegen, das generell so zu verwenden.
Nochmal fuer's Archiv: die Syntax ist:
xscanimage <treiber>:<device>
(wobei dies offenbar auch fuer 'xsane' und wohl auch 'scanimage' gilt).
Habe meine KDE Icons entsprechend erweitert.
Nur eine Idee, konnte das noch nicht prüfen: Nach dem BUS-Scan eventuell 'sane-find-scanner' eingeben und mal versuchen, ob du den Treiber oder das Device noch angeben mußt?! Gruß Jens
Hallo Werner, Ich verstehe es so das du nach dem Booten den Scsi Scanner einshalten willst. Ich habe aus den netzt ein scanner für den Bus so kann ich auch externe Festplatten und Scanner nach bedarf einschalten. Wenn du die shell brauchst kann ich Sie dir senden. Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
participants (7)
-
Andreas Kyek -
David Haller -
Friedrich Strohmaier -
Marcus Roeckrath -
Patrice Staudt -
the_Q＠t-online.de -
Werner Franke