ubuntuusers.de

shiro schrieb: Bei dem obigen Beispiel wäre der Filter beispielsweise

(usb.src[0:4] == "3.21") || (usb.dst[0:4] == "3.21")

An genau an so ein Beispiel hatte ich gedacht. Ich habe nun folgendes gewählt:

(usb.addr[0:5] !="3.2.1")

Damit wird alles rausgefiltert, was von der Maus kommt, und der Rest scheint mir IMHO zur Kommunikation mit dem Scanner zu gehören.

Spiele ein wenig mit ihnen, um zu sehen, wie sie funktionieren. Das alles hier zu beschreiben, würde den Rahmen sprengen.

Ja klar. Du hast mir schon mehr Hinweise gegeben, als ich eigentlich erwartet habe. Ganz herzlichen Dank für die detaillierten Anweisungen.

In Anhang mal 3 Formate der gefilterten Kommunikation. Das CSV-Format eignet sich gut für den groben Überblick mit LibreOffice Calc. Wie man darin sieht, bricht die Kommunikation mit dem Scanner nach etwas mehr als 90 Sekunden ab. Ab da liefert auch lsusb kein Ergebnis mehr.

Jetzt stellt sich mir die Frage, wodurch der Abbruch erfolgt, und von welcher Seite, also dem Scanner oder dem colord.service, und durch welchen USB-"Befehl". Wenn da jemand Ideen zu hat, würde ich mich sehr freuen. Also vielleicht hat ja jemand ein bisschen Ahnung von den USB-Paketen/Befehlen.

😎

Hier noch mal das gleiche Szenario, mit dem Unterschied, dass ich während der Scanner-Kalibrierung noch das Scanprogramm VueScan gestartet habe. Wie man im Log sehen kann, wird der Scanner von VueScan gefunden, doch die Kommunikation gelingt nicht, sodass sie aufgegeben wird.

Ich habe dann mal einen Fehlerbericht geschrieben. Könnte aber sicher dauern, bis da was geschieht, denn colord hat 93 offene Bugs.

Wie man im Log sehen kann, wird der Scanner von VueScan gefunden, doch die Kommunikation gelingt nicht, sodass sie aufgegeben wird.

Ich habe deinem .pcapng File nach dem "Genesys Logic" (0x05e3) Gerät gesucht.

(usb.idVendor == 0x05e3 )

Dabei wurde Adresse "3.8.0" gefunden (siehe Paket 54). Ein Filtern nach

(usb.addr[0:3] == "3.8")

zeigt dann die Kommunikation. Nach Austausch der CONFIGURATION unterhalten sich "host" und "Device" ohne nennenswerte Informationen auszutauschen. Die Abfrage vom "host" (Pakte 85) wird dann allerdings erst nach 30 sek (!!!) vom Gerät beantwortet. Jeder weitere Request vom Host wird von da ab immer erst nach 30 sek beantwortet. Das sieht nach einem Problem im Device aus.

Ich denke, das führt zu der Meldung " 2 usbi: usb_claim_interface failed vid 05e3 pid 0142 nco 1 ifn 0 : could not claim interface 0: Device or resource busy" im "vuescan.log" File.

Ich drück die Daumen, dass der Bug möglichst zügig bearbeitet wird.

shiro schrieb:

Ein Filtern nach

(usb.addr[0:3] == "3.8")

zeigt dann die Kommunikation.

Ja schon klar. Ich habe die anderen Kommandos absichtlich drin gelassen, da sie immer synchron mit der Scanner-Kommunikation kamen, und ich da einen evtln. Zusammenhang vermute. Zumindest "3.0.x" ist ja der Hub selbst, der dann wohl an "3.8.x" weiterleitet.
In dem 2. Versuch sieht man auch schön, dass dann VueScan auch noch "dazwischenfunkt" und dabei versucht, noch an anderen Ports einen Scanner zu finden. So wird z.B. die WebCam gefunden und sogar in der VueScan-Oberfläche als Quelle angeboten. Wählt man sie allerdings aus, kommt dabei nur ein schwarzes Bild bei heraus. Ist also schon komisch, dass die nicht taugliche WebCam als Quelle dann angeboten wird, dafür aber nicht der taugliche Dia-Scanner.

Nach Austausch der CONFIGURATION unterhalten sich "host" und "Device" ohne nennenswerte Informationen auszutauschen. Die Abfrage vom "host" (Pakte 85) wird dann allerdings erst nach 30 sek (!!!) vom Gerät beantwortet. Jeder weitere Request vom Host wird von da ab immer erst nach 30 sek beantwortet.

Das erklärt dann wohl alles. Danke für die tolle Analyse.

Das sieht nach einem Problem im Device aus.

Ja das denke ich auch. Allerdings wird für das 10 Jahre alte Gerät wohl keine neue Firmware mehr kommen. Auf der anderen Seite ... Windows kommt damit klar. So denke ich, dass man den Ubuntu-Code überdenken könnte und so abändern, dass es zu keinem Abbruch mit dem Gerät mehr kommt. Evtl. muss einfach nur der Time-Out überdacht werden. Während der ca. 1,5-minütigen Kalibrierung scheint der Scanner wohl USB-seitig zu schlafen. Schließt man den erst nach der Kalibrierung an, läuft ja alles (fast) normal. Die mitgelieferte, aber sonst viel schlechtere Windows-Software "CyberView" zeigt während der Zeit "Initializing ..." an, kommt also mit der Wartezeit klar, nur VueScan leider nicht.

Ich denke, das führt zu der Meldung " 2 usbi: usb_claim_interface failed vid 05e3 pid 0142 nco 1 ifn 0 : could not claim interface 0: Device or resource busy" im "vuescan.log" File.

Genau das wäre die Stelle, wo auch evtl. VueScan irgend was anders machen könnte, damit die Verbindung nicht verloren geht. Aber die von deren Support meinen ja, ich hätte ein Hardware-Problem.

UlfZibis schrieb:

Aber die von deren Support meinen ja, ich hätte ein Hardware-Problem.

Habe die auch gesagt, welche Art von Hardware-Problemen?
Das Gerät hat defekten Bauteile und dadurch bedingte Einschränkungen. Oder was soll man mit der Info sonst anfangen?

Berlin_1946 schrieb:

Habe die auch gesagt, welche Art von Hardware-Problemen?

Erst mal nur ganz allgemein, dann der Rat, ein anderes Kabel zu nehmen, dann einen anderen USB-Anschluss.
Meist so als Einzeiler. Dann habe ich jeweils Begründungen geliefert, dass es nicht am Scanner, nicht am Kabel und auch nicht am Anschluss liegen kann, denn unter Windoof mit anderer Software funktioniert ja alles. Und dann meinten die doch glatt, dass es daran liegt, dass Linux andere Treiber etc. hätte, Dann musste ich denen erklären, dass es doch genau die Aufgabe einer extra Linux-Version ist, mit diesen Unterschieden klar zu kommen. Und irgendwann meinten sie, sie hätten ja wohl jetzt genug E-Mails beantwortet, jetzt wäre Schluss. Hier findest Du das detaillierter, falls es Dich interessiert: https://forum.aphog.com/index.php?thread/63358-vuescan-unter-linux-mit-braun-multimag-slidescan-6000/&pageNo=2

Oder was soll man mit der Info sonst anfangen?

Eben genau das.