home
erste Version am 03.05.2022
letzte Änderung am 15.05.2022

Google Wifi

Gestern hat Amazon ein Dreierpack GoogleWifi-Adapter zugestellt. Gesamtpreis für den Dreierpack: 172€.
Final brauche ich mindestens noch zwei von den Dingern, werde aber einfach beizeiten ein weiteres Dreierpack ordern...weil: 1x=94€, 2x=155€, 3x=172€. Da müsste ich ja schon komplett blöd sein, ein Zweierpack zu bestellen !?
Ziel ist, meine gesamte AVM-PowerLAN-Infrastruktur abzulösen... weil: die kotzt mich mittlerweile maximal an.
Nur Ärger!
Bisher war ich ja quasi AVM-Fanboy. Aber das, was es jetzt von AVM bzgl. PowerLAN noch zu kaufen gibt, ist alles Dreck!
Und die Dinger sind ja durchaus richtig teuer.
Überleben aber immer nur kurz die zwei Jahre Gewährleistung. Böse ist, wer Böses denkt. Mal wieder....
Ich hab hier mindestens vier verreckte AVM-PowerLAN-Adapter rumliegen.
Und hier noch meine eMail-Kommunikaton mit dem AVM-Support.


Inhaltsverzeichnis

erstmal drei Adapter in Betrieb nehmen
Überlegungen
Klappt wie gedacht
dann doch noch ein Update
sechs aktive Adapter


erstmal drei Adapter in Betrieb nehmen

Der erste GoogleWifi-Adapter steht im Büro (Keller) und hängt direkt am Switch.
Der zweite Adapter landete im Schlafzimmer. Zwei Etagen höher. Und da kam (durch zwei Stahlbeton-Decken) nicht mehr so richtig viel an.
Also wurde der dritte Adapter dazwischen installiert, im Wohnzimmer (Erdgeschoß)... und siehe da... jetzt meldet der "Mesh-Test" für die beiden Satelliten: Wohnzimmer="sehr gute Verbindung" und Schlafzimmer="gute Verbindung".
BTW.: zur Konfiguration der GoogleWifi-Adapter brauchts eine App. Ohne die gehts wohl eher nicht. Und Geduld braucht man auch. Speziell wenn Firmware-Updates deployed werden sollen. Schnell ist was anderes. Aber egal. Das Setup brauchts hoffentlich nicht so oft.

Im Schlafzimmer hängt nur der Fernseher (via Kabel) dran. Die Mediatheken der Öffentlich-rechtlichen kommen problemlos - aber mein DLNA-Server wird nicht mehr gesehen.
Auch kann ich im Wohnzimmer den WLAN-Router nicht einfach von PowerLAN auf GoogleWifi umstecken. Naja, kann ich schon - aber dann sind alle WLAN-Gäste meines offenen WLANs mit der IP-Adresse meiner Fritzbox unterwegs. Die sollen aber im hide.me-Tunnel landen. Auf der GatewayVM. Sonst wäre mir das zu kibbelig.

Tja, hätte ich mir auch vor der Bestellung denken können. Das Ding hat die Bezeichnung "Mesh-Router" ja schon im Produktnamen mit drin.
Also hat der wohl seinen eigenen DHCP-Server samt eigener IP-Range und auch sein eigenes NATing.
Hmmm.... blöd jetzt....
ABER ... :-) ... wozu habe ich einen Managed Switch, der mit VLANs umgehen kann!?

Denn... wenn ich am GoogleWifi-Adapter im Keller an die CAT5-Ausgangsbuchse einen Laptop anschließe, bekommt der eine IP-Adresse in der Range 192.168.86.x.
Statt des Laptops könnte ich die Buchse auf meinen Switch legen und den entsprechenden Switch-Port als "Port-based-VLAN" einstellen.
Damit bekäme jedes ankommende Paket ein VLAN-Tag und bei ausgehenden Paketen mit diesem VLAN-Tag würde es dort wieder entfernt werden.
Also bräuchte ich in meinem DLNA-Server nur ein weiteres VLAN, an das ebenfalls ausgeliefert wird (parallel zu VLAN1 und VLAN42). Eine dritte IP-Adresse im 192.168.86.x-Netz.
Aber bei der GatewayVM oder eher der SocketServerVM könnte es unschön werden.

Die beiden SIP-Telefone, für die ich von V2 auf V3 umgestellt hatte, sind eh längst abgebaut. War nur sinnloser Stromverbrauch. Wir haben mittlerweile genug Fritz!Fon's.

Also könnte ich auch das gesamte GoogleWifi-Mesh ins VLAN42 legen. Port-Basiert.
Damit wäre das Mesh im VLAN42 und damit im hide.me-Tunnel.
Fraglich ist nur, ob sich der DLNA-Server im GoogleWifi-SubNetz dann auch sauber announced.
Noch habe ich keine Lösung - aber wenn es ganz einfach wäre, wäre es ja auch langweilig...und keine eigene Projektseite wert :-)


Überlegungen

Sooo. Scheiß krankheitsbedingte Ausfälle. Eine komplette Woche ist direkt im Lokus verschwunden. Wie ertragen es Leute eigentlich, wochenlang im Bett zu liegen? Ich konnte schon nach etwas über zwei Tagen keine angenehme Liege-Position mehr finden. Eine dauerhafte Qual.... Erst als die Frau endlich ins Wohnzimmer aufs Sofa geflüchtet war und ich das komplette 2x2m-Bett für mich alleine hatte, waren genug Matratzen-Positionen mit unterschiedlichen Härtegraden verfügbar....
Aber nun gehts wieder und ich hab mir gerade mal meine SocketServerVM und die Logger-Firmware angesehen.
Der Logger erwartet seinen Gegenpart im VLAN42 unter der IP-Adresse 192.168.42.80. Vorab verbindet er sich dafür zu "FreifunkWees01.2 (http://ffw)".
Analog siehts bei der jüngsten Version (vom 03.12.2016) der Rollladen-Ansteuerungs-Firmware aus.
Erst bei der Zirkulationspumpen-Steuerung sind derartige Parameter variabel. Zwar schön, aber nutzt nix - wegen der anderen beiden Devices.
Will heißen: ich kann weder den WLAN-Namen (SSID) ändern, noch die IP-Adresse des Socket-Servers .... wenn ich nicht zwei ATmega's umflashen will.

Die WLAN-Router hängen derzeit via PowerLAN am Switch Port4 im VLAN1. Port4 ist auch tagged im VLAN42 definiert.
Der KVM-Host hängt am Port2. Dieser ist ebenfalls untagged im VLAN1 und tagged im VLAN42.
Die Gateway-VM erscheint mit VLAN1 und VLAN42 auf dem Switch, die DLNA-VM nur mit VLAN1. Beide logischerweise am Port2.

Der GoogleWifi-Adapter hängt an Port24. Derzeit im VLAN1, er ist aber auch als tagged im VLAN42 definiert.
Würde ich Port24 jetzt auf VLAN42 only (alias PVID42) umstellen...dann passiert was?
Testen.
Okay. Wenn ich mein Smartphone mit dem GoogleWifi-eigenen WLAN verbinde, lande ich schon mal im hide.me-Tunnel. Das hatte ich mir oben/letzte Woche ja auch schon genau so gedacht.
Klappt also.
Allerdings sieht der VLC auf meinem Smartphone den DLNA-Server nicht [mehr].
Das Smartphone hat eine IP im 192.168.86.x'er Netz, dessen MAC erscheint nicht auf dem Switch, dafür aber in der GatewayVM - jedoch mit falscher IP. Das liegt aber wohl daran, dass das Smartphone eine MAC-Adress-Reservierung auf dem DHCP-Server der GatewayVM besitzt.

Mein WLAN-Router im Büro (mit der SSID "FreifunkWees01.0 (http://ffw)") zeigt sich unbeeindruckt. Welch Wunder - der hängt direkt am Switch.
Verbinde ich mein Smartphone zu dem, lande ich im hide.me-Tunnel und sehe gleichzeitig meinen DLNA-Server.

Aber was solls. Wenn GoogleWifi-Gäste eine IP im 192.168.86.x'er Netz bekommen, werden die schwerlich mit SocketServern in Verbindung treten können, die sich im 192.168.42.x'er Netz befinden.
Was tun?
Ich bräuchte GoogleWifi's, die untereinander per IPv6 meshen und darüber IPv4 transparent durchleiten. Tja, schön wärs.

Oder ich lege auf meinem WLAN-Router, der direkt am Switch hängt, ein zweites Radio an. Und zwar mit der SSID "FreifunkWees01.2 (http://ffw)". Logger und Rollladen-Steuerung stehen nur ein Deck höher und sollten den erreichen können.
Damit würden dann zumindest schon mal alle Selbstbau-Schaltungen ihr "home" finden und folglich auch ihre Daten loswerden.
Der jetzige 1.2 würde zu 1.1 umbenannt werden - und nur noch Internet ausliefern. Intranet gäbe es nur, wenn 1.0 oder 1.2 erreicht werden können.
Damit bliebe nur noch der DLNA-Server als Problemfall übrig. Und der könnte einfach ein drittes Interface bekommen und drüber auch ins 192.168.86.x'er Netz ausliefern.
Mal schauen. Nicht mehr heute.


Klappt wie gedacht

Vorhin habe ich zunächst das zweite Radio auf meinem Büro-WLAN-Router angelegt und das vom Wohnzimmer-WLAN-Router umbenannt.
Ein Druck auf die Reset-Taste an der Rollladen-Steuerung hat dazu geführt, dass sich die Schaltung die aktuelle Uhrzeit via WLAN holt. Der Monitor hat eine Verbindung registriert und den Warnlevel auf "Schaltung hat neu gestartet" gesetzt.
Beim Logger war es ein sog. SonderSync. Kam auch an bzw. hat seine Daten erfolgreich abgeliefert.
Somit kommen beide Schaltungen problemlos im Büro/Keller an.

Dann kam der erste PowerLAN-Adapter aus der Steckdose. Nun hängt der Wohnzimmer-WLAN-Router per Kabel am GoogleWifi.
Gleich via Smartphone damit verbinden...Internet ist da...der hide.me-Check meldet "Sie sind mit unserem VPN verbunden und ihr echter Standort wird verschleiert".
Perfekt!

Nun kam der trickige Teil. Erstmal auf dem Switch ein VLAN10 anlegen, dann Port23 vom Switch auf PVID10 legen und bei Port2 (KVM-Host) und Port3 (Hauptrechner, auch temporärer KVM-Host) das VLAN10 als tagged einstellen.
Auf Port23 wird der Ausgangs-Port des GoogleWifi gepatched. Jetzt gehen also zwei Kabel vom Switch zum GoogleWifi. Eingang und Ausgang sozusagen :-)   (bezogen auf den DHCP-Server des GoogleWifi).
Vorsichtshalber habe ich mir erstmal eine (alte, gammelige und derzeit ungenutzte) Debian10-VM (Switch-Port3) geschnappt, dort vlan-Support installiert und ein neues Interface angelegt:
auto enp1s0.10
iface enp1s0.10 inet dhcp
   vlan-raw-device enp1s0
Hat ein paar Versuche und Switch-Konfigs gedauert, aber irgendwann kam dann bei "ip a" das hier mit:
3: enp1s0.10@enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:b9:ea:36 brd ff:ff:ff:ff:ff:ff
    inet 192.168.86.28/24 brd 192.168.86.255 scope global dynamic enp1s0.10
       valid_lft 86393sec preferred_lft 86393sec
    inet6 fe80::5054:ff:feb9:ea36/64 scope link
       valid_lft forever preferred_lft forever
Will heißen: das Ding hat sich eine IP-Adresse vom DHCP-Server des GoogleWifi geholt.

Daher nun auf die DLNA-VM und dort der "/etc/network/interfaces" folgendes zugefügt:
auto eth0.10
iface eth0.10 inet dhcp
   vlan-raw-device eth0
und in "/etc/minidlna.conf" musste nur eine Zeile etwas erweitert werden:
network_interface=eth0.42,eth0.10,eth0
Aktivierung per Reboot und dann Test an der Glotze.
Klappt!
Der DLNA-Server wird gesehen und liefert seine Videos ruckelfrei aus.
Damit war der nächste PowerLAN-Adapter abgelöst.

Eine Mini-Einschränkung gibt es allerdings: ich komme jetzt nicht mehr so einfach an das WebGUI meines WLAN-Routers im Wohnzimmer ran.
Dazu werde ich eine VM brauchen, die ins VLAN10 kommt und eine volle Desktop-Umgebung samt Firefox an Bord hat.

Dann werde ich gleich mal die nächsten drei GoogleWifi's ordern.
Hey...ist direkt billiger geworden. Nur noch für den Dreierpack. Naja...2€...kaum der Rede wert.
Sollen Samstag kommen.
Mal schauen, ob es hier dann noch Updates geben muss - ich hoffe ja mal, dass nicht.
Damit wäre dieses Projekt jetzt abgeschlossen.


dann doch noch ein Update

Freitag. Und schon sind die nächsten drei GoogleWifi-Adapter angekommen.
Die #4 landete im Dachgeschoß. Also ein Deck über dem Schlafzimmer. Der Mesh-Test meldet dafür "gute Verbindung".
Bis der Adapter soweit war, hat es wieder gefühlte 15 Minuten gedauert...Meshen...Update...und wat weiss ich noch. Zumindest gabs dazu kreative [regelmäßig wechselnde] Fortschrittsmeldungen. Schon ein bischen albern...
Damit konnten die beiden letzten PowerLAN-Adapter verschwinden bzw. im Schrank landen.

Aber irgendwie war da noch ein Denkfehler bzgl. der WLAN-Router.
Die hängen jetzt mit ihrem WAN-Port am GoogleWifi und werden also ihre interne IP-Adresse von dort beziehen.
WLAN-Traffic leiten sie mit einem VLAN42-Tag aus dem WAN-Port heraus. Und da müsste es dann eigentlich verrecken. Aber wieso war mein Test im Wohnzimmer am Mittwoch erfolgreich? Naja, zu dem Zeitpunkt gabs den Weg über Port23 noch nicht. Kann das der Grund gewesen sein?
Egal. Jetzt habe ich beide WLAN-Router abgebaut, ins Büro geschleppt, dort das VLAN42 wegkonfiguriert und sie wieder im Dachgeschoß bzw. Wohnzimmer installiert.
Die sind jetzt stumpfe WLAN-Bridge....oder wie auch immer sich ein derartiges Konstrukt nennen mag.

Im Dachgeschoß kommen laut "Speedtest von CHIP" hinterm WLAN-Router jetzt angeblich 19.5 Mbit/s down und 3.7 Mbit/s up bei einer Latenz von 53.5 ms an.
Sofern das stimmt, wäre es das Doppelte von dem, was da per PowerLAN im Idealfall je ankam.

GoogleWifi #5 ist in der Küche gelandet - mit der Idee, die Verbindung zum Dachboden zu verbessern. Mal schauen.

Nun habe ich noch eine Leap15.3-VM mit XFCE derart umgebogen, dass sie jetzt auch Teilnehmer im VLAN10 ist.
Ein "nmap -sn 192.168.86.0/24" liefert mir ruck-zuck die IP-Adressen, hinter denen Systeme online sind.
In Summe meldet nmap: "Nmap done: 256 IP addresses (11 hosts up) scanned in 4.21 seconds".

Jedoch habe ich keine Lust, mich da einzeln durchzutesten, um meine beiden WLAN-Router zu finden.
Also nochmal ohne den "-sn"-Parameter:
dede@localhost:~> nmap 192.168.86.0/24
Starting Nmap 7.70 ( https://nmap.org ) at 2022-05-13 19:38 CEST
Nmap scan report for 192.168.86.1
Host is up (0.00083s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
5000/tcp open  upnp
8080/tcp open  http-proxy
8081/tcp open  blackice-icecap
8443/tcp open  https-alt

Nmap scan report for 192.168.86.22
Host is up (0.011s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE
80/tcp   open  http
8080/tcp open  http-proxy
8081/tcp open  blackice-icecap
8443/tcp open  https-alt

Nmap scan report for 192.168.86.25
Host is up (0.0085s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE
80/tcp   open  http
8080/tcp open  http-proxy
8081/tcp open  blackice-icecap
8443/tcp open  https-alt

Nmap scan report for 192.168.86.27
Host is up (0.0069s latency).
All 1000 scanned ports on 192.168.86.27 are closed

Nmap scan report for dlna.lan (192.168.86.29)
Host is up (0.00021s latency).
Not shown: 995 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
111/tcp   open  rpcbind
8200/tcp  open  trivnet1
60020/tcp open  unknown

Nmap scan report for 192.168.86.31
Host is up (0.0070s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap scan report for com-mid1.lan (192.168.86.33)
Host is up (0.38s latency).
All 1000 scanned ports on com-mid1.lan (192.168.86.33) are closed

Nmap scan report for 192.168.86.35
Host is up (0.028s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE
80/tcp   open  http
8080/tcp open  http-proxy
8081/tcp open  blackice-icecap
8443/tcp open  https-alt

Nmap scan report for 192.168.86.36
Host is up (0.021s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap scan report for 192.168.86.37
Host is up (0.000042s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
22/tcp open  ssh

Nmap scan report for 192.168.86.43
Host is up (0.013s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE
80/tcp   open  http
8080/tcp open  http-proxy
8081/tcp open  blackice-icecap
8443/tcp open  https-alt

Nmap done: 256 IP addresses (11 hosts up) scanned in 301.94 seconds


Okay, die .31 und die .36 passen von den offenen Ports her zu den WLAN-Routern. Nach Logon ist die .31 offensichtlich der WLAN-Router im Wohnzimmer, die .36 ist der im Dachgeschoß.
Die .37 ist meine Leap15.3-VM, die .29 die DLNA-Server-VM.
Die .1 ist wohl der GoogleWifi im Büro und .22, .25, .35, .43 werden dessen Satelliten sein.
Bleiben noch .27 und .33 .... ?
Egal.
Somit komme ich jedenfalls bei Bedarf noch ans WebGUI meiner WLAN-Router ran, ohne sie vorher physikalisch bewegen zu müssen.
Nur mein schönes Bandwidth-Monitoring läuft jetzt ins Leere. Aber was solls. Da habe ich eh seit mindestens einem Jahr nicht mehr draufgeschaut.


sechs aktive Adapter

...lassen die Verbindungen nicht unbedingt besser werden.
Mittlerweile bin ich wieder bei drei Satelliten / vier GoogleWifis angekommen. Alle sind halbwegs mittig an der Nordseite des Hauses positioniert. Einer pro Etage.
Zeitweilig hatte ich alle sechs Adapter an wechselnden Orten im Haus verteilt. Trotzdem wurde das Mesh-Test-Ergebnis für den/die Satelliten im Dachgeschoß nicht besser, sondern eher deutlich schlechter - bis hin zu "offline".
Auch lautet die Empfehlung (in der App) bei schlechter Verbindung: "Bring deinen Wifi-Zugangspunkt für eine stabile Verbindung näher zum Router".
Zum Router!?
Also näher zum einspeisenden Google-Wifi-Adapter!?
Das entspräche m.E. aber nicht gerade der Idee eines Mesh-Netzwerks.... vielmehr wäre das dann ja nur eine simple Stern-Struktur.
So gesehen bin ich etwas enttäuscht.
Nichtsdestotrotz kommt im Dachgeschoß, bezogen auf PowerLAN, jetzt die doppelte Datenrate an (und Sohnemann#1 ist glücklich[er]).

Nun muss die Zeit zeigen, ob die Google-Dinger länger funktionieren, als es die PowerLAN-Adapter von AVM jeweils taten.
Und im Falle eines Ausfalls habe ich ja noch zwei Austausch-Adapter im Schrank liegen....also [hoffentlich] wieder ein paar Jahre Ruhe.