Springe zum Inhalt

Da hier jemand nach einem einfachen Modem-Skript fragte, mit dem über die serielle Konsole AT-Befehle geschickt werden können und die Antworten vom TC35 angezeigt werden, poste ich das einfach mal hier.

Wichtig: seriellen Monitor auf 9600 Baud umstellen und jedes AT-Kommando mit Punkt abschließen! Sind Kommandos oder Antworten des TC35 länger als 64 Bytes, so muss vorher in der Serial-Library der Puffer entsprechend hoch gesetzt werden (_SS_MAX_RX_BUFF). Nach dem Hochsetzen muss das Skript natürlich nochmal kompiliert und auf den Arduino hochgeladen werden.

Verkabelung:

  • GND Arduino mit GND von TC35
  • Pin 8 des Arduino mit IGT des TC35
  • Pin 2 des Arduino mit RXD0 des TC35
  • Pin 3 des Arduino mit TXD0 des TC35

Wenn vorher alles (auch der TC35) ausgeschaltet war, dann blinkt ca. 5 Sekunden nach dem Start die LED neben R1 und R2 auf dem TC35. Das bedeutet, dass sich der TC35 ins GSM-Netz eingebucht hat. Im seriellen Monitor meldet sich das Skript dann wie im Bild dargestellt.

Danach können ganz normal AT-Kommandos an den TC35 geschickt werden. Zu beachten ist nur, dass jedes Kommando im seriellen Monitor mit einem Punkt abgeschlossen werden muss (welcher durch das Skript aber nicht an den TC35 weitergereicht wird). Es dient nur zur Kennung für "hier ist ein Kommando zu Ende". Anschließend werden die Ausgaben des TC35 gelesen und auch im seriellen Monitor angezeigt.

Viel Spaß damit!

5

Nach ein paar Lobgesängen auf LineageOS hier im Blog habe ich heute meine letzte Version mit einem Stock-ROM überschrieben. Leider hat sich LineageOS für meine Handy-Modelle nicht so entwickelt, wie ich es mir gewünscht hätte oder wie ich es von anderen OpenSource-Projekten gewohnt bin.

Nach dem fulminanten Start von LineageOS Anfang 2017 und der durch das Forken von CyanogenMod unmittelbar verfügbaren breiten Unterstützung von Handymodellen schien der weitere Betrieb meiner ohnehin schon auf CyanogenMod laufenden Handys weiter gesichert. Auch der im LineageOS-Wiki dokumentierte Support meines aktuellsten Handy-Modells durch gleich drei Entwickler ließ Gutes erwarten.

Anders als bei CyanogenMod gab und gibt es bei LineageOS noch keine offiziellen Versionen. Historisch gewachsen werden Nightlys, entgegen dem Namen, wöchentlich gebaut. Ich war bei den Nightlys immer an vorderster Front dabei und habe seit der Verfügbarkeit eines Bug- bzw. Regression-Trackers auch fleißig Tickets eingereicht.

Leider werden seit Mitte letzten Jahres von allen drei Entwicklern für mein Handymodell keine Bugs mehr behoben. Elementare Sachen wie z.B. die Anzeige des Energieverbrauchs durch einzelne Apps oder etwa ganz einfache Sachen wie die Anzeige des durch Videos verbrauchten Speichers (es wird immer 0 angezeigt) funktionieren nicht. Videos länger als 2 Minuten aufzunehmen ist sinnlos, da diese anschließend nur ruckeln. Dazu kommen tägliche Random-Reboots, welche sicherlich die ärgerlichsten der bisher nicht behobenen Fehler sein dürften. Verweise auf die volle Konzentration der Entwickler auf eine neue Version (Oreo) kann ich nicht nachvollziehen, da solch eine Version nach einem ganzen Jahr bisher nicht erschienen ist und auch in den entsprechenden Repositories keinerlei Commits dieser Art zu finden sind. Die bisher letzte Version von LineageOS für mein Handymodell strotzt leider nur so von Fehlern.

Das wieder auf das Stock-ROM zurückgesetzte Handy, welches nach wie vor tadellos funktioniert, wird morgen verschenkt. Mein aktuelles Handy hat von vornherein sein Stock-ROM behalten (der geneigte Leser findet sicherlich schnell heraus, welche Marke ich bevorzuge).

Schade für LineageOS, welche so ambitioniert und großartig gestartet ist, leider aber kein generelles Konzept für die Entwicklung durchsetzten konnte.

1

Bei der Arbeit mit virtuellen Maschinen benutzt man häuftig SSH zur Fernwartung. Was aber nun, wenn grundlegende Einstellungen geändert wurden und nach einem Neustart die VM gar nicht erst komplett startet, der SSH-Daemon also auch noch nicht läuft und kein Remote-Zugang möglich ist? Dann wäre ein Zugang zur Konsole der VM hilfreich.

...weiterlesen "VM-Konsolenzugang mit libvirt"

2

Einige Distributionen haben auf das als eierlegende Wollmilchsau beschriebene und von anderen mehr als gehasste systemd umgestellt. Ein Service, der den Startprozess einfacher, paralleler und konfigurierbarer machen soll. In der mitgelieferten Konfiguration von systemd funktioniert auch alles erst mal nach einer frischen Installation, allerdings ist entsprechend der am meisten eingesetzten Konfigurationen vorgegeben, in welcher Reihenfolge was gestartet wird.

Beispiel NFS und Strongswan

Die Entwickler haben sich gedacht, dass wohl in den meisten Konfigurationen erst mal NFS gemounted werden muss und erst dann IPSEC bzw. Strongswan gestartet werden kann, denn es könnte ja sein, dass z.B. /usr ein NFS-Mountpoint ist, aus dem Strongswan erst nach dem Mounten seine Dateien laden könnte. Soweit so gut.

Was aber nun, wenn die NFS-Mountpoints, wie bei mir, erst über bestehende IPSEC-Tunnel erreichbar sind? Dann muss manuell Hand angelegt werden. In die einzelnen mnt-*.mount-Files kann nichts manuell eingetragen werden, da diese beim Systemstart automatisch von systemd-fstab-generator erzeugt werden. Abhängigkeiten können dort also keine eingetragen werden. Abhilfe schafft nur, dass in strongswan.service eingetragen wird, dass die Unit vor remote-fs.target gestartet werden muss. Dazu wird "Before=remote-fs.target" in strongswan.service eingetragen:

Zum Aktualisieren der Konfiguration anschließend noch ein "systemctl daemon-reload" und ab jetzt wird beim Booten Strongswan vor den NFS-Mounts gestartet.