[Gelöst] FB 6890 - kein LTE mehr nach Freetz

koronth

Neuer User
Mitglied seit
21 Nov 2008
Beiträge
59
Punkte für Reaktionen
1
Punkte
8
Hallo Leute,

nach vielen Stunden des Ausprobierens kann ich nun sagen, daß nach einem Freetz (orig & ng probiert) und mit der Firmware 7.13 der ganze LTE-Teil der FB 6890 nicht mehr funktioniert. Nicht einmal mehr die SIM-Karte wird erkannt.

Nach dem Flashen der Original-Firmware FRITZ.Box_6890_LTE-07.13.image ist mit einem Schlag wieder alles in Ordnung.

Auch der jeweilige minimalste Trunk und das Rücksetzen auf Werkseinstellungen hat nichts geholfen.

Gibt es hier jemanden der 07.13er Firmware und Freetz mit funktionierendem LTE-Teil zusammen gebracht hat? Und wenn ja, welche Freetz-Revision war das dann?

Edit: Es handelt sich übrigens um eine Fritzbox 6890v2.

Vielen Dank!
 
Zuletzt bearbeitet:

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
321
Punkte für Reaktionen
6
Punkte
18

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,147
Punkte für Reaktionen
1,033
Punkte
113
Ich würde erst mal versuchen, mir nur ein Image (von Hand) zu bauen, in dem ein Shell-Zugriff möglich ist.

Die Protokolle im GitHub-Repo sind zwar schön und gut (und auf den ersten Blick auch "vollständig"), aber jemand ohne das Gerät kann auch nur raten, wie der "normale" Startvorgang wohl aussehen müßte.

So rein vom Gefühl her (und anhand dessen, was man in der dmesg-Ausgabe sehen kann) würde ich sagen, daß der LTE-Teil (der hier wohl am USB-Bus hängt und als "Black-Box" per Ethernet-over-USB angesprochen wird) hier zwar irgendwann mal vom USB-Treiber erkannt wird und auch noch der "cdc_ncm"-Treiber versucht wird zu laden, aber der "mobiled" wird gar nicht gestartet bzw. nicht von der Existenz des (neuen) Gerätes informiert und in der Folge setzt dann irgendjemand den USB-Hub für den LTE-Adapter zurück und die Erkennung geht von vorne los - so interpretiere ich jedenfalls die mit
Code:
grep -i "\(usb\|hub\) 3\|cdc" syslog_freetz_noLTE.txt
"gefilterte" Ausgabe.

Nun greift Freetz ja irgendwo (aus dem Kopf weiß ich aber auch nicht mehr genau, wo überall) in die USB-Geräte ein - zumindest dann, wenn man "FREETZ_PATCH_FREETZMOUNT" aktiviert hat, wie das in der "config.txt" in der GitHub-Issue zu sehen ist. Das würde ich also auch mal auslassen ... zu #1 kann man (so ohne jede weitere Angabe hinsichtlich Konfiguration und Protokoll) nichts weiter sagen. Keine Ahnung, wie der "minimalste Trunk" aussieht und ob da Änderungen am USB ggü. der AVM-Firmware vorgenommen wurden.

Wobei das ein Vergleich der Verzeichnisse (mindestens der für "udev" und "hotplug") zwischen der originalen Firmware (build/original/...) und den Freetz-Modifikationen (build/modified) ja auch zeigen könnte - wenn jemand Lust hat, sich die Unterschiede (es werden nicht wenige sein, zumindest auf die gesamte Firmware gesehen) im einzelnen auch anzusehen.

Jedenfalls kann man doch gleich viel sinnvoller ein Protokoll des Systemstarts interpretieren (die Ausgabe von "dmesg", die es in der Issue ja gibt), wenn man nicht nur den Fehlerzustand, sondern auch den "Sollzustand" kennt und die beiden Protokolle nebeneinander legen und vergleichen kann. Ohne das Gerät, ist es schwer bis unmöglich zu sagen, was nun zum "normalen Ablauf" beim Start gehört und wo sich das nach der Installation eines Freetz-Images ändert. Daher würde ich eben erst mal kleinere Brötchen backen und mir ein Image mit einem Shell-Zugang bauen, über den ich dann diese Protokolle aus der Box herausbekomme. Denn vermutlich sollte der "mobiled" erst mal damit beginnen, die Firmware ins LTE-Modem zu laden, wenn er von ihm "Kenntnis erlangt" - jedenfalls liegen in "/usr/share/lte" noch Firmware-Files herum, die ggf. auch erst noch mittels "bspatch" an unterschiedliche Hardware angepaßt werden. DAS sollte man zumindest mal im funktionierenden Zustand mit der AVM-Firmware gesehen haben, um die Unterschiede zum Ablauf unter Freetz überhaupt erkennen zu können.

Ich denke jedenfalls auch, daß es eher an der geänderten Konstruktion neuerer FRITZ!Box 6890-Modelle liegt - auch wenn ich keine Ahnung habe, wie bei den Vorgängern das LTE-Modem angebunden war. Im GitHub-Repo wird ja auch berichtet, daß es schon mit 06.8x (das "x" müßte "7" sein) bei der betroffenen 6890 nicht klappen wollte.
 

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
321
Punkte für Reaktionen
6
Punkte
18
Dann werde ich mal ein minimales Image bauen. Zusätzlich den syslog.

und einmal „mein“ Image ohne freetzmount.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,147
Punkte für Reaktionen
1,033
Punkte
113
Dann werde ich mal ein minimales Image bauen.
Das ist aber nicht das, was ich in #3 meinte ... nur damit es hinterher nicht heißt, ich hätte das ja so gewollt.

Ich rede von einem Image mit minimalen Änderungen ggü. der AVM-Firmware - das kriegt man mit dem Freetz-Projekt höchstens noch einigermaßen hin, wenn man den "no-freetz mode" verwendet.

Sollte allerdings das "minimale Image" bereits funktionieren, wäre das natürlich auch "nett" - nur glaube ich da nicht wirklich dran.
 

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
321
Punkte für Reaktionen
6
Punkte
18
Ah okay. Dann probiere ich das mal :)
 

Micha0815

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
4,002
Punkte für Reaktionen
223
Punkte
63
Hast Du denn mal
daß es eher an der geänderten Konstruktion neuerer FRITZ!Box 6890-Modelle liegt
gedacht?

Imho wurde da doch "nur" eine andere Huawei-HW-Revision verbaut, die speziellere Frequenzbänder (internal-FW-technisch) abdeckt? Der Hinweis
daß der LTE-Teil (der hier wohl am USB-Bus hängt und als "Black-Box" per Ethernet-over-USB angesprochen wird) hier zwar irgendwann mal vom USB-Treiber erkannt wird und auch noch der "cdc_ncm"-Treiber versucht wird zu laden,
Dass auch andere Huawei-LTE(USB-Stick)-Modelle e.g. E3372(@HiLink) nicht wirklich mit aktuellen [email protected] (7490/7590) sinnvoll agieren können ist schon längers bekannt.
Das here Ziel via Konsole ... mein aufrichtiger Respekt ... wird irgendwo imho im Nirwana enden, da die Anbindung -und dort die Huawei-FW- ein Eigenleben hat ... je nach Provider... dem man nicht wirklich "Herr" wird.

Gerne lasse ich mich hier "Lügen Strafen" ... nur irgendwie erscheint mir doch eher als Kapitulation was die Zusammenarbeit Huawei<->AVM betrifft, als dass man zukünftig Wunder erwarten sollte ;)
LG and my2cent
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,147
Punkte für Reaktionen
1,033
Punkte
113
@WileC:
In Deiner Box ist - dem Protokoll nach - ein L830-EB-11 von Fibocom verbaut ... zumindest meldet sich ein solches als USB-Gerät beim Linux-Kernel, wie man sehen kann:
Code:
Jun 26 14:51:07 fritz kern.info kernel: [   67.172000][1]usb 3-1: new high-speed USB device number 4 using xhci-hcd
Jun 26 14:51:07 fritz kern.info kernel: [   67.196000][0]usb 3-1: New USB device found, idVendor=2cb7, idProduct=000b
Jun 26 14:51:07 fritz kern.info kernel: [   67.196000][0]usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 26 14:51:07 fritz kern.info kernel: [   67.196000][0]usb 3-1: Product: L830-EB-11
Jun 26 14:51:07 fritz kern.info kernel: [   67.196000][0]usb 3-1: Manufacturer: FIBOCOM
Jun 26 14:51:07 fritz kern.info kernel: [   67.196000][0]usb 3-1: SerialNumber: 004999010640000
Fibocom hat m.W. mit Huawei absolut nichts zu tun: https://telematik-markt.de/telematik/huawei-stellt-produktion-verschiedener-kommunikationsmodule-ein (oder auch https://www.bloomberg.com/profile/company/300638:CH) und es werden - nach Tests von anderen, ich habe wie gesagt keine 6890v2 (und auch keine v1) - auch schon ziemlich lange Module von Fibocom Wireless bei AVM verbaut, wie man bei Recherchen ermitteln kann: https://maxwireless.de/2018/avm-fritzbox-6890-v2-lte-modem-frequenzbaender/ - immer unter der Maxime, daß die Quellen zuverlässig sind.
 

NDiIPP

IPPF-Promi
Mitglied seit
13 Apr 2017
Beiträge
3,418
Punkte für Reaktionen
613
Punkte
113
Man kann also (bisher) zusammenfassen, mit Freetz-(NG) kein DVB-C beim DVB-C Repeater und kein LTE bei der 6890 LTE. Ob es da noch weitere Inkompatibilitäten gibt (bspw. auch kein LTE bei einer 6820 LTE oder kein GPON bei einer 5491 usw.)? Jedenfalls kann ich bestätigen, dass LTE mit der Fritzbox 6840 LTE zumindest mit einem Freetz-Image (Freetz-NG verwende ich nicht) funktioniert (also schon einmal kein generelles Problem ;)).
 
Zuletzt bearbeitet:

koronth

Neuer User
Mitglied seit
21 Nov 2008
Beiträge
59
Punkte für Reaktionen
1
Punkte
8
So, habe nun (auch) probiert alle für mich sichtbaren Optionen, die Änderungen vornehmen, in Freetz rauszunehmen (so auch das erwähnte Freezmount) - damit funktioniert LTE auch nicht.

Im No_Freetz-Modus funktioniert LTE wieder.

Mit diesem No_Freetz-Image und aktiviertem Telnet habe ich den angehängten dmesg-Output von der funktionierenden Box gezogen.
"Markiert" sind zwei Bereiche in denen LTE via AVM-Weboberfläche aktiviert und deaktiviert (auf DSL umgeschaltet) wurden.
Vielleicht kann ja hier schon jemand was sehen; ich suche weiter ...
 

Anhänge

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,147
Punkte für Reaktionen
1,033
Punkte
113
Das ist aber schon mal eine Aussage/ein Test, mit der/m man etwas anfangen kann - es ist also definitiv irgendeine Änderung, die vom Freetz-Mod vorgenommen wird und die am Ende dazu führt., daß LTE nicht länger funktioniert (EDIT: und nicht schon die Tatsache an sich, daß da eine eigene Firmware installiert wurde).

Damit macht die Fehlersuche ja auch wieder richtig Sinn ... ich schaue heute abend mal rein ins Protokoll, wenn nicht vorher schon jemand anderes das Problem gefunden hat.

Schön wäre es noch, die verwendete ".config.compressed" (erstellt mittels "make config-compress": https://github.com/Freetz/freetz/pull/283) und mit einer ".txt"-Erweiterung (sonst klappt der Upload hier nicht) anzuhängen. Theoretisch sollten ja dann alle Änderungen (ggü. der Standard-Konfiguration) sich auf das Umstellen des Modells beschränken.

EDIT: Ein schneller Blick in das Protokoll zeigt zumindest einen wichtigen Unterschied ... beim Freetz-Protokoll wurden die drei "ttyACM"-Devices (Abstract Control Model für CDC) nicht angelegt.

Ich würde hier als allererstes mal den Inhalt des Verzeichnisses "udev" zwischen Freetz und "Original" vergleichen - ich tippe auf Änderungen an den "rules", die von Freetz vorgenommen wurden/werden.

Es dauert aber definitiv noch, bis der RasPi4, den ich jetzt mal auf das Erstellen der Toolchain für die 6890 angesetzt habe (auch wenn das eigentlich die "normale" für GRX5-Boxen sein müßte), zu einem ersten Ergebnis kommt und ich damit auch nur in die Nähe eines eigenen "Freetz-Images", in dem ich dann selbst nachsehen könnte.
 

koronth

Neuer User
Mitglied seit
21 Nov 2008
Beiträge
59
Punkte für Reaktionen
1
Punkte
8
Vielen Dank für den Hinweis auf die Device-Files!

Der Vollständigkeit hier noch das angeforderte .config.compressed des minimalen Freetz-Images (das No-Freetz-Config unterscheidet sich bloß durch "FREETZ_FWMOD_SKIP_MODIFY=y", wie Du wahrscheinlich sowieso weißt) sowie der Output beim (fehlgeschlagenen) Versuch LTE zu aktivieren, aus dem syslog mit Freetz.
[Edit Novize: Beiträge gemäß der Forumsregeln zusammengefasst]
Und hier noch die Listing des /dev-Verzeichnisses - einmal für LTE working und einmal für nicht.

Edit: Im neu angehängten devices-diff.txt sollten alle special Files drin sein, die NUR in der LTE-working-Variante vorhanden sind.

Ein Vergleich der Dateien /etc/udev/rules.d/60-persistent-serial.rules sowie /etc/udev/rules.d/39-mobiled.rules im build/original/- & build/modified/-Baum zeigt übrigens keinen Unterschied.
 

Anhänge

Zuletzt bearbeitet von einem Moderator:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,147
Punkte für Reaktionen
1,033
Punkte
113
Das bestätigt zwar die Feststellung, daß die ttyACM*-Devices nicht eingerichtet werden, wenn das LTE-Interface erkannt wird, aber es erklärt noch nicht, warum das so ist.

Bitte nicht dahingehend "mißinterpretieren", daß hier irgendjemand von Hand jetzt passende Special-Files unter "/dev" anlegen sollte ... das ist die Aufgabe des "udevd" und was der in welcher Reihenfolge machen soll und für welche Devices (in diesem Falle anhand ihrer USB-IDs identifiziert), wird in den "udev rules" festgelegt und die stehen genau in dem o.a. Verzeichnis "/etc/udev".

In der originalen Firmware kann man sehen, daß praktisch bei jeder Änderungen am Zustand des USB-Subsystems eine entsprechende Meldung an den "mobiled" geht (über "rpctrl" in der "/etc/hotplug/udev-mobiled") und ich würde wetten, daß da durch eine Änderung seitens Freetz irgendeine dieser Benachrichtigungen unter die Räder kommt.

Was man vielleicht auch erst mal klären sollte, ist die Frage, ob in der "/etc/init.d/S52-mobiled" der Start des Daemons auch erfolgreich ist (ggf. einfach mal mit "ps" nachsehen, ob er läuft) - solange der nicht vorhanden ist, kann man den auch nicht über RPC steuern.

Ich weiß nicht, ob der "mobiled" auch mit dem Framework von AVM für "interprocess communication" arbeitet (so interpretiere ich das "A(VM) I(PC)" und den Daemon dafür jedenfalls) und somit auf ein "aicmd mobiled" reagiert oder nur auf "rpctrl" - aber einen Versuch ist es allemal wert, zumal per "aicmd" oftmals den AVM-Daemons (die das unterstützten, wobei das meist nur die neueren bzw. in den letzten Versionen renovierten sind) noch so manche sinnvolle Info entlockt werden kann (sonst hätten die AVM-Leute die "daemon-spezifischen" Kommandos wohl auch kaum implementiert, denn das sind ja keine Automatismen).
 

koronth

Neuer User
Mitglied seit
21 Nov 2008
Beiträge
59
Punkte für Reaktionen
1
Punkte
8
Mobiled läuft:

2442 root 6920 S /bin/mobiled -D history

/etc/hotplug/udev-mobiled wurde von freetz nicht verändert.

Edit: Was kann Freetz daran hindern das LTE-Modem zu erkennen? Im obigen device-diff.txt fehlt ja auch folgender Bereich:

Code:
/dev/serial:
drwxr-xr-x    2 root     root           100 Jan  1  1970 by-id
drwxr-xr-x    2 root     root           100 Jan  1  1970 by-path

/dev/serial/by-id:
lrwxrwxrwx    1 root     root            13 Jan  1  1970 usb-FIBOCOM_L830-EB-11_004999010640000-if00 -> ..
/../ttyACM0
lrwxrwxrwx    1 root     root            13 Jan  1  1970 usb-FIBOCOM_L830-EB-11_004999010640000-if02 -> ..
/../ttyACM1
lrwxrwxrwx    1 root     root            13 Jan  1  1970 usb-FIBOCOM_L830-EB-11_004999010640000-if04 -> ../../ttyACM2

/dev/serial/by-path:
lrwxrwxrwx    1 root     root            13 Jan  1  1970 platform-xhci-hcd.1.auto-usb-0:1:1.0 -> ../../ttyACM0
lrwxrwxrwx    1 root     root            13 Jan  1  1970 platform-xhci-hcd.1.auto-usb-0:1:1.2 -> ../../ttyACM1
lrwxrwxrwx    1 root     root            13 Jan  1  1970 platform-xhci-hcd.1.auto-usb-0:1:1.4 -> ../../ttyACM2

Edit2: mobiled ist zumindest nicht im Output von aicmd zu sehen:

Code:
# aicmd -l
local:upnpd
local:meshd
local:voipd
local:deviceinfod
local:dsld
local:pcpd
local:multid
local:ctlmgr
local:avmnexusd
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,147
Punkte für Reaktionen
1,033
Punkte
113
@koronth:
Mach mal ein "diff -Naur" über die "/etc/udev"-Verzeichnisse im Original und in Freetz - irgendwo da sollte der Hase im Unterholz lauern.

EDIT: Die fehlenden Devices sind das Ergebnis einer fehlenden oder fehlschlagenden "udev"-Aktion - notfalls kann man auch da mal das "udevadm" bemühen für eine ausführlichere Protokollierung bzw. auch für einen Vergleich zwischen Original und Freetz ... da sollte man gleich sehen, welche Aktionen in Freetz "fehlen".
 

NDiIPP

IPPF-Promi
Mitglied seit
13 Apr 2017
Beiträge
3,418
Punkte für Reaktionen
613
Punkte
113
Da ich vor ein paar Monaten mal ein Freetz-Image für die 6890 auf Basis von FRITZ!OS 7.13 gebaut hatte (welches jedoch nie auf einer 6890 LTE zum Einsatz kam, daher auch unbekannt ob dieses mit LTE laufen würde oder nicht) und der Build-Ordner dazu zufälligerweise noch vorhanden war, könnte ich dbzgl. mal behilflich sein:
Diff:
diff -Naur /home/user/Downloads/freetz/freetz_2020-02-05_GRX5-6890/build/original/filesystem/etc/udev/rules.d/50-udev-default.rules /home/user/Downloads/freetz/freetz_2020-02-05_GRX5-6890/build/modified/filesystem/etc/udev/rules.d/50-udev-default.rules
--- /home/user/Downloads/freetz/freetz_2020-02-05_GRX5-6890/build/original/filesystem/etc/udev/rules.d/50-udev-default.rules    2019-11-25 17:16:52.000000000 +0100
+++ /home/user/Downloads/freetz/freetz_2020-02-05_GRX5-6890/build/modified/filesystem/etc/udev/rules.d/50-udev-default.rules    2020-02-07 15:58:56.686104000 +0100
@@ -91,7 +91,7 @@
SUBSYSTEM=="aoe", KERNEL=="err", MODE="0440"

# network
-KERNEL=="tun",            MODE="0666", OPTIONS+="static_node=net/tun"
+KERNEL=="tun",            MODE="0666", OPTIONS+="static_node=net/tun", SYMLINK+="tun"
KERNEL=="rfkill",        MODE="0644"

# CPU
Ist aber nicht mit dem derzeit aktuellen Freetz gemacht worden sondern mit "master-20200121-c7f6780b9". Es gibt jedenfalls bei mir nur in einer Datei einen kleinen Unterschied (s.o.), der das Problem imo eigentlich nicht verursachen dürfte. Vielleicht gibt es ja mit dem aktuellen Freetz und/oder anderer .config bei @koronth tatsächlich noch weitere Unterschiede dort...
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,147
Punkte für Reaktionen
1,033
Punkte
113
Wenn's keine offensichtlichen Unterschiede bei den Regeln gibt, wäre m.E. wieder der "udevadm" der nächste Schritt ... irgendetwas muß unter Freetz ja verhindern, daß "cdc_acm.ko" geladen wird (dieses LKM sollte die ttyACM-Ports einrichten).

Jedenfalls fehlt der Teil komplett in der "dmesg"-Ausgabe bei der Freetz-Version und anhand dessen, was man in der originalen AVM-Firmware sehen kann, würde ich sagen, daß der eigentlich über die "Zuständigkeit" von "cdc_avm" für die passende VID/PID irgendeines USB-Devices/-EPs (automatisch) gestartet werden sollte.

Welcher das am Ende ist, sollte ein ausführliches Protokoll des "udevd" zeigen - ggf. über "udevadm control -l debug" das Log-Level hochsetzen, die Ausgaben sollten in das Kernel-Log erfolgen und mit "dmesg" zu sehen sein.

Zunächst könnte es aber Sinn machen, unter dem unmodifizierten System erst mal die Pfade für "/dev/lte*" bzs. "/dev/ttyACM*" über ein "udevadm info devname" zu ermitteln, damit man hinterher weiß, auf welche Pfade man einen Filter bei der Ausgabe der Ereignisse des Kernels bzw. des "udevd" setzen kann, wenn man mittels "udevadm trigger" bzw. "udevadm test" gezielt die Abläufe bei der Erkennung des LTE-Modems simulieren/testen will - alles auf einmal ist etwas viel, weil dann auch der ganze WLAN- und PCI-Schotter dabei ist, bis hin zu den USB-Host-Controllern.
 

koronth

Neuer User
Mitglied seit
21 Nov 2008
Beiträge
59
Punkte für Reaktionen
1
Punkte
8
Vielen Dank für Eure Mühe!

Ich selber bin nun etwas ratlos. Wieso erkennt denn der Kernel unter Freetz anscheinend nur einen Teil der LTE-bezogenen Geräte? (3-1-*) Das dürfte doch (noch) nichts mit udev zu tun haben, oder?

Es sind auch dieselben Kernelmodule geladen. Nur wird cdc_acm zwei Mal benutzt, wenn LTE funktioniert, sonst ist der used count bei 0.

Ist das irgendein Timing-Problem? IMHO macht ja auch AVM schon irgendwelche Retries, wenn die LTE-Devices nicht gleich da sind ...
 

Anhänge

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,147
Punkte für Reaktionen
1,033
Punkte
113
Lass mal den "cdc_acm" von Hand laden ... es geht darum, ob die USB-Devices mit Major-ID 166, für die er lt. "modules.alias" zuständig wäre:
Code:
alias char-major-166-* cdc_acm
existieren oder nicht. Auch ein "lsusb -v" kann nicht schaden, wobei das Programm in der AVM-Version nur sehr spärliche Infos liefert.

Immerhin bietet das Modem ja 13 USB-Interfaces an, wie man dem "walk" des "udevadm" entnehmen kann:
Code:
  looking at parent device '/devices/1a000000.ssx2/1a500000.usb/xhci-hcd.1.auto/usb3/3-1':
    KERNELS=="3-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{bDeviceSubClass}=="02"
    ATTRS{bDeviceProtocol}=="01"
    ATTRS{devpath}=="1"
    ATTRS{idVendor}=="2cb7"
    ATTRS{speed}=="480"
    ATTRS{bNumInterfaces}=="13"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{busnum}=="3"
    ATTRS{devnum}=="5"
    ATTRS{configuration}==""
    ATTRS{bMaxPower}=="100mA"
    ATTRS{authorized}=="1"
    ATTRS{avm_usb_suspend_delay}=="60"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{maxchild}=="0"
    ATTRS{avm_usb_suspend_enable}=="0"
    ATTRS{bcdDevice}=="0333"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{noprobe}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{serial}=="004999010640000"
    ATTRS{version}==" 2.00"
    ATTRS{urbnum}=="8046"
    ATTRS{avm_usb_suspend_status}=="active"
    ATTRS{ltm_capable}=="no"
    ATTRS{manufacturer}=="FIBOCOM"
    ATTRS{removable}=="unknown"
    ATTRS{idProduct}=="000b"
    ATTRS{bDeviceClass}=="ef"
    ATTRS{product}=="L830-EB-11"
Schon die Tatsache, daß es da Attribute gibt, deren Namen mit "avm" beginnen, zeigt, daß der Treiber von AVM noch einmal verändert wurde ... das gilt (nebenbei) auch für den XHCI-Treiber insgesamt, dem AVM in der 6890-Version einen zusätzlichen Parameter spendiert hat, mit dem wohl einige Endpoints von Bulk- auf Interrupt-Modus "umgestellt" werden (bzw. der Host dann für diese EPs auch ins INTR-Polling geht).

Je nach Ergebnis hinsichtlich der USB-Interfaces muß man dann weitersehen und das hängt auch mit der Frage der "Erkennung" zusammen. Man kann zwar nicht mehr in den "mobiled" hineinsehen und ihm auch keine unbekannten USB-Geräte mehr unterjubeln, wie das zuvor noch bei den USB-Modems funktionierte, aber ich würde wetten, daß auch die (fest verbauten) LTE-Modems erst mal per USB-Kommando auf den gewünschten "Modus" eingestellt werden müssen (früher übernahm das "sndusbmsg") und daß hier diese "Umschaltung", die wohl auch der "mobiled" machen müßte, irgendwie nicht so funktioniert, wie sie sollte.

Zumindest wäre das (auch unter "großen Linux-Systemen") ja der Weg ... das USB-Gerät wird (mit seinem generischen Interface, ggf. ist das auch eines für ein Storage-Device, wo dann z.B. die Treiber für verschiedene OS in einer CD-Emulation aus dem Flash geladen werden können) erkannt und danach in den passenden Modus versetzt - siehe das "usb-modeswitch"-Projekt/-Paket.

Ich weiß zwar auch nicht genau, wie sich das L830-EB-11 verhält und wie eine 6890v2 innen aussieht - aber vermutlich ist das am Ende auch ein stinknormales Modem mit M.2-Connector (https://fccid.io/ZMOL830EB11/User-Manual/User-Manual-3576960.pdf) oder zumindest ein pin- und funktionskompatibler Chip, der irgendwo direkt aufgelötet ist. Damit sollte der sich genauso verhalten ... so, wie er das auch in Laptops o.ä. als LTE-Modem machen müßte.

=============================================================================

Wobei ich noch eine (schnell zu realisierende) Idee hätte ... dieser Patch:
Code:
diff --git a/fwmod b/fwmod
index fec17a5bf..5cb71c10f 100755
--- a/fwmod
+++ b/fwmod
@@ -1221,13 +1221,6 @@ if [ "$DO_MOD" -gt 0 ]; then
        fi
    fi

-   for f in modules.dep.bin modules.alias.bin modules.builtin.bin modules.symbols.bin; do
-       if [ -e "$MODULES_DIR/$f" ]; then
-           echo1 "removing (unused) $f"
-           rm -f "$MODULES_DIR/$f"
-       fi
-   done
-
    kolinecnt="$(cat $MODULES_DIR/modules.dep | wc -l)"
    kofilecnt="$(find $MODULES_DIR -type f -name '*.ko' | wc -l)"
    echo1 "kernel modules installed: $kolinecnt entries in modules.dep and $kofilecnt .ko-files found."
wäre auch noch einen Versuch wert.

Die Idee dabei ist es, daß ggf. ein AVM-Daemon (hier der "mobiled") sich um das Laden der notwendigen LKM selbst kümmert und dabei auf die binären Versionen der Module-Listen zugreift (was einfacher zu implementieren ist), die früher tatsächlich nicht benötigt wurden (weil das "modprobe" der BusyBox sie ohnehin ignoriert) und daher "aus Platzgründen" entsorgt wurden.

Das ist zwar "nur so eine Idee", aber nach meiner Erinnerung ein deutlicher Unterschied zwischen dem originalen AVM-Image und einem Freetz-Image, wo das Entfernen der "bin"-Dateien (außer im "no-freetz mode") zum Standard-Repertoire gehört. Solange die niemand benutzen will, ist ja auch alles gut - wenn aber "Spezial-Daemons" von AVM dann doch darauf zurückgreifen sollten (und DVB bzw. LTE wären ja jeweils "Spezialfälle" von Software, die in anderen Modellen fehlt), dann könnte das Problem auch darin liegen.
 
Zuletzt bearbeitet:

koronth

Neuer User
Mitglied seit
21 Nov 2008
Beiträge
59
Punkte für Reaktionen
1
Punkte
8
Vielen Dank für die Idee!

Leider hatte ich das schon gestern abend erfolglos probiert, da mir auch die fehlenden *.bin-Datein ins Auge gesprungen waren.
 

Zurzeit aktive Besucher

3CX

Neueste Beiträge

Statistik des Forums

Themen
235,868
Beiträge
2,066,971
Mitglieder
356,839
Neuestes Mitglied
FH2020