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.