Wir haben uns das “Waveshare SIM7070G Cat-M/NB-IoT/GPRS HAT” für das Raspberry Pi genauer angesehen und in Betrieb genommen. Dabei haben wir verschiedene Fallstricke aufgedeckt und beschreiben im Folgenden, wie wir das NB-IoT Modem eingerichtet haben, um einen unserer #AMPS Nodes mit dem Internet zu verbinden.

• Hardware:
  • Raspberry Pi 4 B
  • Mobilfunk-HAT: Waveshare SIM7070G Cat-M/NB-IoT/GPRS HAT
  • SIM-Karte: Telekom M2M
• Software: Raspbian 12 “Bookworm”

In unserem vorherigen Artikel haben wir die iptables-Firewall für unseren Wireguard VPN-Server vorgestellt. Die Firewall regelt, welcher Traffic zwischen den einzelnen Kunden-VPNs und dem Management-VPN erlaubt ist und verhindert Zugriffe, die ein Sicherheitsrisiko darstellen.

Die Verwaltung dieser Regeln mittels der iptables Command Line Tools ist zwar möglich, allerdings relativ schnell unübersichtlich und insbesondere für Außenstehende schwer zu erfassen. Wir haben deshalb die Firewallkonfiguration über das Tool “Shorewall” erprobt und für geeignet befunden.

Die ZERO AMPS Nodes verfügen zwar nicht per default über eine Internetverbindung, doch in einigen Fällen statten wir sie mit einem Mobilfunkmodul aus, sodass wir sie in Absprache mit dem Kunden aus der Ferne aktualisieren, warten oder Fehler beheben können.

Um eine sichere Verbindung zu unserer eigenen Infrastruktur herzustellen, nutzen wir größtenteils Wireguard VPNs. Wireguard VPN sind sehr leichtgewichtig, performant und sind sich erfahrungsgemäß sehr robust - vor allem in Kombination mit Mobilfunkverbindungen. Der Wireguard Client auf den AMPS Nodes verbindet sich zu unserem zentralen VPN-Server. Über diesen stellen auch unsere Entwickler eine Verbindung her, sodass sie sich letztendlich zu dem jeweiligen AMPS Node verbinden können.

Gestern haben wir bei der Fertigstellung einiger unserer AMPS Einheiten mit Display und Qt-Applikation einen Fehler festgestellt, der dazu geführt hat, dass die Anwendung in seltenen Fällen nicht korrekt gestartet werden kann und crasht. Der Fehler sieht wie folgt aus:

Während meiner Arbeit verbinde ich mich regelmäßig zu verschiedenen Rechnern und eingebetteten Geräten, die über eine Ethernetverbindung erreichbar sind. Diese könnte man nun direkt - wie den Entwicklungsrechner auch - an das Firmennetzwerk anschließen…

… oder man erstellt für seine Geräte ein eigenes “Labornetz”, welches nur vom eigenen Laptop aus erreichbar ist und über das man die volle Kontrolle hat. Vorteile können sein:

• Überblick über die verbundenen Geräte und ihre IP-Adressen
• Keine Exposition der angeschlossenen Geräte ins Firmennetz (Verbesserung der Sicherheit)
• Ist am Entwicklungsrechner nur WLAN verfügbar, können die embedded Geräte trotzdem einfach und kabelbunden erreicht werden.

In größeren Unternehmen kann zudem der Zugang zum internen Firmennetzwerk stark reguliert sein, sodass sich überhaupt nur freigeschaltene Geräte nutzen lassen. Mit einem eigenen kleinen Labornetz auf einem zweiten Netzwerkinterface kann das Problem elegant umgangen werden.

Die Firma Mikroelektronika (MikroE) aus Serbien bietet innerhalb ihres “Click” Ökosystems zahlreiche Funktionsmodule an, die an Mikrocontrollern betrieben werden können. Eines davon ist das “CAN SPI Click 3.3V” CAN Controller Modul, das über die standardisierte “MikroBus” Schnittstelle bzw. SPI verbunden werden kann. Damit die Verbindung zu einem Raspberry Pi 4 funktioniert, haben wir das “Pi 4 Click Shield” dazugenommen.

In diesem Beitrag wollen wir kurz erklären, wie wir das CAN-Modul im Zusammenspiel mit dem Raspberry Pi 4 in Betrieb genommen haben.

Auf einem unserer Raspberry Pis mit Raspbian “Buster” Image hatten wir in Kombination mit einem USB-Mobilfunkstick ein merkwürdiges Problem: Der Wireguard VPN Client konnte sich immer wieder beim Starten des Pis nicht korrekt mit dem Wireguard Server verbinden. Das Fehler-Log besagte, dass der Hostname des Wireguard Servers in der Clientkonfiguration nicht aufgelöst werden konnte.

Eine mögliche Ursache dafür könnte sein, dass zum Startzeitpunkt des Wireguard-Servers der interne DNS-Resolver des Mobilfunksticks (NAT-/Routerbetrieb) noch nicht einsatzbereit war und die Auflösung deswegen scheiterte. Um die Theorie zu bestätigen und den Fehler zu beheben, sollte nun ein Default-Nameserver eingeführt werden, der unabhängig von der Netzwerkverbindung immer derselbe ist und sofort zur Verfügung steht.

Auf unserer Odyssee auf der Suche nach einem 5G Mobilfunkmodem haben wir mittlerweile einige Modems verschiedener Hersteller ausprobiert. Leider war die Inbetriebnahme nicht immer erfolgreich. Mal fehlte der Treibersupport im Linux-Kernel gänzlich - mal war die Ansteuerung via NetworkManager / ModemManager fehlerbehaftet oder überhaupt nicht möglich.

Uns ist eine einfache Inbetriebnahme und ein stabiler Betrieb wichtig. Da wir die Modems nicht nur auf einigen wenigen Geräten einsetzen wollen, kommt für uns eine manuelle Anpassung des Linux-Kernels in der Regel nicht infrage. Zu groß ist der damit verbundene Aufwand und zu unübersichtlich sind die Folgen, die sich daraus für den weiteren Lebenszyklus eines Produkts ergeben. Daher soll das Betriebssystem - oftmals ein Raspberry Pi OS - möglichst im Werkszustand und ohne große Anpassungen genutzt werden.

Mittlerweile haben sich für uns zwei Modems herauskristallisiert, die in Kombination mit dem aktuellen Raspberry Pi OS auf Debian 11 “Bullseye” Basis (Kernel 6.1) “out of the box” funktionieren:

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.