USB-Treiber werden unter OS6.80 nicht geladen

xanderzone

Neuer User
Mitglied seit
16 Jun 2008
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Hallo,
ich habe über modfs ein update von OS6.60 auf OS6.80 gemacht. Leider funktinieren die USB-Treiber jetzt nicht mehr.
Hat AVM am Kernel was geändert?

2017-01-27_Fehler_USB_OS6.80.jpg

Gruß
XC
 
Woher stammen denn die verwendeten Treiber-Dateien? Die AVM-Firmware enthält sie ja nicht (gilt aber nur für die Treiber für die USB-Serial-Wandler) und im Trunk ist die neue Release-Version noch nicht auswählbar.

Die Frage nach Änderungen kann man ohne die Veröffentlichung der Kernel-Quellen bzw. des kompletten OSS-Pakets ja vermutlich auch nur im Wege des fröhlichen Ratens beantworten - Probleme beim Laden älterer Treiber sprächen zumindest theoretisch dafür, sofern die mit einer vorherigen Version funktionierten.

Das ist ja auch selten verwunderlich ... hätte man aber mit hoher Wahrscheinlichkeit schon in der Phase der Labor-Tests bemerken können und dann auch schon früher versuchen können zu finden, wenn irgendjemand (und das können eben nicht nur diejenigen sein, die noch etwas am Freetz machen) das auch schon mal vorher getestet hätte. Nun lohnt es sich vielleicht auch nicht mehr, ohne die AVM-Dateien nach dem Unterschied zu suchen, denn die Erfahrung zeigt, daß in 1-3 Monaten dann auch die OSS-Pakete nachgereicht werden.

Angesichts der bisherigen Erfahrungen kann man aber sicherlich davon ausgehen, daß AVM die Änderungen am Kernel bereits am Beginn der Labor-Reihe (das waren diesmal knapp 6 Monate mit der 06.69) eingeführt hat und da hätte man sicherlich etwas machen können - die fehlenden Symbole hätte man zumindest garantiert inzwischen identifiziert.

Das "Fehlerbild" deutet darauf hin, daß irgendeine Änderung am USB-Stack erfolgte ... wenn man dann (auch ohne Kenntnis von SolarView) noch registriert, daß da offenbar mittels "insmod" (das ist ja die "dumme" Version, die aber auch Module außerhalb der Kernelverzeichnisse lädt im Gegensatz zum "modprobe") gearbeitet wird, dann würde man vermutlich als erstes mal nach dem verwendeten LKM für "usbserial.ko" schauen. Das gibt es ja in der Firmware bereits und die dort vorhandene Version sollte/müßte/dürfte auch zum verwendeten Kernel passen - da müßte es schon "mit dem Teufel zugehen" (wahlweise auch den "Deibel" einsetzen, ich bin da nicht wählerisch), wenn es sich beim sichtbaren Fehler beim Laden von "usbserial.ko" tatsächlich um die Datei von AVM handeln sollte.

Wenn der sio- oder der pl-Treiber tatsächlich zusätzliche Symbole brauchen sollten im "usbserial" (außerhalb wäre zwar auch möglich, halte ich aber für weniger wahrscheinlich - ohne Kenntnis der fehlenden Funktionen ist das aber auch alles nur geraten), dann könnte man zumindest durch Vergleich der Module (also im hier verwendeten "usbserial"-LKM und in dem von AVM) diese Symbole ermitteln und sich dann überlegen, welche Optionen man bis zur Veröffentlichung des OSS-Paketes noch hätte.
 
Hallo,
die Treiber habe ich mit Freetz mit den AVM OSS-Paket OS6.51 erstellt. Weiter habe ich CURL erstellt um Daten per ftp zu senden. CURL funktioniert unter OS6.80 noch.
Dann muss ich wohl abwarten bis die OSS-Pakete zu OS6.80 verfügbar sind. So lange bleibe ich dann bei OS6.60.

Gruß

XC
 
Dann laß doch mal (probehalber) den eigenen "usbserial.ko" weg und probiere, ob der "pl2303.ko" oder der "ftdi_sio.ko" (braucht man wirklich beide? ich hätte spontan "nein" gesagt, weil ich damit die Unterstützung zweier unterschiedlicher Wandler-Chips assoziieren, aber ich kann mich durchaus täuschen) auch mit den "usbserial.ko" von AVM spielen will. Angesichts der Reihenfolge bei den Nachrichten würde ich die Probleme beim "pl2303" und beim "ftdi_sio" für eine Folge des Problems beim "usbserial" halten und das sollte der von AVM ja nicht haben.
 
Den Treiber "usbserial.ko" benötige ich nicht. Nach meinem Wissensstand sind die Treiber "pl2303.ko" und "ftdi_sio.ko" ab OS6.50 nicht mehr in der Firmware enthalten.
Die Treiber werden über eine Batch-Datei geladen:

echo Starting now USB-Drivers for Fritzbox 7490
insmod usbserial.ko
insmod pl2303.ko
insmod ftdi_sio.ko
echo Finshed loading USB-Drivers

Ich vergleiche heute abend nochmal die Kernelversionen (uname -ar)
 
Zuletzt bearbeitet:
Den Treiber "usbserial.ko" benötige ich nicht.
[...]
Die Treiber werden über eine Batch-Datei geladen:
[...]
insmod usbserial.ko
Hmm ... :gruebel:

Ist das denn nun der "usbserial.ko" von [ ] AVM (in der korrekten Version) oder [ ] der von der Freetz-Toolchain erzeugte, der bei diesem Versuch mittels "insmod" geladen werden soll? (Zutreffendes bitte ankreuzen)

Ich glaube kaum, daß es der von AVM ist, denn der sollte sich eben problemlos laden lassen - wenn bereits das nicht funktioniert, gibt es irgendein wesentlich größeres Problem; denn er funktioniert prinzipiell schon - sonst wäre jeder USB-Stick mit seriellen Ports aufgeschmissen, denn der "option.ko" braucht den "usbserial.ko" auch als "Grundlage":
Code:
$ [COLOR="#0000FF"]lsmod | grep -E '(usbserial|option)'[/COLOR]
option                  3733  0
usb_wwan               10183  1 option
[COLOR="#FF0000"]usbserial[/COLOR]              41121  2 option,usb_wwan
usbcore               209371  5 option,usb_wwan,usbserial,usb_storage,xhci_hcd
und da läßt sich die AVM-Version auch in der 06.80 bei mir problemlos laden ... siehe oben.

Wenn also in #1 im Bild zu sehen ist, daß da bereits der "usbserial.ko" nicht richtig geladen werden kann, dann ergibt
xanderzone schrieb:
Den Treiber "usbserial.ko" benötige ich nicht.
in #5 auch unter diesem Aspekt keinen richtigen Sinn und daran wird vermutlich ein "uname -ar" auch nicht wirklich etwas ändern.

Zumal das ja (so mich mein Gedächtnis nicht täuscht) die Informationen zum gerade laufenden Kernel ausgibt und ich nicht verstehe, wie man daraus jetzt auf irgendeine Versionsangabe für ein zu ladendes LKM schließen sollte - außer es ging darum, unter welchem Kernel das LKM gerade geladen werden soll, was aber mit seiner eigenen Version nichts wirklich zu tun hat.

Ich wäre also tatsächlich so vermessen, meinen Vorschlag noch einmal zu erneuern ... sollte der pl2303.ko oder der ftdi_sio.ko (werden denn nun beide benötigt oder ist das nur die "Vorsorge" im SolarView-Skript, damit man "alle" Wandler-Chips unterstützt?) tatsächlich auf zusätzliche Symbole im Kernel oder im usbserial-LKM angewiesen sein, bringt das zwar auch keinen geladenen Treiber, aber wenigstens Klarheit. Scheitern die aber ihrerseits nur am (vermutlich) falschen "usbserial.ko", besteht zumindest die Chance, daß sie (bzw. "er", falls ja doch nur einer der beiden Wandler-Treiber gebraucht wird) mit dem LKM von AVM arbeiten (den falschen Fall bei "er" lasse ich mal außen vor). Das wird so ein LKM aber mit hoher Wahrscheinlichkeit auch auf keinem anderen Weg als dem des Versuches "offenlegen" ... auch unter Berücksichtigung dieser Annahme (nur der Versuch macht klug) könnte mein Vorschlag neue Erkenntnisse bringen und wenn nicht, zumindest die bisherigen bestätigen.

Daher würde ich anstelle von "uname -ar" dann tatsächlich eher die "insmod"-Kommandos probieren (mit Ausnahme des ersten, was aber bei bereits korrekt geladenem "usbserial" auch scheitern sollte) und denen noch ein "modprobe usbserial" vorausschicken ... immer unter der Annahme, daß der AVM-Treiber noch an seinem angestammten Platz in der Dateihierarchie zu finden ist und nicht gelöscht oder überschrieben wurde.
 
Hallo,
da jetzt die Sourcen vom OS6.80 verfügbar sind, könnte vielleicht einer mir die USB-Treiber pl2303.ko und ftdi_sio.ko erstellen?
DANKE!
Gruß
XC
 

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,687
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.