In diesem Beitrag wird erklärt, wie wir die iptables Firewall eines IoT Gerätes konfiguriert haben, sodass eine Wartung über ein Wireguard VPN-Netz möglich ist, während andere Internetzugriffe aus oder in das Mobilfunknetz verhindert werden.
Weil wir es auf die schmerzhafte Weise herausfinden mussten: Das Waveshare IO BASE Module B für das Raspberry Pi CM4 Modul funktioniert nicht mit dem 4" DSI Touch Display von Waveshare - zumindest nicht, solange man eine BASE IO Board Revision < 4 verwendet.
Erst ab Board Version 4 wird die höherperformante DSI1 Schnittstelle statt der DSI0 Schnittstelle des Raspberry CM4 vom IO Base Board genutzt.
Die Information stammt vom Waveshare-Support, den wir wegen unserer Probleme mit den Display kontaktiert haben. Die Änderung des DSI-Ports mit Version 4 des IO Base Boards ist zwar dokumentiert, doch leider befindet sich zum aktuellen Zeitpunkt nirgendwo ein Hinweis auf die fehlende Kompatibilität zum Display - daher sei es hier dokumentiert … ;-)
Da da Raspberry Pi CM4 (“Compute Module”) seit längerer Zeit wegen der anhaltenden Lieferkettenprobleme schwer und nur in geringen Stückzahlen zu beschaffen ist, haben wir von der ZERO GmbH uns nach einer Alternative umgesehen.
Obwohl der Name es nicht direkt vermuten lässt, bietet Radxa mit dem “Rock3 CM3” eine weitestgehend Pin-kompatible Alternative zum Raspberry Pi CM4 an. “Weitestgehend”, da Radxa über einen zusätzlichen, dritten Sockel weitere Pins für Radxa-spezifische Features anbietet. Weitere Interschiede sind auf dieser Seite in der Tabelle zu finden. Dennoch lässt sich das Radxa CM3 Modul hardwareseitig problemlos in ein bestehendes Raspberry Pi CM4 IO-Board einbauen - in unserem Fall ein Waveshare Dual Gigabit Ethernet 5G/4G Base Board.
Wie bereits in früheren Blogposts erwähnt, nutzen wir innerhalb einer Qt Quick Anwendung die Chromium-basierte Qt WebEngine, um Webinhalte darstellen zu lassen. Im Laufe der Entwicklung haben wir allerdings einen unerfreulichen Bug entdeckt, der unsere Anwendung nach einiger Zeit im laufenden Betrieb abstürzen lässt. Zunächst friert das Web-Fenster ein - etwas später folgt dann der Rest der Anwendung, bis die Anwendung schließlich beendet wird.
In diesem Beitrag stellen wir einen Workaround vor, der für uns funktioniert hat.
Während der Entwicklung einer Qt-basierten Anwendung auf einem Raspberry Pi 4 (CM) sind wir von der ZERO GmbH vor ein paar Tagen auf ein kurioses Problem gestoßen: Die Anwendung beinhaltet zwei Anwendungsfenster - ein QT Quick Fenster und ein weiteres Fenster, das mittels WebEngine (Chromium) eine Webanwendung darstellt. Die Inhalte in beiden Fenstern wurden während des Debuggings und beim manuellen Starten der Binärdatei aus der Kommandozeile heraus flüssig dargestellt. Bei Animationen und Mausbewegungen konnten wir keine bemerkenswerten Ruckler feststellen.
Bis vor wenigen Stunden hatten wir mit einem merkwürdigen Bug im Zusammenhang mit der C++ HTTP Library “Pistache” zu tun, der sich zunächst nicht ganz identifizieren ließ. Möglicherweise sind wir nicht die einzigen Betroffenen - deshalb wollen wir in diesem Post kurz das Setup und unseren Fix vorstellen.
Beim Kompilieren von Qt 5.15.2 aus den offiziellen Open Source Quellen sind wir in Kombination mit unserem Buildserver auf ein Problem getoßen: Der Buildprozess wurde beim Kompilieren der Chromium-basierten “WebEngine” Komponente mit zunächst mysteriösen Fehlermeldungen unterbrochen. Ein Blick in das Kernellog mittels dmesg -w offenbarte dann schnell, dass der sog. OOM-Killer des Linux-Kernels zugeschlagen hatte. Offenbar war der RAM-Verbrauch des Buildprozesses so speicherintensiv, dass der Prozess abgebrochen werden musste, um das Betriebssystem lauffähig zu halten.
Um verschiedene 5G Usecases zu demonstrieren, sollte im Rahmen eines Projekts ein 5G-Modem an einem Ubuntu-basierten Mini PC betrieben werden. Hierzu haben wir uns das RM520N-GL von Quectel besorgt.
Das Modem wird vom Linux-Kernel erst ab Version 6.0 vollständig unterstützt. Die dazugehörigen Patches sind hier (USB “option” Treiber) bzw hier (qmi_wwan Treiber) zu finden.
Quectel liefert in der Dokumentation zwar auch Hinweise aus, an welchen Stellen die beteffenden Treiber angepasst werden müssen, doch das erwies sich in unserem Fall als fehleranfällig. Leider werden keine fertigen Git-Patches geliefert, sondern nur Code-Snippets in einem PDF-Dokument.
Wer - wie wir bei der ZERO GmbH - mit neuer Hardware hantiert, die vom Linux-Kernel noch gar nicht oder nur teilweise unterstützt wird, muss in einigen Fällen bestehende Kerneltreiber anpassen. In unserem konkreten Fall ging es dabei um ein 5G Mobilfunkmodem, das vom uns eingesetzten Linux-Kernel noch nicht korrekt als solches erkannt wurde. Die Hardware war mit ihrer USB Vendor- und Product-ID noch nicht in den dazugehörigen Treibern registriert und weitere Detailanpassungen mussten in den betroffenen Subsystemen vorgenommen werden.
Glücklicherweise lagert die Linuxdistribution Ubuntu die meisten Kerneltreiber in flexibel generierbare Kernelmodule (.ko Dateien) aus, sodass nicht der gesamte Kernel nach Änderungen neu kompiliert werden muss. Wie Änderungen beispielhaft am USB-Treiber “option” durchgeführt werden können, wird im Folgenden erklärt.
Vor allem für Demozwecke, z.B. auf Messen, fragen Kunden immer wieder nach Displayansteuerungen, die eine Videodatei auf einem oder mehreren Bildschirmen präsentieren. Während sich zum Teil abenteuerliche Lösungen mit Windows und automatisch startenden PowerPoint-Präsentationen mit eingebettetem Video finden lassen, waren wir von ZERO auf der Suche nach einer eleganteren Lösung, die zudem zügig startet und wenig Raum für Fehlbedienung lässt.