GL.iNet AR750 Slate

Ich war schon eine geraume Zeit auf der Suche nach einem „Plaste-Router“ für einen sehr spezjellen UseCase: einen ReiseRouter.

Da ich mit Familie reise und die Anzahl an WiFi Devices mittlerweile, die der mitreisenden Personen übersteigt, stellt sich am Zielort immer wieder die gleiche Prozedur ein: alle Devices ins Urlaubs-WLan bringen. Wenn es ganz Übel wird, gibt es dort nicht mal solches. Mit einem gesteigerten Privacy/Security Anspruch, will man zudem ungern direkt in einem fremden Netzwerk hängen. Ein VPN muss her. Nun unterstützt nicht jedes Consumer Endgerät VPNs (Switch, EBook Reader usw)…

Lange Rede – Kurzer Sinn: Es werden folgende Features benötigt:

  • Ein eigenes WLAN bereitstellen (2.4GHz besser 5 GHz)
  • OpenVPN Tunnel
  • Uplink über jede mögliche Verbindungsart herstellen (vorhandenes WLAN/LAN, Tethering)

All das kann man mit diversen OpenWRT/LEDE geflashten Routern irgendwie hinbekommen. Aber meistens war da gefrickel Notwendig. Besonders, wenn man sich in ein WLAN einwählen wollte und gleichzeitig selber ein anderes WLAN als AP zur Verfügung stellen wollte. (Auf dem gleichen Band wohlgemerkt)

Mein kurzer Abstecher in die „alte ConsumerWelt“ via einer Netgear AirCard war echt abschreckend. Für mehr als ein LTE Modem taugt der Kram nicht (dafür aber, dank externer großer Antenne, gut). OS Updates – wozu? „Shippen and Forget“ ist hier die Devise.

Vor meinem letzten Urlaub habe ich mir „zum Testen“ den AR750 Slate von GL.iNet zugelegt. Das Gerät gibt es im Handel aktuell für um die 100€. Das ist erstmal eine Ansage. Damit spielt das Gerät preislich in der „Oberliga“ der Plasterouter Marke „Eierlegende Wollmichsau“.

Die erste Überraschung gibt es beim Auspacken des Gerätes. Das Ding ist kleiner als ein RasperryPy und dennoch bietet es zwei schwenkbare Antennen, 3 RJ45 Ports (Gigabit Ethernet) und einen USB2 Port. Ein RJ45 Port dient fest als WAN Port, über die anderen Beiden kann man kabel-gebundene Geräte anschließen. Der USB Port kann wahlweise für eine Modem oder Tethering-Verbindung genutzt werden oder es kann ein USB Massenspeicher angeschlossen werden. Der interne Speicher (128MB) kann via MicroSD Karte erweitert werden. Die Stromversorgung läuft über ein USB Mini und kann von einem beliebigen USB Netzteil oder PC erfolgen.

Die zweite Überraschung erfolgt bei der Inbetriebnahme des Gerätes. Man wird von der vorgeschaltet UI gezwungen (!!!!!) eine „sicheres“ Passwort zu vergeben. Das ist man bei PlasteRoutern nicht unbedingt gewohnt. Man landet sofort in einer Übersicht wo man aus 4 Optionen wählen kann, wie man die Verbindung zum Internet herstellen möchte. Einen Klick (wirklich nur einen Klick) später hat man Internet (Wenn die Konfiguration am Zielort mitspielt, dazu gleich mehr).

Beim VPN hat man die Wahl zwischen OpenVPN und WireGuard. Unsichere und „sollte man nicht verwenden“ Protokolle und werden gar nicht erst angeboten. Beim VPN Setup hat man immer die Wahl zwischen Client und Server Mode. Die notwendige Config lädt man einfach hoch. Die meisten VPN Provider bieten die passenden personalisierten Configs an, bei privaten VPNs muss man sich Selbige schnell zusammenbasteln. Liegt die Config vor braucht es 5 Klicks bis das VPN steht. Zwei weitere Klicks und der Router blockiert jedweden Traffic, wenn kein VPN verbunden ist. Kurz: wenn alles gut läuft ist man in unter zwei Minuten mit dem Setup durch und muss sich den Rest des Urlaubs nicht mehr um den kleinen Kasten kümmern.

Ich hatte natürlich gleich beim ersten Einsatz den „SuperGau“. Mein HotelWLan nutzte die gleiche IP Range wie mein Heimnetz. Solche Fälle kann weder über die GL.iNet noch die LuCI-GUI abfangen. Hier war direkter SSH Zugang und „Policy Based Routing“ Gefrickel notwendig. 20 Minuten und einige Flüche später war aber auch das Problem umschifft. Das Gerät hat über die Dauer des Urlaubs keine Auffälligkeit gezeigt und einfach lautlos (und störungsfrei) seinen Dienst verrichtet.

Wenn man Meckern will, dann nur auf sehr hohen Niveau. Hier sind ein paar Punkte:

  • Für die WLans werden keine getrennten physikalischen Kanäle verwendet. Wählt man sich in ein WLAN ein, wird das eigene WLAN auch auf dessen Kanal bereitgestellt. Das ist dem Durchsatz nicht zuträglich.
  • Wird ein WLAN sowohl auf 2.4 GHz als auch auf 5 GHz angeboten, kann man von der GUI aus nicht das 5 GHz Band erzwingen. Dazu muss man in die LuCI oder gar via SSH nachhelfen.
  • Der Router wird als MediaCenter beworben. Ich vormuliere es mal diplomatisch. Das ist nicht die Stärke des Gerätes. Via Micro SD Card kann man wohl nur 128 MB nachrüsten (nicht ausprobiert), da geht nicht viel „Media“ und über den USB2 Port geht nicht viel Durchsatz. RAW Bilder von der Kamera will man darüber nicht Sharen (und das habe ich ausprobiert!).
  • IPSec VPN muss man manuell installieren und konfigurieren. Eine direkte Verbindung zu einer FritzBox benötigt Handarbeit.
  • Die Firmware ist ein spezjell gepatchtes OpenWRT und basiert auf der letzten „stable“ Version, ist also schon etwas älter und „gut abgehangen“. Will man ein „untouched“ oder gar „latest“ OpenWRT muss man sich die Kiste Patchen. Das geht ohne Probleme. Die 128MB Flash Speicher sollten für OpenWRT Builds eine weile reichen und genügen Platz für Experimente bieten.

Fazit

So viel „Euphorie“ hatte ich bei Netzwerkgeräten schon lange nicht mehr. Eigentlich löst das nur Ubiquity bei mir aus. Anschließen, einrichten und „geht“. Man sucht noch Gründe rum zu basteln aber eigentlich tut alles. Der Router ist perfekt auf seinen Einsatzzweck ausgerichtet. Urlaubs-Resort betreten, WLAN Zugang einrichten, VPN verbinden und dann das Gerät vergessen und Urlaub machen. Wenn es mal doch einen Grund gibt zu basteln, hat man aber auch die komplette Bandbreite der Tools zur Verfügung.

Wenn zwei unterschiedliche Netzwerke die gleiche IP Range haben…

Vorweg: mit IPv6 wäre das nicht notwendig. IPv6 ist aber immer noch nicht flächendeckend ausgerollt (und wird es wohl zu meiner Lebenzeit auch nicht)

Wenn man sich via VPN aus einem beliebigen Netz in sein eigenes Netzwerk verbindet funktioniert das nur, wenn das Lokale Netz (aus dem man sich verbinden will) eine andere Netzmaske hat, als das Zielnetz, in das man sich verbinden will.

In meinem Fall Hotel-WLan-Gateway die gleiche Adresse wie eine meiner Server (auf dessen Service ich gerade zugreifen wollte).

Ich halte ja mittlerweile zwei unterschiedliche VPN Netzwerk Konfigurationen bereit, für den Fall, dass mein Gastnetzwerk den gleichen Addressraum nutzt, denn auch mein VPN hat. Für die Zieladressen konnte ich diesen Weg aber nicht gehen.

Das Problem kann man mit einem Router und „Policy Based Routing“ lösen.

Der Router wird mit dem zur Verfügung gestellten Gast Netz verbunden (IP Range A) und stellt selber ein Netzwerk (IP Range B) zur Verfügung. Der Router wählt sich nun in das VPN-Netzwerk ein (IP Range C). Das interne Netzwerk, dass durch das VPN erreicht werden soll, hat auch IP Range A.

Das Problem: wenn ein Client aus IP Range B versucht auf interne Ressourcen mit der IP Range A zuzugreifen, geht der Router nicht über das VPN, sondern auf den direkten Link, also ins GastNetz.

Die Lösung: man legt sich eine neue Routing Table an, die zwei Einträge hat:

Den Lokalen Link für das eigene Netzwerk (IP Range B)
eine Default Route über das VPN (IP Range C)

Das kann dann so aussehen

ip route add IP-RANGE-B dev LOCAL-DEV proto kernel scope link src LOCAL-IP table 200 
ip route add default via VPN-GW-IP dev VPN-DEV table 200

Anschließend muss man dem Router nur noch dazu Bringen, alles aus dem eigenen Netzwerk (IP Range B) über diese Tabelle zu routen. Das geht wie folgt:

ip rule add from IP-RANGE-B lookup 200

Wenn nun etwas aus dem eigenen Netzwerk (IP Range B) bearbeitet wird, kennt der Router das GastNetz (IP Range A) nicht.

Das ganze kann man auch ohne Router erreichen, also mit einem Client direkt im GastNetz (IP Range A) und einer OpenVPN Instanz am laufen. Dann werden die „ip rule“ Statements nur viel komplizierter.

Die Ansatz hier ist: Sämtlichen Traffic, der nicht von dem VPN erzeugt wird, über eine gesonderte RoutingTable zu bearbeiten und nur den VPN Traffic an das Default GW zu bekommen. Der Kniff ist „Sämtlichen Traffic, der nicht von dem VPN erzeugt wird“ korrekt zu erkennen. Möglichkeiten hier sind:

  • Alles was nicht an den Default GW gesendet wird
  • Alles was nicht von einem bestimmten User erzeugt wurde

Alles in allem hat man einfach ein bisschen mehr Aufwand.

Oder man sorgt mittels IPv6 einfach dafür, dass man keine zwei Netze mit gleicher IP Range hat…

Devolo Thermostat mit HomeAssistant steuern

ich weiß ich bin ein bisschen „Late to the Party“ – aber egal.

Wer unter Ubuntu ZWave-Geräte via HomeAssistant steuern möchte, muss erst mal selber hand anlegen.

Folgende pakete müssen via apt-get nachinstalliert werden:

  • libudev-dev
  • libopenzwave1.5

Anschließend muss man noch via pip das Paket python-openzwave installieren. Den Rest sollte HomeAssistant selber nachinstallieren, sobald man zwave in der Config aktiviert hat.

zwave:
  usb_path: /dev/ttyACM0
  network_key: "SecretKey" 

Die Installation der meisten Z Wave sticks läuft problemlos. Anstecken und ein device wird angelegt, meist irgendwas mit ttyACM. Gegenbefalls muss man noch an den Berechtigungen schrauben aber das ist trivial. Im HomeAssistant COnfigMenu sollte unter ZWave jetzt der Controller gelistet sein.

Zuerst muss man das Thermostat montieren. Danach versetzt man via HomeAssistant den Z Wave Adapter in den Suchmodus. Auf dem Thermostat die mittlere Bedientaste zur Bestätigung drücken (ca 1sek) und nach kurzer Zeit sollte im HomeAssistant eine neue ZWave Node auftauchen.

„Aus Gründen“ wird das Thermostat als Cooling Unit erkannt. Die Temperatur wird zwar korrekt ausgelesen, aber man kann keine Ziel Temperatur setzten. Um das zu beheben muss muss man warten bis die Node im ZWave Dialog als „Complete“ gelistet wird. Anschließend den HomeAssistant geregelt runter fahren, damit die ZWave Config raus geschrieben wird. Nun diese Config bearbeiten und den Eintrag „Heating 1“ hinzufügen.

<CommandClass id="67" name="COMMAND_CLASS_THERMOSTAT_SETPOINT" version="1" request_flags="4" innif="true" base="1" typeInterpretation="B">
  <Instance index="1" />
  <Value type="decimal" genre="user" instance="1" index="1" label="Heating 1" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="21.00" />
  <Value type="decimal" genre="user" instance="1" index="2" label="Cooling 1" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0.0" />
</CommandClass>

Jetzt noch unter Climate ZWave aktivieren:

climate:
  - platform: zwave

Nach dem start des HomeAssistant sollen 4 neue „devices“ verfügbar sein:

  • climate.danfoss_unknown_type_0005_id_0175_cooling_1… – kann man ignordieren
  • climate.danfoss_unknown_type_0005_id_0175_heating_1… – Steuerung des Thermostat
  • sensor.danfoss_unknown_type_0005_id_0175_temperature… – Das Thermometer des Thermostat
  • zwave.danfoss_unknown_type_0005_id_0175… – Das zwave device selber, braucht man für die Batterieanzeige

Um einen Sensor für die Batterie zu haben muss man folgendes machen:

sensor:
  - platform: template
    sensors:
      zwave_devolo_batt:
        value_template: '{% if states.zwave.danfoss_unknown_type_0005_id_0175 %} {{ states.zwave.danfoss_unknown_type_0005_id_0175.attributes.battery_level }} {% else %} Unknown {% endif %}'
        unit_of_measurement: '%'

Hat man mehrere Thermostate wird allen litereals ein Nummerierung via Unterstrich angehängt. (zwave.danfoss_unknown_type_0005_id_0175_2, climate.danfoss_unknown_type_0005_id_0175_heating_1_2 …)

Jetzt kann man das Thermostat im HomeAssistant nutzen und steuern.

Was funktioniert nicht:
COMMAND_CLASS_CLOCK – Der HomeAssistant scheint die Uhrzeit noch nicht auf das Device zu schreiben. Die wird gebraucht, dass das Thermostat einmal eine „Justierungsmessung“ Des Ventiels macht
COMMAND_CLASS_CLIMATE_CONTROL_SCHEDULE – Laut Beschreibung sollte man dem Thermostat hier eigenen „Schedule“ verpassen können. Das kann man über den HomeAssistant lösen, was heir auch gehen sollte, ist den Temperatursensor mit einem Offset zu versehen.

Kleine Anmerkung für die Leute die die Bedienungsanleitung suchen. Devolo hält es nicht für Notwendig die vollen Funktionen des Thermostates zu beschreiben. Da es sich aber um ein Gebrandetes Danfoss handelt, kann man sich da die nötigen Daten ziehen. Als Spezjalservice, das wichtigste hier:

  • Full Reset: Batterien raus, und beim einlegen die Mittlere Taste gedrückt halten biss Symbole im Display aufleuchten.
  • Wenn man die Mittlere Taste gedrückt hält, erscheint ein „stilisiertes“ M, drückt man nochmal die Taste wird das Ventiel gelöst und man kann das Thermostat demontieren.
  • Wenn man bei dem M mit den Pfeiltasten steuert, kann in weitere Modi wechseln Li und Pb
  • Li = Linktest = Blingt nach der Wahl die Glocke und die Antenne, dann stimmt was mit dem ZWave Link nicht
  • Pb = „Raumdimensionierung“ = P1 Radiator zu gross, P2 Radiator passt, P3 Radiator zu klein

Razer Huntsman unter Linux

Unter Linux gibt es den openrazer Treiber um Razer Geräte anzusteuern. Leider hat Razer bei neueren Geräten das „Protokoll“ gewechselt und betreibt jetzt wohl mehr „Software Based Lightning“. Lange Rede – kurzer Sinn: der openrazor Treiber aus den aktuellen quellen funktioniert noch nicht.

Wenn man nicht alles selber bauen will sollte man sich erst mal das Frontend installieren. Unter KDE bietet sich Polychromatic an. Dazu muss man auch den Treiber „schon mal“ installieren.

Anschließen hohlt man sich die Openrazer-Quellen von hier: https://github.com/sumpster/razer-drivers.git

Danach der üblich Weg:

make
sudo make driver_install
sudo make setup_dkms
sudo make udev_install
sudo make daemon_install

danach noch den openrazor_daemon aus /usr/lib/python3.x nach /usr/lib/python3/dist-packages kopieren, durchstarten und schon kann man die Huntsman unter Linux steuern.

Wichtig: nutzt !!nicht!! die abkürzung über ubuntu_install. Die ist fürs pakaging gedacht und zerschießt euch das System.

Bird unter Debian

Im Rahmen eines Router-Upgrades durfte habe ich den BIRD unter debian-stretch installiert. Dabei kam es während der Installation zu einem Fehler. In der Datei „/usr/lib/bird/prepare-environment“ wird das chown mit einem „–silent“ parameter abgesetzt, den es unter debian-stretch nicht (mehr?) gibt.

wenn man das ganze wie folgt umbaut, klappt es auch mit der installation und anschließendem start.

#!/bin/sh
set -eu

BIRD_RUN_DIR=/run/bird
. /etc/bird/envvars


mkdir --parents "$BIRD_RUN_DIR";

if [ -n "$BIRD_RUN_USER" ]; then
    if ! getent passwd $BIRD_RUN_USER >/dev/null; then
        echo "Configured user '$BIRD_RUN_USER' doesn't exist."
        exit 1
    fi
fi

if [ -n "$BIRD_RUN_GROUP" ]; then
    if ! getent group $BIRD_RUN_GROUP >/dev/null; then
        echo "Configured group '$BIRD_RUN_GROUP' doesn't exist."
        exit 1
    fi
fi

chown "$BIRD_RUN_USER:$BIRD_RUN_GROUP" "$BIRD_RUN_DIR"
chmod 775 "$BIRD_RUN_DIR"

:

uacctd unter systemd

Wer „aus Gründen“ einen uacctd auf einem System einsetzt, bei dem zwar der systemd zum einsatz kommt, aber das uacct-packet kein Service-File mitliefert, hier ein excampel:

[Unit]
Description=uacctd daemon providing Netflow collection service
Wants=network.target
After=network.target
ConditionPathExists=/config/uacct/uacctd.conf

[Service]
Type=forking
ExecStart=/usr/sbin/uacctd -f /config/uacct/uacctd.conf

[Install]
WantedBy=multi-user.target