Am Wed, 29 Nov 2023 10:50:23 +0100 schrieb Herbert Albert :

Am Mittwoch, 29. November 2023, 06:51:43 CET schrieb Manfred Haertel, DB3HM:

...

Herbert Albert schrieb:

...

Warum funktionieren die ganzen sane basierten Mechanismen nicht mehr? Was muss in den Dateien unter /etc/sane.d eingetragen werden? Liegt das an der LAN/WLAN Anbindung?

...

ich habe mir das Paket sane-airscan-git202301107-lp154.1.1.x86_64.rpm von home:Sauerland auf dem Testrechner mit leap 15.5 installiert. Es funktioniert auch mit allen sane basierten Anwendungen. Der Epson XP-800 meldet sich mit WSD (er ist per WLAN angebunden), der Epson WF-C5790BA meldet sich mit eSCL (er ist mit LAN angebunden). Leider hat das keinen Einfluss auf vuescan, da Ed Hamrick anders auf die Scanner zugreift. Ich muss sicherstellen, dass nach einen Upgrade meines Arbeitsrechners auf leap 15.5 vuescan mit den Scannern kommuniziert. Die sane basierten Applikationen sind mir nicht so wichtig, da vuescan hier mehr kann und ich es auch mit einem DiaScanner verwende.

Ich verstehe dein Problem nicht. Vuescan nutzt AFAIK keine Treiber von sane - das Teil bringt seine eigenen Treiber mit. Wenn das unter deiner jetzigen Version funktioniert das geht es auch mit einer anderen - solange Vuescan nur überhaupt läuft. Ich hatte Vuescan unter anderen mit 15.4, 15.5 und Tumbleweed laufen (allerdings anderer Scanner; aber das Programm selber läuft). Warum siehst du da ein Problem? Andreas

Am Wed, Nov 29, 2023 at 04:05:58PM +0100 schrieb Herbert Albert:

ich habe mich vielleicht nicht klar genug ausgedrückt. Bevor ich auf meinem Arbeitsrechner ein leap Upgrade durchführe, möchte ich, soweit wie möglich, abklopfen, wie das Upgrade abläuft und ob meine hauptsächlich benutzen Programme noch funktionieren. Natürlich habe ich keine 1 zu 1 Kopie von meinen Rechner, sonder teste das auf einem alten Notebook. Auf dem habe ich leap hochgezogen, was auch gut funktioniert hat. Doch nach dem Upgrade habe ich eben festgestellt, dass unter leap 15.5 vuescan meine beiden Geräte nicht mehr wie unter leap 15.4 erkennt. Und das macht mich stutzig, ob es dann nicht auch bei meinen Arbeitsrechner passieren könnte.

Zumindest ich habe das schon so verstanden. Ich weiß allerdings nicht, was Du jetzt von der Liste hier erwartest. Bei komerzieller Software würde ich mich im Zweifel an den Hersteller wenden. Viele Grüße Ulf

Am Wed, 29 Nov 2023 19:48:51 +0100 schrieb Herbert Albert : [...]

die Frage war, ob jemand unter leap 15.5 vuescan mit einem Netzwerkscanner erfolgreich betreibt. Wenn ja, musste derjenige nach dem Upgrade evtl. etwas anpassen/ändern.

Ja - schrieb ich aber schon (dachte ich). VueScan läuft hier mit einem TR8500 übers Netz (WLAN) sowohl von Leap 15.5 als auch über Tumbleweed. Andreas

Am Donnerstag, 30. November 2023, 11:49:42 CET schrieb Herbert Albert:

Am Donnerstag, 30. November 2023, 10:11:18 CET schrieb Andreas Kyek:

...

Am Wed, 29 Nov 2023 19:48:51 +0100 schrieb Herbert Albert :

[...]

...

die Frage war, ob jemand unter leap 15.5 vuescan mit einem Netzwerkscanner erfolgreich betreibt. Wenn ja, musste derjenige nach dem Upgrade evtl. etwas anpassen/ändern.

Ja - schrieb ich aber schon (dachte ich).

VueScan läuft hier mit einem TR8500 übers Netz (WLAN) sowohl von Leap 15.5 als auch über Tumbleweed.

Andreas

Hallo Andreas,

vuescan liefert ja nur 3 Dateien aus, die lt. README.txt dahin müssen: sudo cp vuescan.svg /usr/share/icons/hicolor/scalable/apps/ sudo cp vuescan.rul /lib/udev/rules.d/60-vuescan.rules sudo cp vuescan /usr/bin/

danach soll sudo udevadm control --reload-rules ausgeführt werden.

Ich nehme immer das rpm-Paket bei dem das per rpm-Skript erledigt wird.

Was mich wundert und was mir Ed Hamrick auch noch nicht beantwortet hat ist, wie wird auf Netzwerkscanner zugegriffen.

Wenn ich mir die Datei /lib/udev/rules.d/60-vuescan.rules ansehe, finde ich auch meine beiden Scanner, die aber wie alle mit Subsystem USB darin stehen. # Epson XP-800 SUBSYSTEMS=="usb", ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="089b", MODE="0666"

Was ist, wenn ein Gerät per WLAN/LAN angesprochen wird. Auf meinen Arbeitsrechner funktioniert das ja auch unter leap 15.4. Habe nur Angst, dass nach dem Upgrade auf 15.5 es nicht mehr funktioniert.

Gruß

Herbert Jetzt hat mir Ed Hamrick (vuescan) geantwortet die Datei /lib/udev/rules.d/60-vuescan.rules ist nur für USB. "The rules file is only for USB scanners."

Auf meine Farge, wie er den WLAN/LAN Geräte anspricht, kam die Anwort "mDNS" Wenn mDNS auf meinen Arbeitsrechner funktioniert und auf dem Testrechner nicht, wie kann ich das feststellen. Ist das eine Sache der Konfiguration oder ein Unterschied zwischen leap 15.5 (durch das Upgrade verusacht?) und leap 15.4? ein systemctl status avahi-daemon.service liefert auf dem Arbeitsrechner: avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2023-11-30 10:49:56 CET; 2h 42min ago TriggeredBy: ● avahi-daemon.socket Main PID: 916 (avahi-daemon) Status: "Server startup complete. Host name is wodan2.local. Local service cookie is 3099160620." Tasks: 1 (limit: 4915) CGroup: /system.slice/avahi-daemon.service └─ 916 "avahi-daemon: running [wodan2.local]" Auf dem Testrechner: avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2023-11-30 12:32:44 CET; 1h 1min ago TriggeredBy: ● avahi-daemon.socket Main PID: 646 (avahi-daemon) Status: "Server startup complete. Host name is r560.local. Local service cookie is 148664960." Tasks: 1 (limit: 4652) CGroup: /system.slice/avahi-daemon.service └─ 646 "avahi-daemon: running [r560.local]" In /etc/nsswitch.conf steht auf beiden Rechnern u.a. hosts: files mdns_minimal [NOTFOUND=return] dns wins networks: files dns Auf dem Arbeitsrechner ist dazu installiert: nss-*mdns*-0.14.1-150400.8.6.x86_64 nss-*mdns*-32bit-0.14.1-150400.8.6.x86_64 avahi-compat-*mDNS*Responder-devel-0.8-150400.7.10.1.x86_64 Auf dem Testrechner habe ich avahi-compat-*mDNS*Responder-devel-0.8-150400.7.10.1.x86_64 nachinstalliert. Bewirkt aber erst einmal auch nicht, es sei denn ich muss neu starten. Aber da kenne ich mich zu wenig aus.

Am Donnerstag, 30. November 2023, 15:03:57 CET schrieb Ulf Volmer:
> Am 30.11.23 um 13:50 schrieb Herbert Albert:
> > Auf meine Farge, wie er den WLAN/LAN Geräte anspricht, kam die Anwort
> > 
> > "mDNS"
> 
> Kommt bei
> 
> 
> avahi-browse --all
> 
> 
> irgendwas sinnvolles zurück?
Testrechner:
~> avahi-browse --all
+  wlan0 IPv6 EPSON WF-C5790BA                              Microsoft Windows Network local
+  wlan0 IPv4 EPSON WF-C5790BA                              Microsoft Windows Network local
+  wlan0 IPv6 EPSON WF-C5790BA                              _uscans._tcp         local
+  wlan0 IPv4 EPSON WF-C5790BA                              _uscans._tcp         local
+  wlan0 IPv6 EPSON WF-C5790BA                              _uscan._tcp          local
+  wlan0 IPv4 EPSON WF-C5790BA                              _uscan._tcp          local
+  wlan0 IPv6 EPSON WF-C5790BA                              _privet._tcp         local
+  wlan0 IPv4 EPSON WF-C5790BA                              _privet._tcp         local
+  wlan0 IPv6 EPSON WF-C5790BA                              Secure Internet Printer local
+  wlan0 IPv4 EPSON WF-C5790BA                              Secure Internet Printer local
+  wlan0 IPv6 EPSON WF-C5790BA                              Internet Printer     local
+  wlan0 IPv4 EPSON WF-C5790BA                              Internet Printer     local
+  wlan0 IPv6 EPSON WF-C5790BA                              _scanner._tcp        local
+  wlan0 IPv4 EPSON WF-C5790BA                              _scanner._tcp        local
+  wlan0 IPv6 EPSON WF-C5790BA                              Web-Angebot          local
+  wlan0 IPv4 EPSON WF-C5790BA                              Web-Angebot          local
+  wlan0 IPv6 EPSON WF-C5790BA                              PDL Printer          local
+  wlan0 IPv4 EPSON WF-C5790BA                              PDL Printer          local
+  wlan0 IPv6 EPSON WF-C5790BA                              UNIX Printer         local
+  wlan0 IPv4 EPSON WF-C5790BA                              UNIX Printer         local
+  wlan0 IPv4 EPSON XP-800 Series                           UNIX Printer         local
+  wlan0 IPv4 EPSON XP-800 Series                           PDL Printer          local
+  wlan0 IPv4 EPSON XP-800 Series                           Web-Angebot          local
+  wlan0 IPv4 EPSON XP-800 Series                           _scanner._tcp        local
+  wlan0 IPv4 EPSON XP-800 Series                           Internet Printer     local
+  wlan0 IPv4 EPSON XP-800 Series                           Microsoft Windows Network local
+  wlan0 IPv6 EPSON XP-800 Series                           UNIX Printer         local
+  wlan0 IPv6 EPSON XP-800 Series                           PDL Printer          local
+  wlan0 IPv6 EPSON XP-800 Series                           Web-Angebot          local
+  wlan0 IPv6 EPSON XP-800 Series                           _scanner._tcp        local
+  wlan0 IPv6 EPSON XP-800 Series                           Internet Printer     local
+  wlan0 IPv6 EPSON XP-800 Series                           Microsoft Windows Network local

Arbeitsrechner:
~> avahi-browse --all
+   eth0 IPv6 EPSON WF-C5790BA                              _uscans._tcp         local
+   eth0 IPv4 EPSON WF-C5790BA                              _uscans._tcp         local
+   eth0 IPv6 EPSON WF-C5790BA                              _uscan._tcp          local
+   eth0 IPv4 EPSON WF-C5790BA                              _uscan._tcp          local
+   eth0 IPv6 EPSON WF-C5790BA                              _privet._tcp         local
+   eth0 IPv4 EPSON WF-C5790BA                              _privet._tcp         local
+   eth0 IPv6 EPSON WF-C5790BA                              Secure Internet Printer local
+   eth0 IPv4 EPSON WF-C5790BA                              Secure Internet Printer local
+   eth0 IPv6 EPSON WF-C5790BA                              Internet Printer     local
+   eth0 IPv6 EPSON XP-800 Series                           Internet Printer     local
+   eth0 IPv4 EPSON WF-C5790BA                              Internet Printer     local
+   eth0 IPv4 EPSON XP-800 Series                           Internet Printer     local
+   eth0 IPv6 EPSON WF-C5790BA                              _scanner._tcp        local
+   eth0 IPv6 EPSON XP-800 Series                           _scanner._tcp        local
+   eth0 IPv4 EPSON WF-C5790BA                              _scanner._tcp        local
+   eth0 IPv4 EPSON XP-800 Series                           _scanner._tcp        local
+   eth0 IPv6 EPSON WF-C5790BA                              Web-Angebot          local
+   eth0 IPv6 EPSON XP-800 Series                           Web-Angebot          local
+   eth0 IPv4 EPSON WF-C5790BA                              Web-Angebot          local
+   eth0 IPv4 EPSON XP-800 Series                           Web-Angebot          local
+   eth0 IPv6 EPSON WF-C5790BA                              PDL Printer          local
+   eth0 IPv6 EPSON XP-800 Series                           PDL Printer          local
+   eth0 IPv4 EPSON WF-C5790BA                              PDL Printer          local
+   eth0 IPv4 EPSON XP-800 Series                           PDL Printer          local
+   eth0 IPv6 EPSON WF-C5790BA                              UNIX Printer         local
+   eth0 IPv6 EPSON XP-800 Series                           UNIX Printer         local
+   eth0 IPv4 EPSON WF-C5790BA                              UNIX Printer         local
+   eth0 IPv4 EPSON XP-800 Series                           UNIX Printer         local
+   eth0 IPv6 EPSON WF-C5790BA                              Microsoft Windows Network local
+   eth0 IPv6 EPSON XP-800 Series                           Microsoft Windows Network local
+   eth0 IPv4 EPSON WF-C5790BA                              Microsoft Windows Network local
+   eth0 IPv4 EPSON XP-800 Series                           Microsoft Windows Network local

> 
> Bist Du im selben Netz wie Dein Drucker?

ja

> 
> Läßt die Firewall Deines PC port 5353/udp ausgehend durch?

wie prüfe ich das? 
lsof -i -P -n
zeigt den Port auf beiden Rechnern nicht an.

> 
> 
> Viele Grüße
> 
> Ulf

Herbert Albert schrieb:

Testrechner:

~> avahi-browse --all

+  wlan0 IPv6 EPSON WF-C5790BA                              Microsoft Windows Network local +  wlan0 IPv4 EPSON WF-C5790BA                              Microsoft Windows Network local [...]

avahi geht also und die Scanner sind auch sichtbar, also können wir alle netzwerk-technischen möglichen Besonderheiten ausschließen. Es ist also wahrscheinlicher geworden, dass der Fehler irgendwo in der Ecke mit den Libraries liegt. Laut gedacht: Vielleicht zieht sich ja Vuescan die Avahi-Libraries mit dlopen und da ist irgendwas nicht so wie Vuescan es erwartet (neue Library-Versionen?) - oder irgendwas in der Art. Starte doch mal vuescan aus einem Terminalfenster (xterm, KDE konsole usw.). Gibt es irgendwelche Fehlermeldungen aus? Außerdem kannst Du noch folgendes aus dem Terminalfenster probieren: strace -f vuescan 2>&1 | grep avahi Mal unterstellt, dass das vuescan-Binary auch vuescan heißt, sonst den richtigen Binary-Namen verwenden. Evtl. muss man vorher noch strace installieren. Was wird hier ausgegeben? -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Herbert Albert schrieb:

vuescan liefert auf der Konsole keine Output.

Hier mal ein Ausschnitt von log-File. [...]

Tja, da sehen wir im Prinzip nur auch wieder, dass der Testrechner per mDNS eben nichts findet - was wir ja eigentlich schon wissen. Leider ohne irgendeine Fehlermeldung, die auf die Ursachen hindeuten könnte. Ich glaube immer noch, dass Vuescan die Abfrage per mDNS gar nicht wirklich ausführt, weil irgendwas auf dem Weg dahin nicht stimmt. Versuch doch bitte mal mit strace-Kommando auszuführen. Da sehen wir vielleicht mehr. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Herbert Albert schrieb:

strace -f vuescan 2>&1 | grep avahi

liefert auf beiden Rechnern keine Rückmeldung

Das verstehe ich nicht. Bei mir liefert ein strace -f simple-scan 2>&1 | grep avahi wobei simple-scan eben ein auf Sane basierendes Scantool ist folgenden Output: [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-common.so.3", O_RDONLY|O_CLOEXEC [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-client.so.3", O_RDONLY|O_CLOEXEC Und das ist eigentlich auch logisch, denn um avahi-Abfragen zu machen, sollte ich auch die avahi-Libraries "anziehen". Na ja, eine kommerzielle Software wie vuescan macht hier sicherlich was krudes, bringt vielleicht seine eigene mDNS-Implementierung mit. Dann bin ich mit meinem Latein am Ende - fast! Mach doch mal ein: ldd `which vuescan` -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Manfred Kreisl schrieb:

...

Mach doch mal ein:

ldd `which vuescan`

Wenn ich so ne Software erstellen würde würde ich die statisch linken. Da hätte man dann wenigstens das Theater mit Libraryinkompatibilitäten nicht

Die Zeiten der statischen Binaries sind eigentlich vorbei. Denn das macht mittlerweile die Binaries unhandlich riesig. Heute wird es meistens so gemacht, dass kommerzielle Software alle "kritischen" Libraries selber auf eigenen Verzeichnissen mitbringt und meist direkt gegen diese Libraries und eben nicht gegen die auf dem normalen System-Verzeichnissen gelinkt ist. Die krudere Variante ist ein Wrapper, der LD_LIBRARY_PATH auf das eigene Verzeichnis setzt. Und die Zukunft sind eben die Container - da ist das Mitbringen eigener Libraries sogar Konzept. Was dabei übersehen wird ist dass man eben auch Interprozess-Kommunikation machen muss - um mDNS-Abfragen zu machen eben auch mit dem avahi-daemon. Und selbst wenn vuescan eine eigene libavahi-common.so mitbringt, kann es sein, dass diese eben nicht mehr so richtig mit dem avahi-daemon kann, weil es hier in der Interprozess-Kommunikation eine inkompatible Änderung gab. Sollte dies der Fall sein, kann wirklich nur noch der Software-Ersteller selber weiterhelfen. Daher wollte ich mal wissen, gegen was vuescan gelinkt ist - wobei vuescan natürlich auch ein Bash-Script sein könnte, dann müsste man mal ein sh -x vuescan machen um den Namen des richtigen Binaries zu sehen - oder man schaut mal mit "ps ax" in die Prozess-Tabelle. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Am Samstag, 2. Dezember 2023, 18:54:03 CET schrieb Manfred Haertel, DB3HM:

Herbert Albert schrieb:

...

strace -f vuescan 2>&1 | grep avahi

liefert auf beiden Rechnern keine Rückmeldung

Das verstehe ich nicht. Bei mir liefert ein

strace -f simple-scan 2>&1 | grep avahi

wobei simple-scan eben ein auf Sane basierendes Scantool ist folgenden Output:

[pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-common.so.3", O_RDONLY|O_CLOEXEC [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-client.so.3", O_RDONLY|O_CLOEXEC

Und das ist eigentlich auch logisch, denn um avahi-Abfragen zu machen, sollte ich auch die avahi-Libraries "anziehen".

Na ja, eine kommerzielle Software wie vuescan macht hier sicherlich was krudes, bringt vielleicht seine eigene mDNS-Implementierung mit. Dann bin ich mit meinem Latein am Ende - fast!

Mach doch mal ein:

ldd `which vuescan` Zur Vollständigkeit halber Arbeitsrechner: ~> ldd `which vuescan` linux-vdso.so.1 (0x00007ffd94d64000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd15dcec000) libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007fd15b800000) libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007fd15b400000) libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007fd15b000000) libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007fd15ac00000) libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007fd15a800000) libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007fd15a400000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fd15a000000) libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007fd159c00000) libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007fd15dc89000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fd159800000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fd15becb000) libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007fd15ae1e000) libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007fd15dc7e000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fd15dc79000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fd15b6bf000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007fd159400000) libudev.so.1 => /usr/lib64/libudev.so.1 (0x00007fd15be94000) libz.so.1 => /lib64/libz.so.1 (0x00007fd15dc5f000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fd1591bb000) libm.so.6 => /lib64/libm.so.6 (0x00007fd15b2b4000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd15be70000) libc.so.6 => /lib64/libc.so.6 (0x00007fd159609000) /lib64/ld-linux-x86-64.so.2 (0x00007fd15dd6f000) libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007fd15dc58000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fd158e00000) libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007fd158a00000) libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fd158600000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007fd158200000) libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007fd157e00000) libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007fd157a00000) libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007fd157600000) libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007fd157200000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007fd156e00000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fd156a00000) libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fd156600000) libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00007fd156200000) libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007fd15aadb000) libfribidi.so.0 => /usr/lib64/libfribidi.so.0 (0x00007fd155e00000) libthai.so.0 => /usr/lib64/libthai.so.0 (0x00007fd155a00000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fd155600000) libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007fd155200000) libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007fd154e00000) libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 (0x00007fd154a00000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fd154600000) libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007fd154200000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fd153e00000) libffi.so.7 => /usr/lib64/libffi.so.7 (0x00007fd153a00000) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007fd153600000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fd153200000) libmount.so.1 => /usr/lib64/libmount.so.1 (0x00007fd15b255000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fd152e00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fd15be58000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007fd152a00000) librt.so.1 => /lib64/librt.so.1 (0x00007fd15dc44000) libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007fd152600000) libdatrie.so.1 => /usr/lib64/libdatrie.so.1 (0x00007fd152200000) libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007fd151e00000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fd151a00000) libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007fd151600000) libblkid.so.1 => /usr/lib64/libblkid.so.1 (0x00007fd15aa87000)

Testrechner: r560:~> ldd `which vuescan` linux-vdso.so.1 (0x00007ffe275da000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0dd272e000) libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f0dd0200000) libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f0dcfe00000) libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007f0dcfa00000) libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f0dcf600000) libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f0dcf200000) libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007f0dcee00000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f0dcea00000) libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f0dce600000) libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f0dd26cb000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f0dce200000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f0dd08cb000) libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f0dcf81e000) libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f0dd26c0000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f0dd26bb000)

Am Samstag, 2. Dezember 2023, 21:55:42 CET schrieb Herbert Albert:

Am Samstag, 2. Dezember 2023, 18:54:03 CET schrieb Manfred Haertel, DB3HM:

...

Herbert Albert schrieb:

...

strace -f vuescan 2>&1 | grep avahi

liefert auf beiden Rechnern keine Rückmeldung

Das verstehe ich nicht. Bei mir liefert ein

strace -f simple-scan 2>&1 | grep avahi

wobei simple-scan eben ein auf Sane basierendes Scantool ist folgenden Output:

[pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-common.so.3", O_RDONLY|O_CLOEXEC [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-client.so.3", O_RDONLY|O_CLOEXEC

Und das ist eigentlich auch logisch, denn um avahi-Abfragen zu machen, sollte ich auch die avahi-Libraries "anziehen".

Na ja, eine kommerzielle Software wie vuescan macht hier sicherlich was krudes, bringt vielleicht seine eigene mDNS-Implementierung mit. Dann bin ich mit meinem Latein am Ende - fast!

Mach doch mal ein:

ldd `which vuescan`

sorry, war das falsche Kommando.

auf dem Arbeitsrechner unter leap 15.4: :~> strace -f simple-scan 2>&1 | grep avahi

[pid 14966] openat(AT_FDCWD, "/usr/lib64/lib*avahi*-common.so.3", O_RDONLY| O_CLOEXEC [pid 14966] openat(AT_FDCWD, "/usr/lib64/lib*avahi*-client.so.3", O_RDONLY|O_CLOEXEC [ und es geht die GUI "Document-Scanner" auf

Auf dem Testrechner unter leap 15.5: kommt keinerlei Rückmeldung. Bin jetzt auf dem Testrechner nochmals die Firewall durchgegangen und habe bemerkt, dass die wohl nicht automatisch beim start gestartet wird. Nun sagt auch strace -f simple-scan 2>&1 | grep avahi etwas und es geht die GUI von "Document-Scanner" auf @r560:~> cat output_simple-scan.txt r560:~> strace -f simple-scan 2>&1 | grep avahi [pid 4753] execve("/bin/sh", ["sh", "-c", "which avahi-browse > /dev/null"], 0x7ffe8aff8598 /* 106 vars */ [pid 4754] execve("/usr/bin/which", ["which", "avahi-browse"], 0x559019584ee0 /* 106 vars */) = 0

Doch an vuescan ändert das nichts.

Herbert Albert schrieb:

:~> strace -f simple-scan 2>&1 | grep avahi [pid 14966] openat(AT_FDCWD, "/usr/lib64/lib*avahi*-common.so.3", O_RDONLY|O_CLOEXEC [pid 14966] openat(AT_FDCWD, "/usr/lib64/lib*avahi*-client.so.3", O_RDONLY|O_CLOEXEC

Ja, simple-scan "zieht" die Libraries, aber vuescan eben nicht. vuescan scheint gemäß dem ldd-Output auch nicht dynamisch gegen libavahi-*.so gelinkt zu sein. vuescan könnte dann immer noch statisch gegen die avahi-Libraries gelinkt sein oder eine eigene mDNS-Implementierung benutzen. Aber mir gehen so langsam die Ideen aus, was man aus der Ferne da noch checken könnte. Was in Deinem Netzwerk so passiert, ist mir auch ein großes Rätsel, bei dem anderen Thread komme ich ehrlich gesagt nicht mehr mit bei den vielen Mails. Wieso sollte eine feste IP in Deinem Netzwerk den Zugriff auf bestimmte Dienste im Internet unmöglich machen? Das eine hat mit dem anderen nichts zu tun. Aber wenn Sane ja geht, hat dieses Problem ja wohl nichts mit dem Netzwerk zu tun. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Herbert Albert schrieb:

Auf meine Farge, wie er den WLAN/LAN Geräte anspricht, kam die Anwort "mDNS"

Wenn mDNS auf meinen Arbeitsrechner funktioniert und auf dem Testrechner nicht, wie kann ich das feststellen. Ist das eine Sache der Konfiguration oder ein Unterschied zwischen leap 15.5 (durch das Upgrade verusacht?) und leap 15.4?

OK, das mit Multicast-DNS klingt doch nach einer Spur, wie heute morgen schon vermutet. Eigentlich muss man bei einem Opensuse-System gar nichts besonderes machen, dass avahi läuft. Wenn man eine normale Workstation-Installation macht, wird das Paket avahi installiert und läuft einfach. Man muss auch eigentlich nichts konfigurieren. Das ist ja eigentlich der "Witz" an avahi bzw. Multicast-DNS. Man muss nichts konfigurieren und schon gar keinen DNS-Server und trotzdem können sich Geräte, die im Prinzip variable IPs haben können, sich gegenseitig über bestimmte DNS-Knotennamen finden. Letztendlich sagt der Scanner, er hieße _uscan._tcp.local oder so ähnlich. Und da gehen die Probleme schon mal los, es gibt nämlich mehrere Konventionen. Der Scanner verewigt sich meist mit mehreren Namen und die Software fragt mehrere Namen ab, in der Hoffnung, eine nichtleere Schnittmenge zu finden. :-) Das wird es aber wahrscheinlich nicht sein, denn warum sollte Vuescan unter 15.5 andere Namen abfragen als unter 15.4? Es wird schon irgendwas anderes sein, vermutlich irgendein subtiler unerwarteter Unterschied. Kannst Du wireshark bedienen? Dann mach mal einen Trace insbesondere vom nicht funktionierenden Fall und schaue dann mal besonders nach Port 5353 für Multicast-DNS und natürlich nach der IP des Scanners. Gerne darfst Du mir auch das Capture-File schicken. Ich vermute mal, dass im Trace irgendwas erhellendes auftaucht, an was im Moment keiner denkt... -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Am Mittwoch, 29. November 2023, 14:46:16 CET schrieb Andreas Kyek:

Am Wed, 29 Nov 2023 10:50:23 +0100

schrieb Herbert Albert :

...

Am Mittwoch, 29. November 2023, 06:51:43 CET schrieb Manfred Haertel,

DB3HM:

...

Herbert Albert schrieb:

...

Warum funktionieren die ganzen sane basierten Mechanismen nicht mehr? Was muss in den Dateien unter /etc/sane.d eingetragen werden? Liegt das an der LAN/WLAN Anbindung?

...

...

ich habe mir das Paket sane-airscan-git202301107-lp154.1.1.x86_64.rpm von home:Sauerland auf dem Testrechner mit leap 15.5 installiert. Es funktioniert auch mit allen sane basierten Anwendungen. Der Epson XP-800 meldet sich mit WSD (er ist per WLAN angebunden), der Epson WF-C5790BA meldet sich mit eSCL (er ist mit LAN angebunden). Leider hat das keinen Einfluss auf vuescan, da Ed Hamrick anders auf die Scanner zugreift. Ich muss sicherstellen, dass nach einen Upgrade meines Arbeitsrechners auf leap 15.5 vuescan mit den Scannern kommuniziert. Die sane basierten Applikationen sind mir nicht so wichtig, da vuescan hier mehr kann und ich es auch mit einem DiaScanner verwende.

Ich verstehe dein Problem nicht.

Vuescan nutzt AFAIK keine Treiber von sane - das Teil bringt seine eigenen Treiber mit.

Wenn das unter deiner jetzigen Version funktioniert das geht es auch mit einer anderen - solange Vuescan nur überhaupt läuft.

vuescan läuft ja auch auf dem Testrechner, erkennt aber außer der Notbook- Kamera nichts.

Ich hatte Vuescan unter anderen mit 15.4, 15.5 und Tumbleweed laufen (allerdings anderer Scanner; aber das Programm selber läuft).

war das ein dierkt angeschlossener Scanner oder via Netzwerk? Denn via Netzwerk funktioniert mit dem Testrechner unter leap 15.5 eben nicht. Wobei sich beide z.B. mit Imagescan ansprechen lassen oder auch das Druck funktioniert, sind also prinzipiell für den Testrechner verfügbar.

Warum siehst du da ein Problem?

Andreas

Halllo Manfred, Am Donnerstag, 30. November 2023, 05:38:01 CET schrieb Manfred Haertel, DB3HM:

Herbert Albert schrieb:

...

Am Mittwoch, 29. November 2023, 06:51:43 CET schrieb Manfred Haertel, DB3HM:

...

Herbert Albert schrieb:

...

Warum funktionieren die ganzen sane basierten Mechanismen nicht mehr? Was muss in den Dateien unter /etc/sane.d eingetragen werden? Liegt das an der LAN/WLAN Anbindung?

Ich kenne die Epson-Scanner nicht, aber die meisten aktuellen Netzwerk-Scanner und Netzwerk-Multifunktionsgeräte funktionieren prima mit sane-airscan, da sie typischerweise (auch) eSCL oder WSD (oder beides) unterstützen und sane-airscan beide Protokolle implementiert.

Zwar liefern die meisten Hersteller von Scannern und MFP mittlerweile einen nicht quelloffenen Linux-"Treiber" für Sane mit, aber der ist - logischerweise, wegen Abhängigkeiten zu etlichen System-Bibliotheken - nicht unbedingt upgrade-stabil, wenn er denn überhaupt richtig funktioniert (außer in trivialen Umgebungen). Und schlecht oder gar nicht dokumentiert ist er meist noch obendrein.

sane-airscan funktioniert auch im Gegensatz zur mitgelieferten Software prima mit meinem neuen HP-MFP. Leider ist es in den Suse-Standard-Repos nicht enthalten, aber man kann es ohne jegliche Probleme von github holen und selber compilieren. Und das Tool wird auch gepflegt.

Also wenn die Epson-Scanner eSCL oder WSD können, wäre sane-airscan ein guter Weg.

Hallo Manfred,

ich habe mir das Paket sane-airscan-git202301107-lp154.1.1.x86_64.rpm von home:Sauerland auf dem Testrechner mit leap 15.5 installiert. Es funktioniert auch mit allen sane basierten Anwendungen. Der Epson XP-800 meldet sich mit WSD (er ist per WLAN angebunden), der Epson WF-C5790BA meldet sich mit eSCL (er ist mit LAN angebunden). Leider hat das keinen Einfluss auf vuescan, da Ed Hamrick anders auf die Scanner zugreift.

Auch ich hatte schon verstanden, dass Deine Hauptfrage war, warum Vuescan nicht auf dem Testrechner läuft.

vuescan als solches läuft ja, findet nur keine Scanner.

Ich war mir allerdings schon sehr sicher, dass Deine Nebenfrage war, warum Sane in Verbindung mit den beiden Scannern nicht läuft (siehe die Zitate oben). Nur diese konnte ich Dir beantworten und offensichtlich hat das ja auch funktioniert.

Darauf bin ich nur gekommen, nachdem vuescan nicht funktioniert hat. Habe aber gesehen, dass es mit imagescan und Epson epsonscan2 (hier nur der neuere WF- C5790) funktioniert und mit sane nicht. Also waren die Scanner prinzipiell vom Testrechner her erreichbar. Drucken hat ja auch sofort funktioniert.

Vuescan kenne ich nicht. Das ist eine kommerzielle Software und dafür sollte es auch Support geben, der in Anspruch zu nehmen wäre, wenn diese nicht läuft.

Bin mit Ed Hamrick schon im Austausch, doch die Antworten sind sehr knapp (... führe das aus, was in der README.txt steht, etc.) und haben mich noch nicht weitergebracht.

Wie gesagt, ich bin mit kommerzieller Software unter Linux immer vorsichtig. Nicht aus dogmatischen Gründen, sondern aus Erfahrung. Es gibt da immer mal wieder Probleme mit Abhängigkeiten zu Libraries oder Diensten auf dem Rechner. Und wenn die kommerzielle Software mal nicht läuft, hat man mangels Information über die Internas wenig Ansätze den Fehler zu suchen, selbst wenn man den Rechner vor sich hat.

Ich bin da auch skeptisch, da ich aber viele Bilder und Dias digitalisiere bin ich mit vuescan hoch zufrieden, auch wenn es manchmal die Verbindung zu meinen Diascanner mitten im Scan verliert. Aber da meint Ed, dass evtl. andere USB- Geräte wie Webcam etc. stören.

Also kann man nur spekulieren. Einen Ansatz hätte ich noch, da ich mich ja auch frisch mit dem Thema "scannen" beschäftigt habe. Leider wird die Vorrede dadurch noch länger. :-)

Wie auch immer Vuescan mit den Scannern redet, es muss sie ja erst mal finden. Bei Netzwerk-Scannern besteht somit das Problem, dass "der Laie" sich keinen Kopp über IP-Adressen machen will. Also holt sich der Scanner eine IP über DHCP vom Internet-Router, die beliebig ist und je nach Lease-Time und Häufigkeit der Nutzung auch schon mal variiert.

Ich habe meinen Geräten in der FritzBox eine feste IPv4-Adresse zugewiesen. Wobei es schon mehrmals passiert ist, dass die FritzBox den Haken "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen." vergisst und eine neue vergibt, erst gestern wieder bei meinem Arbeitsrechner. Das war aber bei den Scannern nicht der Fall und wäre ein eigener Threat.

Der Ausweg aus dieser Situation besteht darin, dass man versucht, den Scanner bei jeder Benutzung über Multicast-DNS oder ähnliche Mechanismen zu finden. eSCL benutzt tatsächlich Multicast-DNS, WSD benutzt einen eigenen Mechanismus, der aber ähnlich funktioniert und es mag noch zusätzlich einen Hersteller-proprietären Weg geben, der auch wieder anders funktioniert, aber eben ähnlich.

Das ist letztlich ein Riesen-Bohai, der auch schon mal schief gehen kann. Bei mir ging er erst mal schief, weil zwischen Arbeits-VM und Scanner ein Routing-Abstand war und Multicast-DNS nicht routing-fähig ist (es gibt aber eine Art Proxy für Multicast-DNS und bei WSD kann man auch sagen, ich weiß, welche IP der Scanner hat, mach den Bohai mit dem Multicast gar nicht). Ich vermute mal, dass es das bei Dir nicht ist.

Vielleicht nutzt aber das Verständnis dieser Mechanismen, den Fehler zu finden. Läuft Multicast-DNS, also Avahi, überhaupt auf dem Test-Rechner? Werden eventuell die davon erzeugten IP-Multicasts von irgendeiner Firewall geblockt? Vermutlich ist es beides nicht, aber trotzdem würde ich das Problem in der Ecke vermuten.

wie kann ich das feststellen, ob Multicast-DNS, also Avahi auf einem Rechner läuft? Die Einstellungen in Yast - Firewall sind auf beiden Rechnern gleich.

Funktioniert denn sane-airscan auf dem Testrechner? Wenn ich es richtig verstanden habe, hast Du das nur auf dem Arbeitsrechner ausprobiert?!

nein das habe ich nur auf dem Testrechner, aufgrund der Anregung hier, installiert und dann haben auch die Sane-Programme (xsane, skanlite) die Scanner erkannt.

Wireshark auf dem Testrechner könnte noch hilfreich sein. Ggf. sowohl von vuescan als auch von sane-airscan, besonders wenn die sich unterschiedlich verhalten.

Gruß Herbert

Am Donnerstag, 30. November 2023, 12:23:18 CET schrieb Rolf Schumann:

Hallo Herbert,

Am 30.11.23 um 11:39 schrieb Herbert Albert:

...

wie kann ich das feststellen, ob Multicast-DNS, also Avahi auf einem Rechner läuft? Die Einstellungen in Yast - Firewall sind auf beiden Rechnern gleich. yast - Diensteverwaltung

Viele Grüße Rolf

Hallo Rolf, auf dem Arbeitsrechner und dem Testrechner: avahi-daemon: Beim Systemstart avahi-dnsconfd: Manuell Multicast-DNS finde ich so nicht. Es gibt ein dnsmasq und ein multipathd Ist auf beiden auf Manuell Was noch ein Unterschied ist, auf dem Testrechner wird das Netz via NetworkManager: Beim Systemstart und beim Arbeitsrechner via wicked: Beim Systemstart gehandelt. Gruß Herbert