Problem mit Epson Scanner übers Netzwerk
Hallo Liste, in meinem Netzwerk sind zwei Epson Multifunktionsdrucker, die ich auch zum Scannen übers Netz verwende. Ein Epson XP-800 und ein EPSON WF-C5790BA. Beide beziehen ihre IP von einer FritzBox als feste Adresse. Auf meinen Arbeitsrechner, den ich plane in nächster Zeit von leap 15.4 auf 15.5 zu heben, kann ich beide Scanner über Vuescan und imagescan, den WF-C5790BA auch über das Epson Tool epsonscna2 (epsonscan2-6.7.63.0-1.x86_64) ansprechen, nicht jedoch mit xsane, skanlite. Vuescan ist mir sehr wichtig, da fast täglich im Gebrauch, die anderen Tools habe ich nicht so vermisst. Es war schon beim upgrade von leap 15.3 auf 15.4 ein kleines Theater, bis die beiden funktionierten. Nun habe ich vor dem Upgrade des Arbeitsrechners auf einem Testrechner das Upgrade von 15.4 auf 15.5 durchgeführt. Auf diesem Rechner gelingt es mir nicht, was auf dem Arbeitsrechner mit 15.4 geht, scannen mit vuescan. Die Scanner werden in Vuescan nicht gefunden. Hat jemand vuescan unter leap 15.5 mit einem Netzwerkscanner am Laufen? Denn bevor ich upgrade auf 15.5, wüsste ich schon gerne ob das geht bzw. was ich gegenüber leap 15.4 ändern muss. 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? Gruß Herbert
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. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
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. 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. Gruß Herbert
Am Wed, 29 Nov 2023 10:50:23 +0100 schrieb Herbert Albert <herbert.albert@nefkom.net>:
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 Mittwoch, 29. November 2023, 14:46:16 CET schrieb Andreas Kyek:
Am Wed, 29 Nov 2023 10:50:23 +0100
schrieb Herbert Albert <herbert.albert@nefkom.net>:
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 Hallo Andreas,
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. Gruß Herbert
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 Mittwoch, 29. November 2023, 19:42:41 CET schrieb Ulf Volmer:
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 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.
Am Wed, 29 Nov 2023 19:48:51 +0100 schrieb Herbert Albert <herbert.albert@nefkom.net>: [...]
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, 10:11:18 CET schrieb Andreas Kyek:
Am Wed, 29 Nov 2023 19:48:51 +0100 schrieb Herbert Albert <herbert.albert@nefkom.net>:
[...]
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
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 <herbert.albert@nefkom.net>:
[...]
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 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? Bist Du im selben Netz wie Dein Drucker? Läßt die Firewall Deines PC port 5353/udp ausgehend durch? Viele Grüße Ulf
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
Am 01.12.23 um 08:51 schrieb Herbert Albert:
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
Ich würde sagen, das sieht so aus, wie es soll. MDNS scheint nicht Dein Problem zu sein.
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.
Dü müsstest in Deinen Firewall Regel schauen. Aber da das avahi-browse oben funktioert hat, kannst Du Dir das schenken. 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
Am Freitag, 1. Dezember 2023, 16:28:45 CET schrieb Manfred Haertel, DB3HM:
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? Hallo Manfred,
vuescan liefert auf der Konsole keine Output. Hier mal ein Ausschnitt von log-File. Arbeitsrechner: VueScan 9 x64 (9.8.21) Dec 1 2023 UTC+1 de Linux gcc 7 8 cpus Professional Edition h.albert@odn.de 0 Begin startup 0 Calling mdns_open 0 mDNS 4 AF_INET 192.168.178.59 2 Calling prob_open 2 prob: Searching for /dev/usbscanner devices 2 prob: Searching for libusb devices 3 [genesys] sane_init_impl: start 3 [genesys] sane_init_impl: authorize == null 3 [genesys] Genesys Logic backend: test 4850 3 [genesys] sane_init_impl: completed 3 prob: Found device: vid 04e8 pid 4001 bcd 0100 mfg "Samsung" mdl "PSSD T7" ser "S6XJNS0W706479E" por "002" 3 prob: ifn 0 aln 0 icl 08 isc 06 ipr 50 nep 2 3 prob: ifn 0 aln 1 icl 08 isc 06 ipr 62 nep 4 3 prob: Found device: vid 045b pid 0210 bcd 0100 mfg "Unknown" mdl "Unknown" ser "Unknown" por "002" 3 prob: Found device: vid 046d pid 082d bcd 0011 mfg "Logitech" mdl "Unknown" ser "Unknown" por "007" 3 prob: Found device: vid 056d pid 4008 bcd 8000 mfg "Unknown" mdl "Unknown" ser "Unknown" por "006" 3 prob: Found device: vid 046d pid c077 bcd 7200 mfg "Logitech" mdl "Unknown" ser "Unknown" por "005" 3 prob: Found device: vid 046d pid c318 bcd 5503 mfg "Logitech" mdl "Unknown" ser "Unknown" por "004" 3 prob: Found device: vid 058f pid 6364 bcd 0100 mfg "Unknown" mdl "Unknown" ser "Unknown" por "003" 3 prob: Found device: vid 045b pid 0209 bcd 0100 mfg "Unknown" mdl "Unknown" ser "Unknown" por "002" 3 prob: Getting mDNS devices 3 prob: Found device: EPSON XP-800 Series 3 prob: typ: _printer._tcp. 3 prob: adr: 192.168.178.22 3 prob: por: 515 3 prob: txt: 202 3 prob: txtvers=1 3 prob: priority=50 3 prob: ty=EPSON XP-800 Series 3 prob: usb_MFG=EPSON 3 prob: usb_MDL=XP-800 Series 3 prob: product=(EPSON XP-800 Series) 3 prob: pdl=raw 3 prob: rp=auto 3 prob: qtotal=1 3 prob: adminurl=http://EPSON2F3D6A.local.:80/PRESENTATION/BONJOUR 3 prob: note= Testrechner: VueScan 9 x64 (9.8.21.10) Dec 1 2023 UTC+1 de Linux gcc 7 2 cpus Professional Edition h.albert@odn.de 0 Begin startup 0 Calling mdns_open 0 mDNS 4 AF_INET 192.168.178.56 2 Calling prob_open 2 prob: Searching for /dev/usbscanner devices 2 prob: Searching for libusb devices 2 [genesys] sane_init_impl: start 2 [genesys] sane_init_impl: authorize == null 2 [genesys] Genesys Logic backend: test 4850 2 [genesys] sane_init_impl: completed 2 prob: Found device: vid 0a5c pid 2101 bcd 0354 mfg "Broadcom" mdl "Unknown" ser "Unknown" por "002" 2 prob: Found device: vid 046d pid c019 bcd 4301 mfg "Logitech" mdl "Unknown" ser "Unknown" por "002" 2 prob: Found device: vid 174f pid 5931 bcd 1120 mfg "Unknown" mdl "Unknown" ser "Unknown" por "003" 2 prob: Getting mDNS devices 2 prob: Listing devices being used 2 Calling scan_open 2 Searching for SCSI devices 2 Found device: /dev/sg0 2 Found device: /dev/sg1 2 Calling vid1_open
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
Am Freitag, 1. Dezember 2023, 18:22:56 CET schrieb Manfred Haertel, DB3HM:
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. Hallo Manfred,
strace -f vuescan 2>&1 | grep avahi liefert auf beiden Rechnern keine Rückmeldung Gruß Herbert
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 <unfinished ...> [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...> 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
Am 02.12.2023 um 18:54 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 <unfinished ...> [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...>
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`
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 Manfred
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 02.12.23 um 20:23 schrieb Manfred Haertel, DB3HM:
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.
Wenn die Applikation aus einem einzelnen Binary besteht, spart man mit dem Verfahren gegenüber statischem Linken weder Plattenplatz noch RAM. Sowas loht sich nur, wenn man einen Zoo von Apps ausliefert. vuescan tut das nicht, sondern besteht aus einem einzelnem Binary. Welches nebenbei ganz normal gegen die System- Libs gelinkt ist. Das hätte eigentlich jeder der Mitlesenden in 5 Minuten herausfinden können. Viele Grüße Ulf
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 <unfinished ...> [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...>
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, 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 <unfinished ...> [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...>
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 <unfinished ...> [pid 14966] openat(AT_FDCWD, "/usr/lib64/lib*avahi*-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...> [ und es geht die GUI "Document-Scanner" auf
Auf dem Testrechner unter leap 15.5: kommt keinerlei Rückmeldung.
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 <unfinished ...> [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...>
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 <unfinished ...> [pid 14966] openat(AT_FDCWD, "/usr/lib64/lib*avahi*-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...> [ 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 */ <unfinished ...> [pid 4754] execve("/usr/bin/which", ["which", "avahi-browse"], 0x559019584ee0 /* 106 vars */) = 0
Doch an vuescan ändert das nichts.
Am Samstag, 2. Dezember 2023, 22:35:34 CET schrieb Herbert Albert:
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 <unfinished ...> [pid 23634] openat(AT_FDCWD, "/usr/lib64/libavahi-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...>
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 <unfinished ...> [pid 14966] openat(AT_FDCWD, "/usr/lib64/lib*avahi*-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...> [ 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 */ <unfinished ...> [pid 4754] execve("/usr/bin/which", ["which", "avahi-browse"], 0x559019584ee0 /* 106 vars */) = 0
Doch an vuescan ändert das nichts. habe jetzt nochmal den Port überprüft, doch der ist auf beiden Rechnern offen Arbeitsrechner: ~> sudo netstat -tulpn | grep 5353 [sudo] Passwort für root: udp 0 0 0.0.0.0:*5353* 0.0.0.0:* 927/avahi-daemon: r udp6 0 0 :::*5353* :::* 927/avahi-daemon: r Testrechner: r560:~> sudo netstat -tulpn | grep 5353 [sudo] Passwort für root:
Nochmals die Frage: Kann der Unterschied in wicked und NetworkManager liegen? udp 0 0 0.0.0.0:*5353* 0.0.0.0:* 649/avahi-daemon: r udp6 0 0 :::*5353* :::* 649/avahi-daemon: r
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 <unfinished ...> [pid 14966] openat(AT_FDCWD, "/usr/lib64/lib*avahi*-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...>
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
Hallo Manfred, Am Sonntag, 3. Dezember 2023, 03:57:40 CET schrieb Manfred Haertel, DB3HM:
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 <unfinished ...> [pid 14966] openat(AT_FDCWD, "/usr/lib64/lib*avahi*-client.so.3", O_RDONLY|O_CLOEXEC <unfinished ...>
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.
Ja mir auch. Wobei es nicht so wichtig ist das vuescan auf dem Testrechner unter leap 15.5 läuft. Der Grund, warum ich das gemacht habe ist ja, dass ich sicher gehen wollte, dass nach einen Upgrade meines Arbeitsrechners auf leap 15.5 das Programm auch noch läuft. Natürlich ist das keine Garantie, da andere Hardware, jedoch im selben Netz. Denn wenn ich den Arbeitsrechner upgrade und es dann nicht läuft, ist das Kind schon in den Brunnen gefallen. Ein Zurück über mein Backup (rsync Spiegel der Root-Partition) wollte ich nicht riskieren. Wer weiß, was da wieder alles auf poppt. Wenn nicht aus Sicherheitsgründen der Updatezwang wäre und auch irgendwann Programme veralten, würde ich ja so weiterfahren.
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.
Kann ich nicht sagen, entweder habe ich in Yast noch etwas falsch eingetragen, oder es liegt u.a. an den Plasmoiden unter KDE, von den ich einige (Wetter, Kalender) verwende. Die kommen jedenfalls nicht nach außen und KMail hat es auch nicht geschafft. Bis vor ca. 10 Jahren habe ich das immer so gemacht, dass mein Arbeitsrechner eine feste IP bekam. Was damals der Grund war auf DHCP zu wechseln (Router-Wechsel??) weiß ich nicht mehr.
Aber wenn Sane ja geht, hat dieses Problem ja wohl nichts mit dem Netzwerk zu tun.
Mein Netzwerk ist eigentlich nicht kompliziert. Eine FritzBox im Keller als Zentrale für alles was rein- und rausgeht plus neuerdings VoIP. Von da über Switches nach oben zu den Rechnern und Repeatern für WLAN. Der Unterschied zischen Arbeitsrechner und Testrechner ist Wicked zu NetworkManager. Auf dem Testrechner (Notebook) welches per WLAN ins Netz geht habe ich es mit Wicked nie geschafft in Home-Netz zu kommen, weshalb ich mich vor Jahren für den NetworkManager entschieden habe. Da ich nicht der Netzwerkspezialist bin, habe ich mich damit abgefunden. Ich will mit den Geräten arbeiten und nicht ständig schrauben. Herbert
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 Donnerstag, 30. November 2023, 17:00:10 CET schrieb Manfred Haertel, DB3HM:
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... Hallo Manfred,
mit wireshark kenne ich mich leider nicht aus. Nochmals, der Testrechner ist mir nicht so wichtig, wichtig ist, dass nach dem Upgrade auf dem Arbeitsrechner alles wieder so läuft wie mit leap 15.4. Das ist jedes Jahr so eine Zitterpartie. Da hat mein ein gut funktionierendes System, dann läuft die Supportunterstützung aus und nicht auf eine neue Version upgraden ist auch keine Lösung. Mal sehen ob sich in Zukunft Slowroll anbietet, aber davor kommt wohl noch 15.6 und evtl. 15.7. Gruß Herbert
Am Mittwoch, 29. November 2023, 14:46:16 CET schrieb Andreas Kyek:
Am Wed, 29 Nov 2023 10:50:23 +0100
schrieb Herbert Albert <herbert.albert@nefkom.net>:
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
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. 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. 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. 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. 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. 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. Funktioniert denn sane-airscan auf dem Testrechner? Wenn ich es richtig verstanden habe, hast Du das nur auf dem Arbeitsrechner ausprobiert?! Wireshark auf dem Testrechner könnte noch hilfreich sein. Ggf. sowohl von vuescan als auch von sane-airscan, besonders wenn die sich unterschiedlich verhalten. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
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
participants (6)
-
Andreas Kyek -
Herbert Albert -
Manfred Haertel, DB3HM -
Manfred Kreisl -
Rolf Schumann -
Ulf Volmer