Bevor wir mit den ersten Tests beginnen, starten wir alle veränderten Dienste noch einmal neu (Listing 3) und warten nach dem Restart des NetworkManagers einige Sekunden. Es kann sonst passieren, dass das Interface, an das sich Apache binden möchte, noch nicht wieder verfügbar ist.
Listing 3
Restart
$ sudo systemctl restart NetworkManager $ sudo systemctl restart apache2
Tests
Für unseren ersten Test verwenden wir ein Notebook und verbinden uns mit dem WLAN AP. Nachdem wir uns dort angemeldet haben, geben wir im Browser die Adresse http://10.42.0.1 ein. Hier sollte die Startseite von Apache erscheinen (Abbildung 4).
Abbildung 4: Dank der Umleitung erscheint immer die Startseite von Apache2, egal, welche URL Sie eingeben.
Unabhängig davon, welche URL man jetzt im Webbrowser eingibt, es sollte stets die Startseite von Apache erscheinen. Ist das der Fall, funktioniert das Captive Portal wie geplant und leitet wunschgemäß alle HTTP-Anfragen um.
Fehlersuche
Wo gehobelt wird, fallen Späne. Daher möchte Ihnen der Autor ein paar Tipps mit an die Hand geben, die bei der Fehlersuche helfen. Viele Fehler im Netzwerk lassen sich anfangs nur schwer eingrenzen. Es ist immer eine gute Idee, als Erstes nachzuschauen, ob alle Geräte die erwarteten IP-Adressen verwenden. Der Aufruf ip a zeigt alle Interfaces mit ihrer IP-Konfiguration an.
Um herauszufinden, welche Dienste aktuell auf welches Interface gebunden sind, hilft die Kommando-Pipe netstat -an | grep -i LISTEN | grep -i tcp. Sie überprüft, ob die entsprechenden Dienste auf den Interfaces laufen, die wir dafür vorgesehen haben. Unter Raspberry Pi OS rufen Sie die System-Logfiles mit dem Kommando journalctl auf. Die Tabelle “Nützliche Journalctl-Parameter” zeigt eine Übersicht.
|
Kommando |
Wirkung |
|---|---|
|
|
Anzeige des Systemprotokolls (wie |
|
|
Protokoll für einen bestimmten Dienst |
|
|
Protokoll für den letzten Bootvorgang |
|
|
Hilfeseiten von Journalctl |
Bei der Erstkonfiguration haben wir selbst einen Fehler eingebaut: Durch das generelle Weiterleiten aller DNS-Anfragen an die IP-Adresse 10.42.0.1 fehlt auf dem RasPi eine funktionierende Namensauflösung. Tools wie Apt oder Pip finden daher ihre Quellen nicht mehr.
Um die Namensauflösung temporär wiederherzustellen, kommentieren wir die Regel address=/#/10.42.0.1 in der Konfigurationsdatei redirect.conf aus und starten den Network Manager mit sudo systemctl restart NetworkManager neu. Um den Redirect wieder zu aktivieren, entfernen wir die Auskommentierung wieder.
RGB-LEDs
Um eine schicke Möglichkeit zu haben, Statusinformationen über das Spiel nach außen zu geben, verwenden wir zwölf 8-Millimeter-WS2812-LEDs, die wir in den 3D-gedruckten Deckel montieren. Wir schalten alle Dioden in Reihe, verbinden also den DOUT (Digital Output) jeder LED mit dem DIN (Digital Input) der folgenden. An den MOSI-Pin des Raspberry Pi (GPIO10, Pin 19) schließen wir den DIN der ersten LED an. Die Dioden verwenden ein sehr spezielles Datenübertragungsverfahren. Daher setzen wir hier die Python-Bibliothek WS2812 [5] ein, die uns bei der Arbeit unterstützt.
Als Spannungsversorgung für die LEDs verwenden wir die 3,3 Volt des Raspberry Pi, die wir an GND und VDD aller LEDs anschließen. Das ist zwar nicht der Betriebsmodus, den das Datenblatt empfiehlt, aber es klappt in unserem Fall problemlos. Wir verwenden die LEDs an der SPI-Schnittstelle. Das erlaubt es, die Programme zum Ansteuern ohne Root-Berechtigungen laufen zu lassen. Das Pinout der Dioden zeigt Abbildung 5. Achten Sie beim Einlöten der LEDs darauf, dass das Gehäuse später noch richtig schließt.
Abbildung 5: Das Pinout der WS2812-LEDs. Die digitalen Ein- und Ausgänge der Dioden müssen Sie in dieser Konfiguration jeweils miteinander verbinden.
Virtuelle Python-Umgebung
Mit den Kommandos aus Listing 4 installieren wir die Bibliothek in eine virtuelle Python-Umgebung und aktivieren die SPI-Schnittstelle. Dazu aktivieren wir vorab, wie beschrieben, temporär die Namensauflösung, sonst findet Pip seine Installationsquellen nicht.
