[Gelöst] USB Probleme Fritzbox 7390

gklank

Neuer User
Mitglied seit
9 Jan 2009
Beiträge
29
Punkte für Reaktionen
0
Punkte
6
Hallo,

ich bin mir sicher, dass mit dem Image 7390_06.04-rev27435_labor-freetz-devel-12015M.de_20140511-023612.image
bzw. mit dem entsprechenden Firmwarestand mein Huawei E160 als /dev/ttyUSB0 und mein CUL an /dev/ttyACM0@9600 beide liefen.
es gibt noch einen USB-Memory-Stick und eine USB-Festplatte an dem USB-Hub...

Auch nach einem reboot haben sich beide automatisch eingeklinckt.

Jetzt mit keinerlei Änderungen meiner Einstellungen, lediglich mit svn up auf "Letzte geänderte Rev: 12111"
und dem Image 7390_06.10-rev28144_labor-freetz-devel-12111M.de_20140609-004346.image bzw. dem entsprechenden S/W Stand läuft der Huawei E160 nicht mehr.

Auch ein umstecken am USB Hub, bzw. ein und ausstecken im Betrieb bringen nichts.
Interessanterweise geht nach einem Reboot der Huawei nicht aber auch nicht der CUL.
Cul ziehen und wieder reinstecken bringt den dann sofort wieder zum Funktionieren.

Klar wäre es eine Möglichkeit auf das alte Image zurückzugehen, was ich aber nicht möchte...

Für eine Idee wäre ich sehr dankbar.

Gruß,

bsv
 
Zuletzt bearbeitet:
Für eine Idee wäre ich sehr dankbar.
AVM hat (wohl zur Unterstützung von NDIS-USB-Sticks) an der USB-GSM-Baustelle heftig geändert.

Mach doch einfach mal eine Telnet-Sitzung auf (wichtig ist die Umleitung von /dev/console in dieser Sitzung) und sieh Dir an, was von udev-gsm-usb dort zur Umschaltung des Huawei in den GSM-Modus angezeigt wird. Vielleicht bist Du ja dann schon schlauer, weil eventuell die Umschaltung schon fehlschlägt.

Ansonsten könntest Du auch die Datei /var/flash/usbgsm.cfg probehalber löschen (eine Sicherung sollte in den zuvor gesicherten Konfigurationseinstellungen vorhanden sein, da sind aber auch keine benutzerdefinierten Einstellungen drin) und nach einem Neustart noch einmal probieren. Früher wurde nach einer erfolgreichen Umschaltung eines UMTS-Sticks in der letzten Zeile dieser Datei das dafür verwendete Kommando gespeichert, damit nicht jedesmal aufs Neue alles durchprobiert werden mußte. Wenn das jetzt irgendwie nicht mehr passen sollte, könnte es durch das Löschen behoben werden.

Edit: /var/flash/usbgsm.cfg zu löschen heißt natürlich nicht: 'rm /var/flash/usbgsm.cfg', sondern 'echo -n >/var/flash/usbgsm.cfg'.
 
Zuletzt bearbeitet:
Hallo,


vielen Dank.
Durch usbgsm Änderungen von AVM ging bei mir nach dem reboot der CUL und der Huawei E160 nicht mehr.
Den CUL brachte ich wieder zum Funktionieren, durch das Abziehen und wieder anstecken...

Durch das Löschen "echo -n >/var/flash/usbgsm.cfg" funktioniert immerhin der CUL nach dem Reboot direkt wieder...

Weitere Versuche mach ich jetzt noch mit dem Huawei...

Gruß,

gklank
 
Hallo,

ich konnte mich zeitlich nicht näher mit dem Problem beschäftigen.
Habe lediglich ein svn up auf die Version 12270 gemacht.
Allerdings keine Verbesserung für meine Konfiguration.

Zudem muss ich gestehen, dass ich den Tipp im Thread 2 "udev-gsm-usb dort zur Umschaltung des Huawei..." über die console näher zu untersuchen, nicht in der Lage bin richtig umzusetzen.

Gibt es weitere Tipps oder Threads wo ich weiter nachlesen kann?

Danke im Vorraus,


gklank
 
Zudem muss ich gestehen, dass ich den Tipp im Thread 2 "udev-gsm-usb dort zur Umschaltung des Huawei..." über die console näher zu untersuchen, nicht in der Lage bin richtig umzusetzen.
Kein großes Kunststück, einfach eine Telnet-Session ohne den Huawei-Stick starten und folgende Kommandos ausführen:
Code:
# cat /etc/default.Fritz_Box_7390/avm/usbgsm.cfg >/var/flash/usbgsm.cfg
Telnet-Sitzung (es muß die einzige Telnet-Session sein !) offen lassen und den Stick anstecken; alles, was jetzt in der Telnet-Session angezeigt wird, mitschneiden. Als krönenden Abschluß noch ein
Code:
# cat /var/flash/usbgsm.cfg
und die Ausgaben dann hier posten (ist ja nicht soo viel). Am besten aktualisierst Du aber vorher dein Freetz-Image noch auf die aktuelle AVM-Laborversion, da waren auch in letzter Zeit noch Änderungen im GSM-Teil.
 
Hallo,

Freetz ist auf 12291 mit aktueller Laborversion.

Das subgsm.cfg zeigt:

VER=:9
###
V=:0421:05c6:0af0:1199:12d1:1410:16d8:1bbb:1c9e:1e0e:19d2:1ee8:
V=:0b3c:07d1:2357:0fce:
###
C=:1199:400b01
C=:12d1:000301
C=:19d2:c0a115
C=:0fce:c01102
###
B=:16d8:555342431234567800000000000009ff524445564348473100000000000000
B=:1c9e:1bbb:55534243123456780000000080000606f50402527000000000000000000000
B=:05c6:0af0:55534243123456780100000080000601000000000000000000000000000000
B=:1e0e:555342431234567800000000000006bd000000020000000000000000000000
B=:12d1:55534243123456780000000000000011062000000101000100000000000000
B=:12d1:55534243876543210000000000000011062000000100000000000000000000
B=:12d1:55534243000000000000000000000611060000000000000000000000000000
B=:0b3c:5553424312345678c000000080010606f50402527000000000000000000000
B=:0421:05c6:0af0:1199:12d1:1410:16d8:1bbb:1c9e:1e0e:19d2:1ee8:5553424312345678000000000000061b000000020000000000000000000000
B=:0b3c:07d1:2357:0fce:5553424312345678000000000000061b000000020000000000000000000000
###
B=:12d11f19:55534243000000000000000000000611060000000000000000000000000000
###
S=:1c9e3003:2
S=:0fced0cf:3
S=:0fced0e1:2
###
M=:0af07251:D2
M=:1c9e9603:D2
M=:1c9e9605:D3V2C1
M=:1c9e3003:D1C2V3
M=:11996880:D3
M=:119968a3:D2
M=:1bbb0000:D2
M=:12d11001:12d11c05:12d114c9:D0V1C2
M=:12d11003:12d11c08:D0C1
M=:12d1140c:12d11436:12d11465:12d114ac:D0V2C3
M=:12d11444:D1C0
M=:1e0e9000:D2
M=:19d20031:19d20117:D2C1
M=:19d20063:19d20104:D3C1
M=:19d20143:D0C1
M=:19d22003:D3V2C1
###


Gruß,


gklank
der Smiley ist im Code ":" und danach das "D"
 
Das subgsm.cfg zeigt:
Die ist zwar interessant, aber bei der aktuellen Labor-Generation nicht mehr so sehr wie früher ... da wurde nämlich noch das aktuelle Umschaltkommando da drin gespeichert.

Viel wichtiger ist das Console-Log während des Ansteckens des Sticks, da steht dann drin, was so passiert oder auch nicht.
 
Hallo,


meinst Du diesen Teil:

usb 1-2.3: new high speed USB device using fusiv-ehci-hcd and address 11
usb 1-2.3: configuration #1 chosen from 1 choice
usb-storage: probe of 1-2.3:1.0 failed with error -5
usb-storage: probe of 1-2.3:1.1 failed with error -5
usb-storage: probe of 1-2.3:1.2 failed with error -5
USB Warning: Device HUAWEI Mobile From HUAWEI Technology Not Supported
[0]system-load 1 loadavg 2.55 1.74 0.72 - 114 tasks:83 % curr:busybox(0 %) max:minidlna(71 %, pid:3448), readytorun: 7, pgfault 144/s (max 1 avg 1.0)
[module-alloc-by-name] give 0x7000 bytes at 0x81572000 to module 'usbserial'
usbcore: registered new interface driver usbserial
usbserial: USB Serial Driver core
[module-alloc-by-name] give 0x3000 bytes at 0x81579000 to module 'option'
option: use params vendor=12d1 product=1001
USB Serial support registered for GSM modem (1-port)
option 1-2.3:1.0: GSM modem (1-port) converter detected
usb 1-2.3: GSM modem (1-port) converter now attached to ttyUSB0
option 1-2.3:1.1: GSM modem (1-port) converter detected
usb 1-2.3: GSM modem (1-port) converter now attached to ttyUSB1
option 1-2.3:1.2: GSM modem (1-port) converter detected
usb 1-2.3: GSM modem (1-port) converter now attached to ttyUSB2
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems
[ieee80211_ioctl_setmlme] non sta mode, skip to set bssid
[module-alloc-by-name] module alloc table full


Gruß,


gklank
P.S.: da steht leider "USB Warning: Device HUAWEI Mobile From HUAWEI Technology Not Supported" ....
 
meinst Du diesen Teil:
Eigentlich nicht unbedingt, aber das sieht nach syslog aus und enthält ja auch ein paar Informationen.

Wenn Du schon dank Freetz erweiterten Zugriff auf die Box hast, kannst Du ja auch mal ein lsusb hinterher schieben.

USB Warning: Device HUAWEI Mobile From HUAWEI Technology Not Supported
Das dürfte sich - dem Kontext nach - nur auf den usb-storage-Treiber beziehen. Warum das so ist, sieht man nur anhand der vom USB-Stick bereitgestellten Geräte und ihrer IDs.

[module-alloc-by-name] give 0x7000 bytes at 0x81572000 to module 'usbserial'
...
option: v0.7.2:USB Driver for GSM modems
Hier werden drei USB-Devices für die serielle Kommunikation mit dem Modem eingerichtet. Wenn Du am Anfang geschrieben hast
dem entsprechenden S/W Stand läuft der Huawei E160 nicht mehr.
, was meintest Du damit denn genau ? Ich komme langsam zu dem Schluß, daß Du den Stick gar nicht mit den AVM-Komponenten der Firmware ansprechen willst.

Über die richtigen der drei UART-Schnittstellen (1x Data, event. noch 1x Control) sollte sonst zumindest der "mobile" Datenzugriff über umtsd funktionieren. Die Erkennung des Sticks (von der Umschaltung sieht man nichts) funktioniert doch problemlos. Kann es event. sein, daß Du den Stick "vorbehandelt" hast, indem Du ihn anhand irgendwelcher Internet-Quellen in den "Modem"-Betrieb "gezwungen" hast ?

Ohne nähere Informationen zu diesem Stick (Vendor- und Product-ID beim Einstecken, ggf. beim Umschalten - wenn es überhaupt stattfindet - verwendete Kommandos und die resultierende VID/PID) kommt man da nicht weiter ... das wird alles von der AVM-Firmware beim Einstecken des USB-Sticks auf /dev/console protokolliert. Irgendwie werde ich aber den Verdacht nicht ganz los, daß bei Dir die Behandlung von GSM-Devices über udev-Hotplug gar nicht stattfindet und beim Erstellen des Freetz-Images per Patch abgeschaltet wurde. Es fehlen dazu ja praktisch alle Ausgaben von udev im Log.

Andere Möglichkeit:
module alloc table full
Ist Dein Image mit "Replace Kernel" erstellt ? Der Fehlermeldung nach ist Deine Modul-Tabelle zu klein. Im originalen AVM-Kernel sind weniger Einträge möglich, wurde irgendwann vor 1 1/2 Jahren mal aufgebohrt für "custom kernels". Wenn das Laden eines weiteren benötigten Moduls (welches es ist, sieht man leider nicht, müßte aber unmittelbar nach dem Log-Auszug irgendwo stehen) fehlschlägt, wäre das ja auch eine mögliche Ursache.
 
Hallo,

sorry, Du hast recht.
Meine Infos waren etwas dürftig.

- Ich möchte mit dem Stick lediglich SMSe verschicken und habe dazu unter Freetz SMStools3 eingebaut.
- Ich habe keine spezielle Modifikation am Stick vorgenommen
- kein "replace kernel" gemacht
- die SIM-Karte funktioniert und ich kann per Handy SMSe verschicken
- remove UMTS (USB GSM) ist nicht angewählt, also kein remove
- remove AURA ist angewählt, da kein USB-Fernanschluss geplant ist
- Patch GSM voice ist nicht angewählt
- Modify umtsd ist angewählt, da ich dachte, dass SMStools3 eben eine andere S/W ist mit der ich den Stick bedienen will
- Enable custom UDEV rules ist nicht angewählt
- smusbutil 1.1 ist angewählt
- unter Drivers / Kernel modules sind keine Module angewählt


Gruß,


gklank

root@FB7390:/var/mod/root# lsusb
BUS=002
DEV=001
VID=1d6b
PID=0001
CLS=09
SCL=00
SPEED='full'
VER='1.1'
ISOC=0
INUM=1
ICLS1=09
ISCL1=00

BUS=001
DEV=001
VID=1d6b
PID=0002
CLS=09
SCL=00
SPEED='hi'
VER='2.0'
ISOC=0
INUM=1
ICLS1=09
ISCL1=00

BUS=001
DEV=002
VID=1a40
PID=0101
CLS=09
SCL=00
SPEED='hi'
VER='2.0'
ISOC=0
INUM=1
ICLS1=09
ISCL1=00

BUS=001
DEV=004
VID=0403
PID=6001
CLS=00
SCL=00
SPEED='full'
VER='2.0'
ISOC=0
INUM=1
ICLS1=255
ISCL1=255

BUS=001
DEV=005
VID=0403
PID=6001
CLS=00
SCL=00
SPEED='full'
VER='2.0'
ISOC=0
INUM=1
ICLS1=255
ISCL1=255

BUS=001
DEV=003
VID=2109
PID=2812
CLS=09
SCL=00
SPEED='hi'
VER='2.1'
ISOC=0
INUM=1
ICLS1=09
ISCL1=00

BUS=001
DEV=006
VID=2109
PID=2812
CLS=09
SCL=00
SPEED='hi'
VER='2.1'
ISOC=0
INUM=1
ICLS1=09
ISCL1=00

BUS=001
DEV=009
VID=03eb
PID=204b
CLS=02
SCL=00
SPEED='full'
VER='1.1'
ISOC=0
INUM=2
ICLS1=02
ISCL1=02
ICLS2=10
ISCL2=00

BUS=001
DEV=007
VID=0951
PID=1643
CLS=00
SCL=00
SPEED='hi'
VER='2.0'
ISOC=0
INUM=1
ICLS1=08
ISCL1=06

BUS=001
DEV=011
VID=12d1
PID=1001
CLS=00
SCL=00
SPEED='hi'
VER='2.0'
ISOC=0
INUM=3
ICLS1=255
ISCL1=255
ICLS2=255
ISCL2=255
ICLS3=255
ISCL3=255

BUS=001
DEV=010
VID=1058
PID=1140
CLS=00
SCL=00
SPEED='hi'
VER='2.1'
ISOC=0
INUM=1
ICLS1=08
ISCL1=06
 
Zuletzt bearbeitet:
Ich möchte mit dem Stick lediglich SMSe verschicken und habe dazu unter Freetz SMStools3 eingebaut.
Ok, das erklärt einiges.

Theoretisch sollte dann bei Deinem Stick die Datenverbindung über ttyUSB0, die Voice-Daten über ttyUSB1 (bei Dir ja nicht benutzt) und die Steuerung über ttyUSB2 laufen.

Am besten packst Du mal minicom mit in das Image und testest damit erst einmal, ob die Kommunikation mit AT-Kommandos auf ttyUSB0 und ttyUSB2 prinzipiell klappt. Um Probleme mit der zu kleinen Modul-Tabelle auszuschließen, lass einfach erst einmal den CUL weg, dann brauchst Du schon mal cdc_acm.ko nicht zu laden / wird er nicht geladen.

Ansonsten wäre die Konfigurationsdatei von SMSTools3 (am besten die ganze, mindestens der device=-Eintrag) und das Protokoll von SMSTools3 wichtig.

Dem Syslog-Auszug nach zu urteilen, werden die tty-Devices ja richtig erkannt und eingebunden. Wenn wirklich der udev-Mechanismus von AVM greift, müßten auch unter /var/gsm die richtigen tty-Devices als "ttyDATA" und "ttyCONTROL" verlinkt sein.

Also sollte das Problem irgendwo anders liegen als bei der Initialisierung der tty-Devices ...

Edit: Dein lsusb-Listing zeigt die drei Modem-Devices alle als "custom" (255/255), damit sollte es aber klappen. Mein E3131 sieht (bei entsprechender Umschaltung) auch so aus und wird problemlos vom option-Treiber eingebunden. Allerdings irritiert mich immer noch etwas, daß Dein E160 eigentlich ursprünglich VID/PID 12D1:1446 oder 12D1:1003 haben müßte (mit mindestens einem Gerät mit ICLSx=08/ISCLx=06 für das "CD-ROM") und erst nach erfolgter Umschaltung auf 12D1:1001 gehen sollte. Wenn das nicht der Fall ist, wurde der doch schon "dauerhaft umgeschaltet". Daß der Stick sich native mit FF/FF-Devices meldet, kann ich eigentlich nicht glauben, das wäre m.E. nicht wirklich konform zum Standard. Aber im Listing siehst Du ja auch, daß der Stick bei Dir letzten Endes ja gar kein Storage-Device (08/06) anbietet, damit ist auch klar, warum der usb-storage damit nicht spielen will.
 
Zuletzt bearbeitet:
Hallo,

sorry, dass ich mich immer mit so großen Abständen melde.
Aber ich habe nur ganz unterschiedlich mal Zeit und mal nicht.

Ich meine zwar nicht gerade gar kein Techniker zu seín, aber da und dort komme ich nicht ganz mit...

Ja, die Links unter /var/gsm sind vorhanden und stimmen.
Minicom fällt mir dennoch schwer zu bedienen, wenn ich auch mit einem ATZ immerhin ein OK bekomme...

Ich habe noch mal nach dem letzten Freetz Update und neuer Firmware Laborversion die neueste Firmware auf die Fritzbox gespielt und mal einfach das SMStool3 gestartet.
Und auch eine Test-SMS versucht zu verschicken:

2014-08-19 18:49:39,5, smsd: Moved file /var/spool/sms/outgoing/GSM.2014-08-19_18-49-31 to /var/spool/sms/checked
2014-08-19 18:49:40,7, GSM: put_command expected (OK)|(ERROR), timeout occurred. 2.
2014-08-19 18:49:40,7, GSM: <-
2014-08-19 18:49:42,7, GSM: -> AT
2014-08-19 18:49:42,7, GSM: Command is sent, waiting for the answer
2014-08-19 18:49:47,7, GSM: put_command expected (OK)|(ERROR), timeout occurred. 1.
2014-08-19 18:49:47,7, GSM: <-
2014-08-19 18:49:47,7, GSM: -> ^Z
2014-08-19 18:49:47,7, GSM: Command is sent, waiting for the answer
2014-08-19 18:49:53,7, GSM: put_command expected (OK)|(ERROR), timeout occurred. 2.
2014-08-19 18:49:53,7, GSM: <-
2014-08-19 18:49:54,7, GSM: -> AT
2014-08-19 18:49:54,7, GSM: Command is sent, waiting for the answer
2014-08-19 18:49:59,7, GSM: put_command expected (OK)|(ERROR), timeout occurred. 1.
2014-08-19 18:50:00,7, GSM: <- AT
2014-08-19 18:50:00,7, GSM: -> ^Z
2014-08-19 18:50:00,7, GSM: Command is sent, waiting for the answer
2014-08-19 18:50:05,7, GSM: put_command expected (OK)|(ERROR), timeout occurred. 2.
2014-08-19 18:50:05,7, GSM: <-
2014-08-19 18:50:06,7, GSM: -> AT
2014-08-19 18:50:06,7, GSM: Command is sent, waiting for the answer
2014-08-19 18:50:07,7, GSM: <- OK
2014-08-19 18:50:07,6, GSM: Pre-initializing modem
2014-08-19 18:50:07,7, GSM: -> ATE0+CMEE=1;+CREG=2
2014-08-19 18:50:07,7, GSM: Command is sent, waiting for the answer
2014-08-19 18:50:18,7, GSM: put_command expected (OK)|(ERROR), timeout occurred. 1.
2014-08-19 18:50:18,7, GSM: <-
2014-08-19 18:50:18,3, GSM: Modem did not accept the pre-init string
2014-08-19 18:50:18,6, GSM: Checking if modem needs PIN
2014-08-19 18:50:18,7, GSM: -> AT+CPIN?
2014-08-19 18:50:18,7, GSM: Command is sent, waiting for the answer
2014-08-19 18:50:28,7, GSM: put_command expected (READY)|( PIN)|( PUK)|(ERROR), timeout occurred. 2.
2014-08-19 18:50:28,7, GSM: <-
2014-08-19 18:50:28,2, GSM: PIN handling: expected READY, modem answered
2014-08-19 18:50:28,2, GSM: Modem handler 0 terminated abnormally. PID: 2822.


Das Config File:

devices = GSM
logfile = /var/log/smsd.log
loglevel = 7

[GSM]
device = /dev/ttyUSB0
incoming = yes
pin = 0000

Falls Du noch weitere Tipps hast wäre ich Dir sehr dankbar.
In der Zwischenzeit versuche im mich noch mal mit dem minicom.

Gruß,

gklank
P.S.: wenn es einen anderen USB-Stick gibt, der "höchst wahrscheinlich geht" dann würde ich auch etwas anderes kaufen...
 
Zuletzt bearbeitet:
In der Zwischenzeit versuche im mich noch mal mit dem minicom.
Ich denke mal, das ist der falsche Port. Das einzige, was ich da als Antwort erkennen kann, ist ein schnödes "OK" auf ein pures "AT".

Im Minicom kann es sein, daß Du erst noch das Echo einschalten mußt, damit Du ein eingegebenes Kommando auch sehen kannst:

ATE1<return> (notfalls blind eintippen, anschließend solltest Du jedes getippte Zeichen auch sehen)

ATI1<return>
sollte jetzt wenigstens mit einigen Textzeilen antworten, ansonsten probiere einfach einen anderen Port.

EDIT: Warum konfigurierst Du das Gerät als /dev/ttyUSBx ? Nimm doch lieber /var/gsm/ttyDATA oder /var/gsm/ttyCONTROL (keine Ahnung, welcher der richtige wäre, ich nehme mal an DATA, aber keine Garantie), dann bist Du auf derselben "Schiene" wie das FRITZ!OS.
 
Zuletzt bearbeitet:
hallo,

ich habe -D /var/gsm/ttyDATA verwendet und ate1 blind eingetippt:

Welcome to minicom 2.5

OPTIONS:
Compiled on Aug 7 2014, 01:04:01.
Port /var/gsm/ttyDATA

Press CTRL-A Z for help on special keys

AT+CGMI
huawei

OK
AT
OK
AT
OK

huawei

OK
AT
OK
AT
OK
AT
OK
AT+GMR
11.609.10.00.00

OK
AT+GMRM
11.609.10.00.00

OK
AT
OK
AT+CGMI
huawei

OK
AT
OK
AT
OK
AT
OK
AT
OK
AT
OK
AT
OK

huawei

OK
AT+CGMI
huawei

OK
AT^CPIN?

jetzt ist er am unteren Rand des Terminals angekommen und es geschieht weiter nichts.
 
jetzt ist er am unteren Rand des Terminals angekommen und es geschieht weiter nichts.
Na das ist ja dann mal offensichtlich ein kommunikativer Port.

Das AT^CPIN? sollte imho (das ist von Hersteller zu Hersteller etwas anders) den Status der PIN für die SIM-Karte abfragen. Zur Bedeutung der Kommandos steht einiges auf der SMSTools3-Seite und auch eine Google-Suche fördert bestimmt Ergebnisse zutage.

Ich würde im Stick ohnehin nur eine Karte ohne aktivierte PIN-Abfrage verwenden, ggf. mußt Du die SIM-Karte mal in einem anderen Gerät kontrollieren (daß sie nicht schon gesperrt ist und Du nun die PUK brauchst) und dabei die PIN-Abfrage abschalten.

Ansonsten sieht das auf diesem Port doch schon gut aus ... ich nehme mal an, die Kommandos kommen entweder vom umtsd der Box (sollte der nicht eigentlich aus sein) oder schon vom SMSTool3. Da diese Programme aber nicht auf die visuelle Prüfung ihrer Eingaben angewiesen sind, schalten sie die i.d.R. mit ATE0 ab und sind dann eher verwirrt, wenn da ein Echo ihrer Eingaben zurück kommt. Du mußt Dich also entscheiden: Entweder manueller Test von Kommandos mit minicom oder Zugriff durch Daemons.

Wie gesagt, prüfe die SIM-Karte, deaktiviere falls nötig die PIN, schmeiß den umtsd raus, falls er aus irgendeinem Grund gestartet wird und wirf SMSTools3 an (auf /var/gsm/ttyDATA). Dann kannst Du dort im Log (Debug-Ausgaben ggf. aktivieren, ich weiß aber auch nicht, ob es welche gibt und wo man die einstellt) die Kommunikation des Programms mit dem Modem nachvollziehen und es notfalls (als Anhang !) hier auch posten.
 
Hallo,

- umtsd "gekillt" und das Modem bzw. der Output im minicom ist ruhiger / weniger kommunkativ. Sieht schon deutlich besser aus.
- Ich habe allerdings noch ein "Remove UMTS (USB GSM) gemacht, dann fehlt allerdings einiges (/var/gsm ; smstools3 config file wird nicht gefunden...).
- PIN ist deaktiviert.
- wie meinst Du das "Rauschmeißen" des umtsd genau?

Gruß,

gklank
P.S.: interessanterweise wird jetzt das cdc_acm Modul automatisch geladen, was vorher nicht mehr ging.
 
- umtsd "gekillt" und das Modem bzw. der Output im minicom ist ruhiger / weniger kommunkativ. Sieht schon deutlich besser aus.
Mit 'rauswerfen' meinte ich schon ein 'kill'-Kommando. Wenn Du den Remove-Patch verwendest, fliegt ja die ganze Initialisierung mit heraus, das willst Du nicht wirklich.

Was passiert denn nun, wenn der umtsd nicht läuft (ggf. auch den csvd - der ist für Sprachtelefonie über USB-Stick zuständig - killen, wenn er läuft) und Du versuchst, mit SMSTool3 auf den Stick zuzugreifen ?
Wenn es dann geht, kann man ja immer noch an's Werk gehen, den Start der nicht benötigten AVM-Daemons zu unterdrücken ... ggf. durch CONFIG-Variablen im Environment, das muß man dann sehen, wenn man weiß, was da zuviel gestartet wird.

P.S.: interessanterweise wird jetzt das cdc_acm Modul automatisch geladen, was vorher nicht mehr ging.
Hatten wir das nicht schon auf einen Überlauf der Modultabelle heruntergebrochen ?

Du mußt halt ein Kernel-Modul, das Du ohnehin nicht brauchst, welches aber von der Box geladen wird wenn das File da ist, einfach aus dem Image herauslassen.

Mach doch mal ein 'lsmod' und sieh Dir an, was davon verzichtbar wäre. Ein Kanditat wäre z.B. kspeedtest.ko, wenn das bei Dir geladen ist. Irgendetwas muß da auch faul sein, bei mir sind trotz aktiviertem UMTS-Stick nur 36 Module geladen und die Tabelle faßt 50 Einträge. Wenn das bei Dir wesentlich mehr sind, ist hoffentlich noch "überflüssiges Zeugs" dabei.
 
Hi PeterPawn,

es funktioniert wieder, rießigen Dank!
- UMTSD gekilled
- PIN deaktiviert
- lsmod cdc_acm muss noch von Hand ausgeführt werden, aber damit kann ich sogar leben

Wie bekomme ich den UMTSD beim booten gar nicht gestartet?

Gruß,

gklank
 
Zuletzt bearbeitet:
- lsmod cdc_acm muss noch von Hand ausgeführt werden, aber damit kann ich sogar leben
Ich hoffe mal, du meinst "insmod" oder "modprobe". Schmeiß einfach ein nicht benötigtes Modul raus, dazu mußt Du nur mal kundtun, was bei Dir geladen ist.

Wie bekomme ich den UMTSD beim booten gar nicht gestartet?
In einem freetz-Image ?
Wenn Du keine großen Faxen machen willst und ihn nicht brauchst, lösche ihn doch einfach vor dem Packen. Ansonsten mußt Du den Start in "/etc/hotplug/udev-gsm-tty" unterbinden.
Wenn Dein Stick ein Voice-Interface hat (/var/gsm/ttyVOICE existiert), solltest Du den Start des csvd auch unterbinden, analog zum umtsd.
 
Hallo,

ja, Freetz Image.
Und klar, Du hast Recht. Ich meinte insmod csc_acm.

Ich habe einfach in den Sourcen unter "build/original/filesystem/etc/hotplug" das File udev-gsm-tty editiert und den Eintrag umtsd und csvd auskommentiert.
Das Image habe ich so noch nicht ausprobiert, müsste aber doch so richtig sein (dass eben die beiden daemon nicht gestartet werden)?

Ich habe allerdings noch keine so richtige Ahnung welche kernel Module was bewirken, ich dann rausnehmen kann.
Und auch vor allem, wie nehme ich diese nicht benötigten kernel Module raus.

Trotz Googlen nicht so einfach...

Gruß,

gklank
 
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.