@Vobe:
Wobei schon die Feststellung, der Stick würde nicht erkannt, ja anhand des Screenshot in #93 ganz klar als falsch anzusehen ist. Der Stick wird als Mobilfunk-Modem
erkannt (selbst das Storage-Device ist ja nach der Umschaltung verwendbar), er wird lediglich nicht genutzt, weil die Mobilfunk-Option (gemäß Screenshot) deaktiviert ist. Es liegt also ziemlich sicher nicht an der Umschaltung des Sticks und da werden Dir dann auch weitere "round trips" aus "Abstecken und wieder Anstecken" eher nicht weiter helfen. Du solltest mal die Einstellungen bzgl. des Mobilfunks prüfen ... und das meint nicht nur die im GUI, sondern auch die in den Konfigurationsdateien, die Dir notfalls nach dem Export auch zugänglich sind. Auch ein zwischenzeitlicher Test mit den Werkseinstellungen (den Rest kann man ja später wiederherstellen, wenn man einen Plan hat) könnte weitere Klarheit bringen, ob nicht in den vorhandenen Einstellungen etwas so durcheinander ist, daß das Modem nicht genutzt wird. Nach den letzten Änderungen
infolab.txt für 6.36-31299 schrieb:
Behoben - Optionen zur Nutzung von USB-Tethering auf der Seite Internet / Mobilfunk wurden fehlerhaft gesetzt
würde ich so eine Möglichkeit auch nicht generell ausschließen. Aber es fehlen eben jede Menge Informationen Deinerseits ... außer der (falschen) Feststellung und dem o.a. Screenshot habe ich noch nicht viele belastbare Informationen dazu hier gelesen.
-Zur Umschaltung der USB-"Modems" generell ...
Wenn es sich wirklich um ein Problem der Umschaltung so eines Devices handelt, kann das Löschen der usbgsm.cfg tatsächlich unter gewissen Umständen helfen.
Die Version des Templates (12) hat sich seit einiger Zeit nicht geändert (daher gibt es auch keine "automatischen Updates" innerhalb der Firmware für diese Datei), aber es wird nach wie vor noch in der aktuell verwendeten Datei nach der "ignore"-Zeile gesucht:
Code:
if grep -qi "^[V]=.*:$VID:" $CFG_FILE ; then
touch $IGNORE_FILE
[COLOR="#FF0000"]if ! grep -qi "^[I]=.*:$VID$PID:" [COLOR="#0000FF"]$CFG_FILE[/COLOR] $IGNORE_FILE ; then
[/COLOR]if grep -q -e ff -e 0a -e 02 ${USBDEVPATH}/*/bInterfaceClass ; then
grep -q -e 08 /sys/${DEVPATH}/bInterfaceClass || echo DEVCLASS=usbgsm
else
grep -q -e 08 ${USBDEVPATH}/*/bInterfaceClass && echo DEVCLASS=usbgsm
fi
fi
fi
Sollte da also eine Zeile "i:=vvvvdddd" in der verwendeten usbgsm.cfg stehen (keine Ahnung, wie die dahin geraten sein kann), wird so ein Stick gar nicht erst als Modem in Erwägung gezogen (ist bei Vobe aber definitiv nicht das Problem, soll nur noch mal anderen vor Augen führen, daß zwar die "Forderung" nach dem Löschen der Datei etwas übertrieben scheinen mag, aber das ist bei den meisten einfacher als die Abfrage, was da tatsächlich drin steht).
Auch noch einmal der Hinweis, daß die Dateien /var/tmp/usbgsm.log, /var/tmp/usbgsm.ignore und /var/tmp/usbgsm.log.old (auch die ist wichtig, weil sie den letzten Anlauf des Umschaltens protokolliert, wenn es beim ersten nicht funktioniert) in Kombination mit den zugehörigen Eventlog-Einträgen (findet man auch alles in den Support-Daten, wenn man es per Telnet nicht auslesen kann) dem Rätselraten bei der "Nichterkennung" von USB-Devices (Modems, CDCs) relativ schnell ein Ende setzen können.
AVM experimentiert an dieser Stelle mit der Reihenfolge und dem Zeitpunkt des Ladens und Entladens von Treiber-Modulen (kann man mit einfachem "diff" für die Unterschiede in den Dateien /etc/hotplug/usb-gsm-* (auch die usb-rndis-usb nicht vergessen) zwischen den Versionen leicht feststellen), denn es macht eben einen gewaltigen Unterschied im Ablauf aus, ob so ein Stick beim Neustart der Box bereits angesteckt (und auch schon umgeschaltet) ist oder nicht.
OT: Dankenswerterweise kommt AVM nicht auf die Idee, durch Abschalten der USB-Speisung erst einmal einen definierten Zustand herzustellen und praktisch bei jedem Start solche Sticks neu zu initialisieren. Das, was bei GSM-/UMTS-Sticks noch wie eine gute Idee aussehen mag, wird schnell zur elektrischen und mechanischen Belastungsprobe, wenn da eben eine "richtige HDD" an so einem USB-Anschluß hängt (die hat auch eine "storage"-Interface-Klasse) und diese ständig erneut per "aus/ein" neu gestartet würde. Zwar wird auch bisher bei einem Neustart der Box
ein Stop-/Start-Zyklus für eine per USB angeschlossene HDD durchlaufen (dem Gehör nach), ob der aber aus einem Reset seitens der HDD oder dem Abschalten der Versorgung durch die Box resultiert, kann man ohne Protokoll-Analyzer schlecht feststellen. Davon ausgehend, daß ein GSM-Stick bei mir "umgeschaltet" bleibt, würde ich eher vermuten, daß es kein Abschalten der USB-Spannung ist. BTT ...
Wenn die Firmware ein passendes USB-Device für Tethering findet (in udev-rndis-usb, da muß die Interface-Klasse, die Subclass und das Protokoll passen), prüft sie als nächstes, ob der "option"-Treiber geladen ist. Wenn ja, versucht sie gar nicht erst irgendwelche weiteren Aktionen mit diesem Tethering-Device:
Code:
if [ -e /sys/class/net/usb0 ]; then
if [ ! -e /sys/module/option ]; then
echo "trigger USB_TETHERING ..." > $CONSOLE
msgsend ctlmgr usbtether_hotplug
else
[COLOR="#0000FF"]echo "unloading USB_TETHERING drivers due to AT-Modem driver..." > $CONSOLE
modprobe -r rndis_host[/COLOR]
fi
fi
Stattdessen wird der "rndis_host"-Treiber einfach wieder entladen (wenn das funktioniert, bei einigen Treibern hat AVM offenbar den Code zum Entladen entsorgt - zumindest werden die entsprechenden Aufrufe von den Treibern mit Fehlermeldungen quittiert) und zumindest der "NDIS mode" bei diesem Tethering nicht verwendet (hat ja wenig mit CDC-Devices zu tun, läuft aber m.W. bei AVM beides unter "Tethering").
Daher kann man auch nicht einfach der Firmware "sagen", sie solle bei zwei potentiellen Möglichkeiten der Verbindung (1x Modem, 1x Smartphone-Tethering) einfach das Modem ignorieren und das Smartphone benutzen. Solche Kombinationen funktionieren also bei der derzeitigen Firmware genauso wenig, wie die Kombination zweier Sticks (einer für Telefonie, einer für Daten) an derselben Box. Eine solche Kombination hat ja durchaus ihren eigenen Reiz, wenn man für die Telefonie ein "altes Arbeitspferd" verwenden kann, das zuverlässig funktioniert und auch bei der Telefonie keine Sperenzien macht (das Lautstärke-Problem kommt mir da wieder in den Sinn) und parallel für die Datenverbindungen einen modernen Stick für LTE verwendet, die in aller Regel ja deutlich dünner gesät sind, wenn sie mit CSV-Verbindungen auch noch klar kommen sollen (abgesehen davon, daß man bei Sticks im CDC-Mode u.U. (z.B. bei HiLink-Devices) auch über den Webserver auf die SMS-Funktionen zugreifen kann, was bei Verwendung des AVM-csvd und -umtsd für COM-Interfaces auch nicht problemlos klappt).
Wie das mit der Erkennung beim CDC-Modus eines USB-Sticks aussieht (dafür muß ebenfalls die Interface-Klasse passen, wenn der erste "check_class"-Aufruf erfolgt), kann man sich auch ansehen (mal darf ein "storage interface" vorhanden sein, mal nicht) ... allerdings sind eben konkrete VID- und PID-Angaben sinnvoller als ein "Trockentest" mit rein theroretischen Werten und auch das Protokoll, was die Firmware da bei einer problematischen Kombination aus Firmware und Stick eigentlich tatsächlich macht, enthält sicherlich wichtige Informationen dazu.
Zumindest die Feststellung, woran es denn nun liegt, ist also mit einfachen Mitteln möglich ... besser als reines Konstatieren "geht nicht", wäre das imho allemal.
.
