frndc.saschaschroeder.eu

Ein freundlicher Mensch schenkt mir aus Firmenbeständen ein #. Noch 'ne SSD dazu und eine kleine Aufmerksamkeit als Dankeschön, dann bin ich wieder für 5+ Jahre hardwaretechnisch abgesichert.

Nicht, das es in diesem Haushalt an Notebooks mangeln würde. Vielleicht muss ich irgendwann mal lernen, loszulassen. Beginnen könnte ich eventuell vielleicht möglicherweise mit dem #, aber der hat so viele coole Sticker und so viele Erinnerungen. Und er tut noch 1A, selbst mit # 44...

Hach!

#
gehrke_test
Was ein großartiges Projekt.

Erstmal # Feed abonniert: https://fbrc.dev/index.xml
#RSS
gehrke_test
De doorgedrukte besparingen in het onderwijs en de manier waarop het gebeurde (maar ook het disproportioneel harde politieoptreden tegenover minderjarigen) gaat sporen nalaten aan Franstalige kant. Het gonst. In plaats van over bootcamps of Brusselse jongeren te bazelen, blijft men aan Vlaamse kant beter bij de les.
Boah ey, das Mesh-Verhalten von # macht mich noch kirre!

Hab ja schon gelesen, dass das irgendwie selbstorganisierend und dynamisch ist und wenig vorhersagbar. Und so sind auch meine Beobachtungen mit der Visualisierung vom #. Ich vermute stark, die Organisation findet sich auf Basis von #, aber was ich sehe erscheint mir so unlogisch.

Ich habe den Server und viele Devices im Keller, dann eine erwünschte 'Luftbrücke' durch jeweils eine # im Flur im Erdgeschoss und im ersten Stock. Und dann zwei Devices im Badezimmer im ersten Stock.

Die Visualisierung zeigt ganz krude Verbindungen, beispielsweise von einer Steckdose im Keller bei geschlossener Tür mit zwei Stahlbetondecken zur Shelly im ersten Stock.
Aber nur eine schwache (LQI=76) Verbindung von der einen Shelly zur anderen, obwohl da ein freies Treppenhaus ist und die sich auf 7 Meter Luftlinie fast sehen können. Und die LED im Badezimmer verbindet sich nicht mit der Shelly im selben Stockwerk, sondern mit der eins drunter - obwohl beide selbes Modell, selbe Charge und selbe Firmware-Revision. WTF!

Das Debuggen mit der Netzwerk-Visualisierung ist wenig effizient.

#: Gibt es einen Weg, die aktuellen Verbindungsdaten per Konsole abzufragen - beispielsweise mit #?

# # #

Ausschnitt Zigbee Netzwerk-Visualisierung


Detail Verbindung Netzwerk zwischen den Shellys
Ausschnitt Zigbee Netzwerk-Visualisierung
Detail Verbindung Netzwerk zwischen den Shellys
gehrke_test
Und dann das hier: vom Coordinator zur Shelly geht mit LQI=218, und in der Gegenrichtung mit LQI=45. Häh?!?

Verbindungseigenschaften Zigbee-Netzwerk

#
gehrke_test
OK, in diesem Fall neige ich dazu, der KI zu glauben:
5. LQI ist richtungsbezogen und nicht zwingend symmetrisch

Das ist der wichtigste technische Punkt:
LQI wird jeweils am empfangenden Gerät gemessen.

Also:
- der Wert für Coordinator → Shelly wird faktisch von der Shelly beim Empfang beurteilt
- der Wert für Shelly → Coordinator wird vom Coordinator beim Empfang beurteilt

Das sind zwei verschiedene Messungen, auf zwei verschiedenen Funkchips, mit evtl. unterschiedlicher Skala, Empfindlichkeit und Auswertung.

Deshalb sind gleiche oder ähnliche Werte nicht garantiert.

Habe die Shelly mal etwas weiter vom WLAN-Router positioniert.
gehrke_test
There are some security updates requiring a reboot. I'll restart the server in 20 minutes.

libranet.de · venera.social
alfred hat dies geteilt
So langsam bezweifle ich, dass die Entscheidung für # AirGuard TH - # # eine gute Wahl war. Länger als einen halben Tag hat das Ding noch keine Daten per # an # geliefert.

Weil ich vermutet habe, dass es an der Reichweite lag, habe ich mein # durch zwei # 1PM Mini Gen4 an strategischen Stellen ausgeweitet. Eigentlich (tm) sollte das nicht das Problem sein.

Hhmpff!

Verlaufsgrafik HomeAssistant - Kurve bricht ab

# # #
Verlaufsgrafik HomeAssistant - Kurve bricht ab
gehrke_test
4 Monate später bin ich immer noch nicht wirklich weiter. Die beiden Shellys hängen provisorisch an den optimalen Positionen, um eine Bridge vom Keller in den ersten Stock zu bauen. Sie sind stabil am Netz und wurden auf Auto-Update der # eingestellt. Eigentlich alles gut.

Aber der # TH # # ist weiterhin instabil und nur für kurze Zeit nach dem Pairing via # erreichbar.

Es erscheint mir ziemlich wahrscheinlich, dass es nicht an den Shellys liegt, aber solange ich keinen Beweis habe, möchte ich die nicht aufwändig verbauen.

Also habe ich jetzt mal als provisorisches Testsetup eine # LED im # im ersten Stock angeschlossen, vor denen wir eine zweistellige Zahl verbaut haben und die stabil mit Zigbee laufen - allerdings im #. Die war nach dem Pairing sofort ansprechbar für #. Kann nach meinem Verständnis ja nur über die Shelly-Bridge geroutet werden.

Das lasse ich jetzt mal etwas laufen, um die Stabilität zu bewerten.

Leider wird die Verbindung im Zigbee-Netzwerkdiagramm nicht wirklich sauber angezeigt.

# #

Testsetup: grün leuchtende LED in einer Badezimmerecke

Ausschnitt Zigbee Netzwerkdiagramm
gehrke_test
You should test the Paulman LED without the Shelly’s, to make sure that the Shelly’s are effectively bridging …
+++ Werbeblock: Nächster Schritt in meiner yubiKey-Journey jetzt mit # +++

Nicht, dass ich schon allzu viel # mit NFC-Support unter # hätte, aber auf Dauer wird es wohl auch bei mir kommen. Testphase beginnt jetzt...

# # #

Yubikey 5c NFC in Verpackung auf Fliesen
gehrke_test
Tja. der erste Eindruck bei NFC ist tatsächlich ernüchternd derzeit. Die einzigen beiden Devices mit Hardwaresupport für NFC sind # 4 mit # 15 ohne Google-Account.

Mit aktivem NFC und # kann ich eine Test-Datenbank mit Challenge-Response als zweiten Faktor nicht öffnen unter Hinweis auf einen fehlenden Treiber. Dazu gibt es wohl ein 3 Jahre altes Projekt # in #, welches ich auch ganz naiv testweise installiert habe. Das greift aber nicht und bei # bin ich sowieso schnell an der Grenze meiner Fähigkeiten und der Leidensbereitschaft.

Für den Moment geht es da wohl nicht weiter.
gehrke_test
Oh, wait!

Offenbar geht das doch, wenn man sich traut, den Treiber im APK-Format von GitLab zu installieren:
https://gitlab.com/kunzisoft/android-hardware-key-driver/-/releases

Dann ist es recht easy: In # zum Öffnen der Datenbank das Password als ersten Faktor und 'YubiKey Challenge-Response' als zweiten, dabei den YubiKey hinten an die Rückseite halten. Zack, bin ich drin.

# #

Screenshot Android YubiKey HMAC-SHA1

Ich hab das alles mal gemacht, ohne weiter Nachzudenken, was genau ich da tue und wie sicher das ist. Erst mal scheint das zu tun.
Screenshot Android YubiKey HMAC-SHA1
gehrke_test
Another test...

Bild/Foto
alfred
Test...

Bild/Foto
alfred
# #: # # war in wohl jeder Beziehung Mittelmaß. 1.307 kWh # geerntet, kein Eintrag in der ewigen Top10. Mehr gibt es nicht zu sagen.

# # # # # # # #

Statistiktabelle PV
Statistiktabelle PV
gehrke_test
Go, Marie-Agnes. Go!
gehrke_test
»Liberalismus heißt nicht, sich morgens einen Gegner zu suchen, um abends in den Sessel zu fallen, wenn man ihn erfolgreich beleidigt hat.«
gehrke_test
Der Zugriff auf # / # auf meinem primären Notebook klappt nun mit beiden Yubikeys auch beim Booten, aber das war unter # 44 schon etwas tricky und ist noch nicht perfekt:

root@j20:~# systemd-cryptenroll /dev/nvme0n1p3
SLOT TYPE    
   0 fido2
   1 password
   2 password
   3 fido2
   4 recovery


Was noch nicht optimal läuft, ist die Eingabe der Passphrase für den Security Token beim Booten, die zwar funktioniert, aber nicht von der normalen Eingabe zu unterscheiden ist. Erst danach wird man zum Berühren des Tokens aufgefordert.

Kein Schimmer, wie man das noch verbessert. Aber das ist Jammern auf hohem Niveau...

# # # # # #

Eingabe der Passphrase sieht aus wie immer

Bootmeldung: Bitte Security-Token berühren
Eingabe der Passphrase sieht aus wie immer
Bootmeldung: Bitte Security-Token berühren
gehrke_test
@⁉️
Das ist gut zu hören, sicherlich bekommt man das auch mit Fedora hin. Hast Du mal einen Screenshot, wie die Abfrage der Passphrase bei Dir beim Booten aussieht? TNX


> Boot without user interaction
>
> If you want the machine to be unlocked only by the YubiKey, you can add the challenge/passphrase from the enrollment step to /etc/ykluks.cfg

OK, diesen Weg möchte ich nicht gehen.
gehrke_test
Updates to install:
MariaDB database server
Linux kernel

A reboot is required. Will do that in 10 minutes.
alfred hat dies geteilt
Updates and reboot done.
alfred
Und auch der Zugriff auf # klappt mit beiden Yubikeys. Das war ja einfach...

root@j20:~# systemd-cryptenroll /dev/sda1
SLOT TYPE    
   1 fido2
   2 recovery

root@j20:~# systemd-cryptsetup attach testcrypt /dev/sda1 && mount /dev/mapper/testcrypt /mnt && cat /mnt/secure
🔐 Please enter LUKS2 token PIN: •••••••••••••           
Asking FIDO2 token for authentication.
👆 Please confirm presence on security token to unlock.
42


# # # # # #
gehrke_test
In Slot 0 war zuvor eine manuell gesetzte Passphrase gespeichert, die ich im Verlauf der Tests auch manuell gelöscht hatte.

Slot 0 ist danach scheinbar neu belegt worden mit dem zweiten Yubikey.
gehrke_test
Wo ich auch noch mal bei muss: # weiß noch nichts davon, dass ein # im Spiel ist. Ohne Konsole poppt einfach nur der übliche Dialog auf, der nach der Passphrase fragt.

gehrke_test
Hab mich ja lange nicht getraut, meine produktiven Passwort-Datenbanken von # mit einem zweiten Faktor abzusichern.

Nun läuft das zusätzllch mit Challenge-Response via #.

Auch wenn ich redundante Sticks an unterschiedlichen Orten habe und mir den Private Key für HMAC-SHA1 gut für den Notfall gesichert habe: Mal sehen, wie lange es dauert, bis ich mich selbst ausgesperrt habe...

# #
gehrke_test
Warum solltest du?
Aus schlichter Unfähigkeit beispielsweise.
gehrke_test
neuer älter