Warum aendert das GSM Modem ZTE mit gammu gesteuert immer wieder seinen Port von ttyUSB2 auf ttyUSB3 und zurueck?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Ich habe mir einen kleinen SMS Relayserver geschrieben der SMS von einem ZTE GSM Modem (1&1 Surfstick) emfaengt und per eMail weiterleitet. Das funktioniert auch soweit gut. Nur wechselt alle 2 Stunden das USB Device von ttyUSB2 auf ttyUSB3 und zurueck. Ich kann die Uhr danach stellen.

    Code
    ls -la /dev/serial/by-id/
    total 0
    drwxr-xr-x 2 root root 100 Mar 11 08:53 .
    drwxr-xr-x 4 root root  80 Mar 11 08:53 ..
    lrwxrwxrwx 1 root root  13 Mar 11 08:53 usb-ZTE_Incorporated_1_1_Surf-stick_MF19001MOD010000-if00-port0 -> ../../ttyUSB0
    lrwxrwxrwx 1 root root  13 Mar 11 08:53 usb-ZTE_Incorporated_1_1_Surf-stick_MF19001MOD010000-if01-port0 -> ../../ttyUSB1
    lrwxrwxrwx 1 root root  13 Mar 11 08:53 usb-ZTE_Incorporated_1_1_Surf-stick_MF19001MOD010000-if02-port0 -> ../../ttyUSB2 bzw ttyUSB3

    Da gammu einen Exit fuer Fehlerfaelle hat flippe ich das usbDebice jedesmal, d.h. ich lese aus /var/log/syslog aus welches usb Device denn nun aktuell genutzt wird, aendere in der /etc/gammu-smsdrc den Port und restarte gammu. Das funktioniert auch soweit gut - nur stoert es mich einfach. Normal ist dieses Verhalten nicht.

    Timeouts die ich in gammu definiert habe sind

    Code
    commtimeout=120
    receivefrequency=60
    resetfrequency=3600

    wobei das alles Sekunden sind. D.h. 2 Stunden - also 7200 Sekunden sind dort nirgendwo definiert :conf: Hat vielleicht jemand eine Idee warum das Modem regelmaessig seinen usb Port wechselt?

  • Warum aendert das GSM Modem ZTE mit gammu gesteuert immer wieder seinen Port von ttyUSB2 auf ttyUSB3 und zurueck?? Schau mal ob du hier fündig wirst!

  • Hi, habe leider keine Erklärung, aber scheinbar das gleiche Problem, zwar nicht auf meinem Pi sondern auf meinem OpenWRT Router, aber ähnliches Setup:

    Verwende gammu um von meinem USB-Surf-Stick ZTE MF823 die SMS abzurufen und per Mail zu schicken.

    Durch deinen Post fiel mir auf dass das Device von ttyUSB2 auf 3 gewechselt ist und gammu deswegen nichts mehr tat, und das erklärt auch wie nach mehreren Stunden manchmal eine SMS doch noch zugestellt wurde...

    Darf ich dich nach deinen Settings/Skript fragen dass du zum switchen des Ports und neustarten von gammu nimmst?

  • framp , bekommst du das nicht evtl. über eine udev Regel in den Griff ?

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Darf ich dich nach deinen Settings/Skript fragen dass du zum switchen des Ports und neustarten von gammu nimmst?

    Kein Problem. Ich habe es im github hinterlegt und ein paar Kommentare spendiert damit es leichter zu verstehen ist.

    framp , bekommst du das nicht evtl. über eine udev Regel in den Griff ?

    Ich bin bzgl udev Regeln ein Noob und baue mir da schneller ein Script zusammen. Allerdings dachte ich bislang auch dass udev Regeln nur greifen wenn ein Device ein- oder ausgesteckt wird. Das findet hier ja nicht statt. Kannst Du mir vielleicht einen Anschub geben wie eine udev Regel aussehen muesste?

  • Puh, ich bin da genau so ein Noob.

    Dachte nur ich könnte dich evtl. in die richtige Richtung schubsen. :gk1:

    Ich denke wir Noobsen ein wenig gemeinsam (nicht mehr wie zwei) und warten auf den welcher sich auskennt. :helpnew:

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Über eine entsprechende udev regel sollte das tatsächlich möglich sein. Eine neue Regel in \etc\udev\rules.d\ anlegen. Am besten einfach 98-usb-serial.rules. Falls die 98 schon belegt ist, sollte eine fortlaufende Nummer (also 99, 100, oder ähnliches) okay sein. In dem File dann so etwas angeben:

    SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", SYMLINK+="ZTE"

    idVencor und idProduct müssen natürlich noch entsprechend angepasst werden. Anschließend einmal sudo udevadm trigger um die neuem udev regeln zu laden. Dann sollte in /dev ein Eintrag "ZTE" vorhanden sein. Dieser kann dann anstatt /dev/ttyUSBX mit /dev/ZTE verwendet werden.

    Zumindest habe ich es immer so gemacht und das funktioniert zB mit XBees einwamdfrei.

    Zum Finden von idVendor und idProduct verwende ich immer:

    udevadm info -a -n /dev/ttyUSB0 | grep -e '{serial}' -e '{idProduct}' -e '{idVendor}'

  • BallerNacken Perfekt :thumbup:. Die Regel verstehe ich sogar :) Vielen Dank. Ich habe das mal konfiguriert und meine Recovery deaktiviert.

    Irgendwie ist mir noch nicht klar wie und wann jetzt entdeckt wird dass von ttyUSB2 auf ttyUSB3 bzw umgekehrt gewechselt wurde und /dev/ZTE dann auf das neue ttyUSBn zeigt. Jetzt beobachte ich das mal :)

  • Ich bin da auch kein Profi. Aber die udev regel wird letztendlich über idvecdor und idproduct definiert. Es ist egal wo das USB Gerät "eingehängt" ist. Wie es in dem Moment des Wechsels ist weiß ich nicht, aber in der Theorie sollte das so funktionieren. Kannst ja mal berichten ob es funktioniert.

  • Vorlaeufig sieht es gut aus. /dev/ZTE wechselt wirklich zum jeweiligen ttyUSBn :bravo2:. Warum und wieso ist sicherlich noch interessant aber erst einmal sekundaer. Ich musste aber erst noch die Configzeile resetfrequency=600 loeschen. Dadurch wurde alle 5 Minuten ein Reset geforced von dem sich gammu ohne Restart nicht erholt hat.

    Jetzt beobachte ich das mal ein paar Stunden und gebe dann einen Update.

  • So wie es aussieht hat die udev Regel zusammen mit dem Loeschen von resetfrequency=3600 das Problem geloest :). Offensichtlich hat gammu mit dem reset ein Problem und verhakt sich irgendwann.

    Jetzt warte ich mal ab ob morgen immer noch alles funktioniert. Ich bin aber zuversichtlich ;)

    n00b42 Definiere bei Dir auch mal die udev Regel. Ich denke das wird auch bei Dir helfen :)

    Update: Eben habe ich noch den Threadtitel angepasst damit er einfacher gefunden wird.

  • Danke, bin mal gespannt ob ich das Problem bei mir auch so beheben konnte; abwarten.

    framp udev Regeln gibt es bei OpenWRT wohl nicht, aber konnte mir was ähnliches mit hotplug zusammenschustern.

    Hatte nur das Problem, dass das Modem 3 ttyUSB Devices anlegt (nur ttyUSB2 bzw 3 relevant) und die sich nicht mittels product/vendor unterscheiden lassen. Und dass ttyUSB2 für hotplug jeweils zweimal hinzugefügt bzw entfernt werden.

  • udev Regeln gibt es bei OpenWRT wohl nicht

    Habe ich eben auch durch Suchen im Netz rausgefunden. Obwohl openwrt auf Linux laeuft ... Ersatz ist wohl hotplug was Du ja auch benutzt. Lass uns wissen ob und wie Du es mit hiotplug hinbekommen hast.

    Zitat von n00b42

    Hatte nur das Problem, dass das Modem 3 ttyUSB Devices anlegt

    Die werden auch bei mir angelegt und werden auch nicht unterschieden mit Product/VendorId. Deshalb war ich ja auch ueberascht dass die udev Regel das mit ttyUSB2 bzw 3 Wechsel hinbekommt.

  • Heute morgen funktioniert immer noch alles :bravo2: Keine staendigen Logmeldungen das das ttyUSBn gewechselt hat. Durch die udev Regel und Benutzung von /dev/ZTE hat gammu offensichtlich keine Haengprobleme mehr und funktioniert reibungslos.

    Vielen Dank an BallerNacken und Der_Imperator fuer ihre Hinweise bzw ihre Hilfe das Problem zu loesen.

  • Als Erinnerungsstuetze dokumentiere ich immer Dinge die ich auf meiner Raspi installiert und konfiguriert habe. Bringt ja nix Euch wenn ich das bei mir @home irgendwo dokumentiere.

    Zu dem Thema

    Benutzung eines ZTE ML190 USB Sticks um einen SMS Relay Server zu betreiben

    finden sich die Details hier :)

  • Kein Problem. Ich habe es im github hinterlegt und ein paar Kommentare spendiert damit es leichter zu verstehen ist.

    Ich bin bzgl udev Regeln ein Noob und baue mir da schneller ein Script zusammen. Allerdings dachte ich bislang auch dass udev Regeln nur greifen wenn ein Device ein- oder ausgesteckt wird. Das findet hier ja nicht statt. Kannst Du mir vielleicht einen Anschub geben wie eine udev Regel aussehen muesste?

    Leider hast du dein Skript schon offline genommen, wollte nochmal nachsehen wie du das geregelt hast, da ich scheinbar doch ein gammu restart einbauen muss.

    Zwar folgt mein symlink dem device ttyUSB2/3, aber scheinbar muss ich dann gammu neustarten, vmtl über "runonfailure".

    Als Erinnerungsstuetze dokumentiere ich immer Dinge die ich auf meiner Raspi installiert und konfiguriert habe. Bringt ja nix Euch wenn ich das bei mir @home irgendwo dokumentiere.

    Zu dem Thema

    Benutzung eines ZTE ML190 USB Sticks um einen SMS Relay Server zu betreiben

    finden sich die Details hier :)

    Das kenne ich, hab auch nen Blog, primär um eine eigene Referenz zu haben^^

  • Ich habe eben noch mal die Logs geprüft. Keine Meldungen mehr in /var/log/syslog das der ttyUSBn gewechselt wurde. Der SMS Relayserver laeuft jetzt rund :bravo2: Ich wuerde jetzt gerne noch verstehen warum die udev Regel das Problem geloest hat :shy:. Offensichtlich switched der Kernel per udev Regel jetzt immer wenn sich der Port aendert. Da immer per /dev/ZTE auf den Port von gammu zugegriffen wird ist die Aenderung fuer gammu nicht sichtbar und alles funktioniert perfekt. Auch wuerde mich interessieren warum der Port sich immer mal wieder aendert.

    Falls jemand Hinweise hat wie ich meine noch zwei offenstehende Fragen beantwortet komme habe ich ein offenes Ohr :)

  • Einen Nachtrag moechte ich geben:

    Vor ca 4 Wochen fing es wieder an: Staendig wechselte der Port und /dev/zte war auch nicht korrekt :fluchen:

    Ich war schon soweit nach einer Alternative von gammu zu suchen. Als ich eine andere Raspi die ich auf meinem Tisch platzierte mit dem GSM Stick versah und ein geclontes OS nutze um was Neues zu suchen und zu testen machte ich noch mal einen Test mit gammu - und musste erstaunt feststellen, dass alles bestens funktionierte :-/ . Die einzige Aenderung an dem gesamten Environment war nur der Ort an dem sich der GSM Stick befindet und seine GSM Signale empfaengt.

    Danach habe ich die Raspi die sonst den GSM Stick hatte an einen anderen Ort versetzt und auch da funktioniert wieder alles bestens. Die einzige Erklaerung die ich habe ist dass der GSM Stick eine schlechte Verbindung an dem alten Raspiplatz hatte und damit gammu nicht zurecht kam. Dass auch die UdevRegel, die /dev/zte statisch haelt auch davon abhaengt ist schon sehr merkwuerdig aber ziemlich deutlich festzustellen.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!