Da bin ich raus ... ich kann noch verstehen, wenn der umtsd und der csvd parallel arbeiten können, weil jeder von ihnen auf seinen eigenen Port zugreifen kann (und vermutlich der umtsd auch intern mit dem csvd kommunizieren kann). Ich kann es gerade nicht nachstellen, weil der Huawei E3131 vom FRITZ!OS 06.51 im HiLink-Modus betrieben wird (12d1:14db, ich will da im Moment auch nichts am Stick ändern) und ich den MF190V im Moment nicht finde ... daher nur aus dem Gedächtnis und ohne Test auf aktueller Firmware:
Für den Versand/Empfang von SMS (über AT-Kommandos, wie das SMSTools3 ja macht - im HiLink-Modus kann das auch über das GUI des Sticks funktionieren, das kann/konnte SMSTools3 aber nicht) braucht man nun einmal einen voll funktionsfähigen Zugriff auf einen Port, wo man AT-Kommandos senden und die Antworten ungestört(!) empfangen kann. Die seriellen Ports eines USB-Sticks werden aber (über /var/gsm/ttyXXX) vom umtsd und csvd dauerhaft geöffnet gehalten (sonst kriegen diese Daemons ja auch die asynchron vom Modem gesendeten Informationen nicht mit ... ansonsten könnte man natürlich nur dann den Port öffnen, wenn man eine Sequenz von AT-Kommandos senden und die Antworten darauf auswerten will), wie man mit dem Blick in die Ausgabe von "lsof" eigentlich feststellen müßte.
Wenn es trotzdem gelingt, die Ports parallel zu benutzen bzw. (bei einigen Sticks geht das, weil die Kommandos auf mehreren Ports entgegen nehmen, dann aber auch auf mehreren die Reaktionen sichtbar sind) man einen freien Steuerport findet, dann kommt noch hinzu, daß die Daemons nicht allzu begeistert sind von Kommandos, die sie als asynchrone Daten interpretieren, weil dank ATE1 "fremde Kommandos" und deren Ergebnis (das wieder unabhängig vom ATEx-Zustand) auf ihrem Port sichtbar werden und dann schon mal den Stick prophylaktisch zurücksetzen (ATZ). Vielleicht hat sich das inzwischen geändert, aber ich glaube nicht so richtig daran ...
Das war auch der Grund, warum ich von "Multiplexen" geschrieben hatte ... solange der umtsd als der "Herrscher" über den Control-Port nicht die dort empfangenen Daten an den SMSTools3-Daemon (smsd) weiterleitet, klappt schon mal der Empfang gar nicht ... höchstens im Polling und durch Vergleich mit dem vorhergehenden Stand könnten neue SMS identifiziert werden. Auch beim Versand wird es mehr oder weniger zur Glückssache, ob und wann das funktioniert ... solange der umtsd den Stick nicht zurücksetzt oder man schneller mit dem Versand fertig ist als mit dem Zurücksetzen, kommt vielleicht auch mal eine SMS durch. Wenn ich das oben so lese, würde ich am ehesten darauf tippen.
Eine sinnvolle Lösung ist das aber nicht und so müßte man entweder die anderen Daemons (umtsd und csvd) beenden, um SMS zu versenden und sie hinterher neu starten, das mag aber der telefon-Daemon in Bezug auf den csvd nicht immer - dann klappt manchmal hinterher die Telefonie über den Stick nicht mehr.
Der andere Ansatz, den ich mal in Angriff genommen hatte, war das "Dazwischenschalten" eines eigenen Programms, das die asynchronen Daten vom Modem nach SMS und "nicht SMS" trennt und sie entsprechend an den richtigen FIFO weiterleitet, den man anstelle der seriellen Schnittstelle hinter den Link in /var/gsm/ttyXXX legt. Damit kriegt der umtsd die Daten mit Bezug zum SMS-Versand gar nicht erst mit und der SMSTools3-Daemon erhält diese (über seinen eigenen FIFO). Dann muß man "nur" noch die Kommandos seitens des SMSTools3-Daemons so weit filtern, daß nur noch die mit SMS-Bezug auch an den Stick weitergeleitet werden, weil ansonsten dieser Daemon ebenfalls beim Start den Stick neu initialisieren will, denn auch der "denkt" ja, er hätte die Macht über diesen Port alleine. Allerdings erwartet natürlich auch der smsd eine Reaktion des Sticks auf seine initialen Kommandos ... das muß man also auch noch "emulieren". Das war dann auch irgendwo der Punkt, wo ich abgebrochen hatte ... ich finde aber die Quellen gerade nicht und ich hatte es auch nie bis zum Ende gebracht, weil ich dann auf XMPP-Benachrichtigungen umgestiegen bin (bzw. sogar auf "prowl", wo ein einfaches "wget" ausreichend ist) - die gehen auch ohne Stick, leider nicht ohne Internetverbindung, aber die arbeitet i.d.R. auch wieder über einen Stick, wenn die Benachrichtigung genau den Ausfall der DSL-Verbindung mitteilen sollte.
Fazit: Ich wäre recht verblüfft, wenn sich die Internet-/Telefonie-Funktionen der FRITZ!Box (da muß es ja dann die Modem-Emulation sein und nicht der CDC-Modus eines USB-Sticks) und SMSTools3 gemeinsam und nachhaltig (reliable) auf einer FRITZ!Box betreiben lassen ... es mag - je nach USB-Stick und dessen Umgang mit seinen Schnittstellen - aber auch funktionieren. Daß es einfach so klappt (ich installiere und konfiguriere dann mal SMSTools3 und dann ist alles in Butter), glaube ich aber erst recht nicht ... dazu muß man schon seinen USB-Stick sehr genau kennen (und ihn dazu vermutlich erst einmal untersuchen), wann der wo welche asynchronen Daten ausgibt und wie/wo er auf AT-Kommandos reagiert. Hat der am Ende wirklich einen "freien Port", auf den man smsd loslassen könnte und dort sind auch die asynchronen Daten sichtbar, wenn SMS empfangen werden (die ignoriert der umtsd nach meiner Erinnerung, weil er sie nicht kennt und er trotzdem nicht bei jedem unbekannten "Datensatz" auf der Schnittstelle gleich abdrehen kann - aber die sind dann eben auch als asynchron erkennbar) ... dann könnte ich mir sogar die Koexistenz vorstellen. Ansonsten muß man sich eben zwischen GSM-Telefonie/Internet und SMS entscheiden oder zwei getrennte Sticks (mit zwei SIM-Karten, usw.) verwenden.
Will man anstelle der FRITZ!OS-Komponenten lieber smsd verwenden, muß man aber auch noch andere Vorkehrungen treffen, damit die AVM-Daemons nicht durch den "hotplug"-Mechanismus des udevd dann doch irgendwann gestartet werden oder man muß sie jeweils wieder beenden bzw. in "wrapper scripts" verpacken, so daß man eine fallweise Entscheidung treffen lassen kann, ob die nun starten sollen oder nicht.
Ich kann mir beim besten Willen nicht vorstellen, daß jemand sich diese ganze Arbeit antut ... ich habe das mal zwei verschiedenen Leuten per PM versucht zu erklären, die haben dann spätestens nach der dritten Nachricht abgewunken, weil das alles "viel zu kompliziert wird". Aber ich lasse mich gerne vom Gegenteil überzeugen - vielleicht findet ja auch jemand eine einfachere Lösung, die trotzdem zuverlässig funktioniert - und ich bin nach wie vor auch noch daran interessiert, so eine Lösung "nachzunutzen" ... aber ich investiere da auch keine Zeit mehr in ein solches Vorhaben (SMS sind auf dem absteigenden Ast). Sollten mir die Quellen für den Multiplexer irgendwo noch über den Weg laufen (es gab damals nichts Fertiges, vielleicht ist das heute sogar anders, wobei ja auch die seriellen Schnittstellen (auch als USB-Emulation) eher seltener werden), stelle ich die in GitHub ein ... mehr aber auch nicht.
