So you rely on the fact that only root can start services and that the service that has a security problem which you stopped and for which you did autostart disable thus stays down?

Well, what the heck, why should systemd developers implement such an Hax0r's hindrance? Thats' what "ActivationRequest" signals are for. Just start any service with no authority check, isn't that a cute feature?

... that select, poll, epoll and friends where invented a while ago and that networks tend to fail spuriously from time to time? Probably not as a short wireless outage while "dirmngr" is running makes that rubbish of a so called tool start to consume 100% cpu and needs to be killed before the laptop fans get their outage, too. And thanks to having to kill this waste of code this trash happily ruins the keyring it is supposed to be working on while going down.

Yes, planning and implementation of modern and functional software that is actually usable tends not to be part of the skills required for gnupg development.

...be sure to run all software promoted by freedesktop.org. You will get:

• monstrous programs like accounts-daemon that for sure can't be audited but insist on accessing /etc/shadow to offer account services relying on the broken and virtually unmaintained Polkit via DBUS instead of relying on tried and usually trustable services like PAM
   
• programs like systemd that are designed with the 1970s concept of "root is allowed everything" that don't even offer any mechanism to restrict access
   
• again programs like systemd that are soooo flexible that you can't e.g. have your own unit definition and then mask the unit (may be temporarily required) as your unit definition and the masking symlink are require actually the same pathname, nah, doesn't happen on big $$$ corp. systems, unneeded feature
   
• software that is designed to be liked by managers of big $$$ corporations as the broken design fits the monitoring plans on the sheet of printed paper lying on their desktop
   
• software that is for sure not designed with end user desktop system security in mind

The mainainers of freedesktop.org should rename their site to megacorpsupport.com as this fits the intention of the software hosted there. I just do wait for the moment when "freedesktop.org" starts to promote the "we don't need any programs anymore, just shared libraries loadable by our awsome systemd" slogan. And if they manage, a little later there will probably be the "in the future only libraries signed by our big $$$ friends will be acceptable for loading by systemd" enhancement. Well, yes, like Steven King's "new and improved" interpretation (you should read "Tommyknockers").

One should really be aware that freedesktop.org is not a real promoter of the open source idea, instead it promotes "embrace and extend" which is the method of a certain Redmond company.

Polkit is broken. Completely. Not only that there's usability bugs that break command line usage pending for years - it relies on an "Authentication Agent". The latter is typically provided by your desktop environment and consists of a part running as the user and a part running as root.

The brokenness is that Polkit doesn't do any actual authentication itself. It relies on the "Authentication Agent" doing "the right thing" and signalling "access granted" or "access denied".

Now desktop environments are not exacly known for providing components that are heavily security audited. And they do things their own way. Thus it is quite usual that an application requests root rights and the "Authentication Agent" of the desktop environment just asks for the user's password to signal "access granted". So just running "pkshell" and entering your accound password provides for a root shell, even if the whole system is configured to require the root password for any actual root shell. Doh.

It could have been so easy if Polkit would have been properly designed. Polkit is accessed via DBUS and DBUS allows for file descriptor transfer. Thus the authentication request via Polkit could still make use of an "Agent", the "Agent" however just providing the authentication information via the file descriptor and Polkit doing the actual authentication using tried and mostly reliable methods e.g. via PAM. And in this case Polkit could have been configured to e.g. enforce presentation of the root password for root actions by default except where defined explicitly otherwise via a policy.

But well, this ship has sailed a long time ago and thus Polkit is another example of short thinking with regard to security, resulting in bad security.

Systemd developers seem to behave like little children playing with their new toy in front of their home and not being aware that the nearby road is a constant danger to their life.

This is the only reason I can see why systemd allows for service control via DBUS without any means of restricting what can be done. I don't mind systemd having its own private control socket (except for it's location which again prevents security measures) with full service control.

So any malicious application that can pretend to be legitimate via DBUS can wreak havoc to a systemd controlled system. Systemd developers should have been aware that uid 0 is just an insufficient credential and has been for many years. But well, little children don't know better.

The sad thing is that nobody on the systemd side seems to care about security. No wonder the head systemd developer was welcomed by this certain Redmond company that is well known for losing important private keys. Maybe the remaining developers should head there, too. And maybe then developers with a sense of security in mind can try to salvage the pieces.

At least now I do understand why Ubuntu is patching the kernel so heavily for Unix domain socket and DBUS control. And yes, from a security point of view this stuff would need to be applied to mainline urgently to get at least some control back into the hands of an administrator that really takes care when it comes to system security.

Is it necessary for some zero day exploit to cause worldwide havoc until kernel developers get it that the beloved systemd init system is fatally flawed and needs restrictions that can only be applied via additional kernel security?

Does one really need to develop eBPF code that gets attached to the proper Unix domain sockets and then filter unwanted stuff - given that this is actually possible? Why is there no systemd configuration that can deny dbus requests as specified by the system adminsitrator? How big must a security hole be to be acknowledged as such?

And yes, this "feature" can threaten lives. Try to make an urgent emergency call when your home pbx has been shut down by a malicious application marauding system services via the oh so cute DBUS interface of systemd. Ok, no way to call for help, die a little bit earlier, thanks to the stupidity of systemd developers.

Well, I just wanted to do a fresh install of Tor browser. Ahem, not possible, key expired (!?!). So I looked at the Tor Project's web site for further information. So let's try to fetch the signing keys manually according to the above information: 

gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser@torproject.org

This gives some more information, which isn't really helpful at all:

gpg: error retrieving 'torbrowser@torproject.org' via WKD: General error
gpg: error reading key: General error 

So back to the drawing board and edit ~/.gnupg/dirmngr.conf to contain:

debug-level guru
log-file /tmp/dirmngr.log

Then kill dirmngr which otherwise stays as an unwanted daemon in the background and thus never re-reads its configuration and retry. As expected the above error persists, so let's look at the debug output (*** means 'obfuscated' and some wrapping applied):

dirmngr[813092] listening on socket '/run/user/***/gnupg/S.dirmngr'
dirmngr[813093.0] permanently loaded certificates: 145
dirmngr[813093.0]     runtime cached certificates: 0
dirmngr[813093.0]            trusted certificates: 145 (145,0,0,0)
dirmngr[813093.6] handler for fd 6 started
dirmngr[813093.6] DBG: chan_6 -> # Home: /home/***/.gnupg
dirmngr[813093.6] DBG: chan_6 -> # Config: /home/***/.gnupg/dirmngr.conf
dirmngr[813093.6] DBG: chan_6 -> OK Dirmngr 2.2.41 at your service
dirmngr[813093.6] connection from process 813090 (***:***)
dirmngr[813093.6] DBG: chan_6 <- GETINFO version
dirmngr[813093.6] DBG: chan_6 -> D 2.2.41
dirmngr[813093.6] DBG: chan_6 -> OK
dirmngr[813093.6] DBG: chan_6 <- WKD_GET -- torbrowser@torproject.org
dirmngr[813093.6] DBG: chan_6 -> S SOURCE https://openpgpkey.torproject.org
dirmngr[813093.6] number of system provided CAs: 0
dirmngr[813093.6] TLS verification of peer failed: status=0x0042
dirmngr[813093.6] TLS verification of peer failed: The certificate is NOT trusted.
        The certificate issuer is unknown. 
dirmngr[813093.6] DBG: expected hostname: openpgpkey.torproject.org
dirmngr[813093.6] DBG: BEGIN Certificate 'server[0]':
dirmngr[813093.6] DBG:      serial: 0468C1A495902B3A5BE46845EF6767A04B2E
dirmngr[813093.6] DBG:   notBefore: 2023-09-02 00:48:10
dirmngr[813093.6] DBG:    notAfter: 2023-12-01 00:48:09
dirmngr[813093.6] DBG:      issuer: CN=R3,O=Let's Encrypt,C=US
dirmngr[813093.6] DBG:     subject: CN=openpgpkey.torproject.org
dirmngr[813093.6] DBG:         aka: (8:dns-name25:openpgpkey.torproject.org)
dirmngr[813093.6] DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[813093.6] DBG:   SHA1 fingerprint: 86A624B2EF0BDA723F2459B2C90D20D33E7EA8AD
dirmngr[813093.6] DBG: END Certificate
dirmngr[813093.6] DBG: BEGIN Certificate 'server[1]':
dirmngr[813093.6] DBG:      serial: 00912B084ACF0C18A753F6D62E25A75F5A
dirmngr[813093.6] DBG:   notBefore: 2020-09-04 00:00:00
dirmngr[813093.6] DBG:    notAfter: 2025-09-15 16:00:00
dirmngr[813093.6] DBG:      issuer: CN=ISRG Root X1,O=Internet Security Research Group,C=US
dirmngr[813093.6] DBG:     subject: CN=R3,O=Let's Encrypt,C=US
dirmngr[813093.6] DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[813093.6] DBG:   SHA1 fingerprint: A053375BFE84E8B748782C7CEE15827A6AF5A405
dirmngr[813093.6] DBG: END Certificate
dirmngr[813093.6] DBG: BEGIN Certificate 'server[2]':
dirmngr[813093.6] DBG:      serial: 4001772137D4E942B8EE76AA3C640AB7
dirmngr[813093.6] DBG:   notBefore: 2021-01-20 19:14:03
dirmngr[813093.6] DBG:    notAfter: 2024-09-30 18:14:03
dirmngr[813093.6] DBG:      issuer: CN=DST Root CA X3,O=Digital Signature Trust Co.
dirmngr[813093.6] DBG:     subject: CN=ISRG Root X1,O=Internet Security Research Group,C=US
dirmngr[813093.6] DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[813093.6] DBG:   SHA1 fingerprint: 933C6DDEE95C9C41A40F9F50493D82BE03AD87BF
dirmngr[813093.6] DBG: END Certificate
dirmngr[813093.6] TLS connection authentication failed: General error
dirmngr[813093.6] error connecting to 'https://openpgpkey.torproject.org/.well-known/
        openpgpkey/torproject.org/hu/kounek7zrdx745qydx6p59t9mqjpuhdf?l=torbrowser': General error
dirmngr[813093.6] command 'WKD_GET' failed: General error <Unspecified source>
dirmngr[813093.6] DBG: chan_6 -> ERR 1 General error <Unspecified source>
dirmngr[813093.6] DBG: chan_6 <- BYE
dirmngr[813093.6] DBG: chan_6 -> OK closing connection
dirmngr[813093.6] handler for fd 6 terminated
dirmngr[813093.0] running scheduled tasks (with network)
dirmngr[813093.0] running scheduled tasks
dirmngr[813093.0] running scheduled tasks

Now WTF!?! The ISRG X1 root CA is loaded as a system CA certificate, what is going on here? Whatever one tries, you just seemingly can't get past this error. Searching the web then points to SKS pool CA which one e.g. on Arch Linux has to include in ~/.gnupg/dirmngr.conf as: 

hkp-cacert /usr/share/gnupg/sks-keyservers.netCA.pem

Now this leads to the interesting point that dirmngr refuses the above certificate as expired. And there won't be any new SKS CA for sure. So what? Another lengthy online research turns out that the wisdom of the GnuPG developers is without any limits - and as such they decided that a trusted root CA is for sure not a trusted HKP CA. So, to get things working again one has to find the local system's storage of the ISRG X1 CA and make ~/.gnupg/dirmngr.conf to contain the following (path below is for Arch Linux):

hkp-cacert /etc/ca-certificates/extracted/cadir/ISRG_Root_X1.pem
keyserver hkps://keys.openpgp.org

Kill dirmngr and restart all over. You will be surprised that with this well thought out and and perfectly documented configuration gnupg suddenly starts to work again.

So something that should have worked out of the box has taken me half a day to trace down and adjust back to working order. Now I know what I'm doing when tracing thing down. Ordinary users don't. No wonder gnupg is as disliked as it is. This is just disgusting.

And, oh, try to use dirmngr while there is a short upstream network outage and see how happily this oh so well coded beast starts to consume 100% cpu, as GnuPG developers seemingly despise select, poll and similar calls, they do prefer to do a polling loop at any cost. Maybe they're stakeholders of certain CPU producing companies...

mosh would be beautiful to use as its designed for high latency links as well as for lossy networks - if it would only support TCP as an alternative communication mode.

The only place where I do encounter untolerable high latencies for interactive typing is emergency access to my home systems using onion routing. Thats when either there's a DNS failure or ssh access is blocked by some proxy. And that's exactly when you can't use mosh as it has a more than 10 years old PR for TCP support that continues to get ignored.

Usually the speed of your TCP based ssh connection is sufficient and you don't need mosh. And if not chances are that you can't use mosh anyway due to UDP insistance. Thats what I call a dead horse.

Ja, Lancom macht alles gaaanz sicher. So sicher, das man es erst einmal nicht nutzen kann. Denn man muss erst die Dokumentationsvariante finden, in der sich der entscheidende Hinweis befindet.

Ok, NPTv6 hört sich erst einmal gut an, eine fixe interne 64-Bit ULA, die vom Router auf die sich immer ändernde externe Adresse gemappt wird, macht ja vieles einfacher. Doch dann sucht man die externe Adresse und wundert sich über die "Verunstaltung". Nach längerer Suche findet sich dann in einer Lancom Dokumentation (aber nicht in den anderen durch die Suchmaschinen aufgefundenen) der schüchterne Hinweis auf RFC6296.

Und RFC6296 beschreibt, was es mit der "Verunstaltung" der externen Adresse auf sich hat. Da bleibt einem nichts anderes übrig, als ein Tool zu schreiben, dass aus dem externen Prefix und der internen Adresse die tatsächlich vom Router verwendete Adresse generiert.

Der Clou dabei ist, dass dieser RFC als "Experimental" gekennzeichnet ist und somit keinen Standard darstellt. Warum wird als bei der doch so auf Sicherheit bedachten Firma Lancom als experimentell gekennzeichneter Kram als "Standard" implementiert und warum findet sich der Hinweis nicht in jeder Dokumentation zu NPTv6? Hätte es nicht eine einfache n:n Network Translation auch getan? Warum muss jetzt jeder Code schreiben, um seine externe Adresse ohne externen Hilfs-Server zu finden?

Nebenbei bemerkt, die Qualität von RFC6296 kann man wohl auch daran messen, wie gut der Referenzcode funktioniert. Und der schlägt mit einem aktuellen Compiler fehl.

Als Sahnehäubchen darf dann jeder, statt ein Aktions-Skript auf dem Router nutzen zu können, im Fall von DynDNS die IPv6-Adresse händisch von einem "Server" im Netzwerk updaten, da das dank der RFC6296 Implementation durch den Lancom Router selbst nicht mehr möglich ist - es sei denn, man will die Adresse des Lancom-Routers selbst bekanntgeben, der aber für IPv6 kein Port Forwarding unterstützt...

There is a privilege escalation in the Linux AppArmor LSM that is present in probably all kernels since July 2019 that can lead to full system compromise. Looking at the kernel code the Tomoyo LSM is probably affected, too (not tested).

As I'm trying to be fair I did post information about this to the AppArmor mailing list where it sits "awaiting moderator approval" since days. I'm slowly but steadily going to assume that AppArmor mailing list moderation effectively means "send to /dev/null"...

Thus I'm trying now to get a CVE assigned to this. I will post further information about the problem and a band aid fix on my Github account at a later stage.

The thing is that sddm is and has always been a major problem. Disable suspend and hibernate on the login screen? Well, no such option, one has to patch the related QML file. And this is just for starters. Creating an AppArmor profile for sddm-helper is what on calls a PITA. Highly sensitive is the understatement of the day in case of this beast.

And even then if one gets the idea to confine systemd-logind with AppArmor sddm falls completely apart. And that's even when the systemd-logind profile is just in complain mode. As soon an systemd-logind gets an AppArmor profile sddm chokes and causes startplasma-x11 to hang forever. The relevant differences are in the process environment for startplasma-x11:

systemd-logind unconfined:

PAM_KWALLET5_LOGIN=/run/user//kwallet5.socket XDG_SESSION_ID= XDG_RUNTIME_DIR=/run/user/ 

systemd-logind in complain mode: 

PAM_KWALLET5_LOGIN=/tmp/kwallet5_ast.socket

The solution to this problem is to replace sddm by lightdm which happily ever after works when confined under AppArmor including systemd-login confinement in enforce mode. And as an extra feature the power stuff on the login screen can be disabled by simple configuration. Maybe KDE developers should book a course in DM programming at the lightdm academy...

Edit:

Actually the problem is a rare case of Arch Linux to blame first. Arch systemd is compiled without AppArmor support though I don't see any reason for this. Now, if I would be 20 years younger I'd recompile systemd. But age causes a little lazyness.

Nevertheless, why doesn't systemd complain when a security relevant feature is used that is not compiled in? The systemd stuff is usually so noisy that it kills off an SSD every other week by means of TBW. And just for things that are really relevant there's utter silence. Doh.

Original Post:

Yes, everybody has to use systemd. And as there is a broad user base it is well audited...

Now look at the systemd.exec documentation for AppArmorProfile=. Try to use this option in good faith. Doh, target process keeps unconfined. Now, let's remove this broken fake feature line and add aa-exec -p at the start of the ExecStart= string instead and watch your process being perfectly confined by AppArmor.

Well, it seems that security is not one of the strong systemd features. So I do suppose the strongest features are annoyance and frustration to make users change to that "easy" Redmond OS...

And don't anybody try to tell me "well, in general it works, but its broken in this or that release". From a security point of view any kind of brokeness of a relevant security feature means that you can not trust such code anymore, ever - except if you use this Redmond stuff where even a catastrophic key loss is played down as "well, can happen".

Ich habe mal ein Snom M80 DECT Telefon angeschafft. Gegen das Telefon an sich gibt es nichts zu sagen. Aber: Die Ladeschale ist so leicht, dass sie ohne das darauf befindliche Telefon bereits vom dünnen Netzkabel in Bewegung gesetzt wird. Und dann die Lade-LED: Beim M65 war das ein dezentes dunkles Blau. Das hat wohl die Nacht nicht gut genug erhellt. Deswegen nun ein hell stahlender grüner Punkt. Bezüglich Ergonomie insbesondere in Bezug auf Augenfreundlichkeit haben die Entwickler bei Snom wohl noch nichts gehört. Dazu dann noch ein USB Netzteil, dass von seiner Bauform her extrem klobig ist. Hatte ich schon erwähnt, dass das M80 ja IP65 zertifiziert ist, die Ladeschale dagegen, die man dann möglicherweise auch in feuchteren Räumen betreibt, eine USB-Buchse - natürlich ohne Abdeckung - besitzt?

Und dann das M900. Ja, laut Snom kann man es auch aufstellen. Das sollen die mal vorführen. Es gibt keinen Standfuß und der Ethernetkabelauslass ist so gestaltet, dass man zum einen das Kabel zwingend heftig knicken muss und dann starrere geschirmte Kabel, die sich zurückformen, das leichte M900 sofort "flachlegen". Nun, möglicherweise gibt es ja irgendwann einen "Tischadapter" als Zubehör, natürlich gegen Aufpreis...

Allerdings - und das ist ein Fortschritt - kann man auf dem M900 (vermutlich) ab Softwareversion BS530 (mit der Werksversion, eine frühe 500er geht das nicht) ein Webserver-Zertifikat nebst private Key recht einfach installieren - wenn man denn herausfindet, wie. Es braucht das Zertifikat und den Private Key (kennwortlos) im PEM-Format. Ich habe 2048 Bit RSA verwendet, mit anderen Schlüsseltypen möge man es selbst testen. Dann die Dateiauswahl im Browser bemühen und dabei gefissentlich den irreführenden Web-Text bezüglich ".cer" und ".key" ignorieren. Und nun der Trick. In der Dateiauswahl des Browsers müssen sowohl Zertifikat als auch Private Key gleichzeitig ausgewählt werden, d.h. nach dem OK muss im Dateiauswahlfeld ein Text bezüglich zweier Dateien stehen. Dann den Upload starten und schon hat man sein eigenes Webserver-Zertifikat auf dem Gerät. Den wesentlichen Hinweis, dass das so zu handhaben ist, habe ich in einer US-Dokumentation gefunden, die deutsche Doku hierzu enspricht dem Schweigen der Lämmer.

Ach ja, bevor ich es vergesse: Die Replikation zwischen im Verbund betriebenen M900 Geräten ist etwas übereifrig. Das Webserver-Zertifikat nebst Private Key wird nämlich ebenfalls repliziert. Das sollte man bei der Zertifikatserzeugung beachten und SNI dafür nutzen, im Zertifikat die DNS-Namen aller im Verbund betriebenen M900 einzutragen.

Ja, mit der Sicherheit nimmt es Lancom ganz genau. Deswegen sind die Access Points der LX Serie so sicher, dass man kein Webserver-Zertifikat installieren kann, was zum einem mit dem normalen LCOS von Lancom ja möglich ist und was inzwischen jedes noch so popelige Gadget beherrscht. Nun, vielleicht entfernt Lancom ja noch die Möglichkeit der Zertifikatsinstallation aus dem normalen LCOS, damit sie auch dort dokumentieren können: "Speichern Sie einfach eine Ausnahme im Browser". Ja, Lancom, wie sicher! Das wird garantiert vom BSI gelobt!

If you run a environment with WLCs and a Radius server make sure that you are able to view the WLC stored PMKs for wireless clients and that you are especially able to delete a stored PMK on the WLC.

Otherwise a blocked or deleted user will have Wifi access until the PMK expires, which may take hours!

Lancom präsentiert sich ja als ein Unternehmen, das auf Sicherheit großen Wert legt. Das stimmt. Diese Firma ist so sicher, dass es keine Möglichkeit gibt, Sicherheitslücken zu melden.

Ja, natürlich gibt es die tief im URL-Urwald versteckte Möglichkeit, ein Problem zu melden. Aber: Erst einmal tut sich gar nichts und dann kommt nach diversen Tagen eine Mail mit folgendem Inhalt:

Im technischen Support für Endkunden kommt es zu Wartezeiten von mehreren Wochen, da wir die Support-Anfragen unserer Fachhandelspartner bevorzugt behandeln.

Ja, die Fachhandelspartner, bei denen man das Gerät nicht gekauft hat, weil die z.B. Arztsoftware vertreiben, sind garantiert die willigen und kompetenten Ansprechpartner für tief im LCOS System vergrabene Sicherheitslücken, oder?

Man denkt sich nun, "Es gibt doch noch das Lancom Forum, dort lesen doch auch Lancom Mitarbeiter mit". Nur ist man auch dort sehr auf Sicherheit bedacht. Daher kann man sich in diesem Etepetete Forum mit einer vulgären und sicher ganz gefährlichen Gmail-Emailadresse nicht anmelden. Welche elitären Email-Adressen denn nun den Zugang zum Forum ermöglichen, wird leider nicht verraten.

Da es also keine Möglichkeit gibt, zeitnah zu Sicherheitsproblemen und fatalen Bugs auf irgendeine Weise mit Lancom in Kontakt zu treten, mache ich das jetzt hier. Wenn es die ganze Welt lesen kann, dann auch Lancom. Vielleicht tun sie es ja sogar.

Szenario unter LCOS 10.72.0203:

Ein Mitarbeiter einer Firma mit sensitiven Daten macht immer mehr mit Problemen auf sich aufmerksam. Die Firma ist natürlich sicherheitsbedacht und setzt darum einen oder mehrere WLCs, sowie diverse APs von Lancom ein. Dem Chef kommen die Probleme zu Ohren und er beschließt, den Mitarbeiter aus den sensitiveren Bereichen auszusperren. Der Netzwerk-Admin sperrt auch sogleich den Zugang und sorgt dafür, dass sich der Mitarbeiter abmeldet. Alle gehen nun davon aus, dass der Mitarbeiter keinen Zugriff mehr auf die sensitiven Daten hat. Einige Stunden später tauchen tagesaktuelle Daten, die nach der Sperrung des Mitarbeiters gespeichert wurden, im Darknet auf. Wer war das? Der Mitarbeiter doch nicht, der war ja ausgesperrt? Eben doch!

Ursache:

Da das Benutzermanagement dieser Firma nicht von Lancom stammt, sind die WLCs und APs über einen externen Radius-Server an das Benutzermanagement angebunden. Die WLCs und APs speichern für einen angemeldeten Benutzer ein PMK, damit dieser schnell zwischen den APs wechseln kann, ohne dass es zu Verzögerungen durch eine erneute Anfrage beim Radius Server kommt. So weit, so gut.

Es gibt nun aber keine Möglichkeit, die PMK-Speicherzeit einzustellen, oder aber ein PMK zu löschen. Die Standardspeicherzeit für ein PMK scheint bei Lancom knapp 12 Stunden zu sein. Dies bedeutet, dass ein ausgesperrter Client, der (ggf. durch Softwaremodifizierung) das clientseitige PMK vorhält, solange es gültig ist, sich während dieser Zeit am WLAN-Netzwerk anmelden kann, obwohl er es eigentlich nicht mehr darf.

Wer das testen will, kann sich im LCOS Menuebaum unter /Status/WLAN-Management/PMK-Caching die aktuellen Cache-Einträge ansehen. Nun einen externen Radius-Server (z.b. freeradius) einrichten und die WLCs so konfigurieren, dass dieser Radius-Server für die Benutzer-Authentifizierung verwendet wird. Als Test Client dient ein Handy mit aktuellem Android, die Zugangsmethode kann z.B. PEAP/MSCHAPv2 oder EAP-TLS jeweils mit automatischer Anmeldung falls in Reichweite sein. Nun das Handy anmelden, dann den Zugang im Radius-Server sperren. Auf dem Handy das WLAN deaktivieren einige Minuten warten, das WLAN wieder aktivieren und schon ist das Handy wieder angemeldet.

Und weil es so schön ist, demonstriere ich hier auch noch gleich, wie man einen LX-6402 AP mit LCOS LX 6.12.0024-Rel Firmware so sicher machen kann, dass nur noch eine Büroklammer für den Werksreset hilft, damit der Netzwerkadministrator sich auch einmal bewegt.

Man konfiguriere in einer vorherigen Firmware das "Untagged-VLAN", um den zweiten Netzwerkport des APs einer sinnvollen  Verwendung zuzuführen. Das funktioniert prima in allen Lebenslagen, auch wenn der AP neu gestartet wird. Will man den Admin jetzt so richtig auf Trab bringen, dann installiert man den Upgrade auf o.a. Firmware auf allen APs. Funktioniert ebenfalls prima - bis zum AP Neustart. Ab hier hilft dann nur noch die bereits erwähnte Büroklammer und was man an Leitern und ähnlichem Gerät noch so braucht, um die APs zu erreichen. Das nenne ich dann mal einen sicheren AP! 

Ever wondered how to install your shiny and brand new server certificate on a CBS250 or CBS350 device? Given up in utter despair? Fear no more, success just a few erratic and illogical steps away. But be sure that your certificate contains a 2048 bit RSA key (3072 bit RSA might work, too, but untested), Cisco doesn't like these fancy new EC things.

First of all, you will need a private key file with no password, you can archive this with:

openssl rsa -in encrypted.key.pem -out unencrypted.key.pem

Then you will need to extract the public key from your certificate, you can use:

openssl x509 -in cert.pem -pubkey -out pubkey.pem

This was very logical, right? Wait no more, log on via your browser to your switch and skip to:

Security => SSL Server => SSL Server Authentication Settings

Welcome to the Ministry of Silly Walks!

Rules:

• Ignore the certificate after the end of the public key in the openssl generated file.
  
  
• For all operations, public and private key must be modified as follows
  

  Public Key:
  -----BEGIN PUBLIC KEY-----      =>      -----BEGIN RSA PUBLIC KEY-----
  -----END PUBLIC KEY-----        =>      -----END RSA PUBLIC KEY-----
  
  Plaintext:
  -----BEGIN PRIVATE KEY-----     =>      -----BEGIN RSA PRIVATE KEY-----
  -----END PRIVATE KEY-----       =>      -----END RSA PRIVATE KEY-----
  

  
  
• Whenever a private key has to be entered the 'Encrypted' input field must be cleared and the private key must be placed in the 'Plaintext' field.
   
• Unless explicitely stated all all fields into which data has to be entered have to be cleared, i.e. the data as delivered by the switch are to be ignored.
   
• Ignore the unhelpul "Empty value is invalid." messages and continue processing, just click again.

Now that you know the Ministry's rules let's start the silly walk  by selecting the inactive certificate slot and clicking "Import Certificate..." - never close the popup until the whole silly walk is done and, well, yes, the road to success if full of failures:

• Try to import certificate, public key and private key. This will fail with:
  Failed to load public key
  
  
• Try to import only the certificate, leave the "Import RSA Key-Pair"  unchecked. This will then fail with:
  SSL saved private key did not match the imported certificate.
   
• Try to import certificate and private key, do not touch the presented public key. This results in:
  Success.

Now that you have passed all the tests for your capabilities of being a proud member of the Ministry of Silly Walks you can close the popup and enjoy your shiny new certificate.

It is not so nice when developers don't have any clue about security and thus constantly shift responsibility to another project. This results in insecure systems with virtually no one responsible. Somebody who can file CVEs should look at this and get into action. A few not so nice examples:

• When using fscrypt to secure a home directory a user expects the directory to be unlocked (done via pam_fscrypt) at login and to be locked at logout. Well, pam_fscrypt tries to lock but has to fail miserably.
  
  The reason for this is the default setup of systemd-logind to not kill user session processes at logout time. So a bunch of processes including keyring stuff and, if started via systemd --user, ssh-agent with valid and accessible keys keeps hanging around.
  
  As a result files in the home directory are in use and pam_fscrypt can't lock the home directory. And even if systemd-logind is configured to kill the user session processes this happens a variable amount of seconds after logout, so still no joy.
  
  One has to go through hoops and start a script as root that attempts to lock the home directory for multiple seconds - success not guaranteed.
   
• As stated before process kill and directory lock takes multiple seconds after logout. So, if a user changes settings that require re-login to be applied, user logs out and instantly logs in again. Result is a "ploink" sound and either a KDE wheels or a blank screen with no way to go backward or forward. If the user is able to switch to a console and has the permission to restart sddm from there the user can resurrect the system, the other options are 'call and wait for administrator' or 'unplug system mains'.
   
• Now, if the home directory is not encrypted, ssh-agent is in use and systemd-logind is used in the default configuration, things tend to be equally bad. The friendly Mallory working at the next table spies the login passphrase. After his victim logs out Mallory just needs to log in to be able to use all activated ssh keys of his victim, thanks to the ignorance of KDE and systemd developers. I beg to question if those developers use putty on this OS from Redmond when they need ssh access?
   
• Somebody should look at the keyring stuff that is left running in the default configuration. I'm too disgusted already to continue digging in this mess.
   
• Now for the easy part: to prevent access to system control functionality like poweroff one has to create Polkit rules - KDE developers just shift responsibility and be done with. When it comes then to "Restart" one has to find out by trial and error what has to be disabled via Polkit to make "Restart" to disappear - documentation is, well, sparse. And as this wasn't ugly enough there's no way to hide the "Switch User" button except for editing "~/.config/kdeglobals" and adding a section which is best documented in mailing list archives. To remove unwanted buttons from the login screen one has to then edit the proper sddm theme file, there's no other way.
   
• If one is not frustrated enough then here we go again: KDE developers seem to know only about passwords when it comes to the screensaver. If one is smart enough to be able to use a passwordless unlock functionality the screensaver greets the unexpecting user with an "Unlock" button probably designed to wear out the keyboard. This is a productivity hindrance par excellence and can only be resolved by patching the LockScreenUi.qml file. It turns out that someone out of their mind have decided to pop up this nonsense if the passphrase line was not displayed at unlock time. Arrrgh...
   
• And there's pam_systemd which is active in distros e.g. for ssh access which starts stuff but never terminates on logout...

For all those who depend on privacy this site is accessible with Tor Browser using the following URL:

http://2tk3jwrferu37blz6g6oq7r3gcnbxgvi7tnddxblobywpbkkp2q3fvqd.onion/

...there's no intelligent life down in Redmond. This is especially true since Poettering moved there. How the f**k can one design a 'systemd and udev' trash that first renames ethernet interfaces to illegible gibberish and then make this waste of time and money rename the interface if a PCIE card (no network) is inserted or removed? I just get inspired by Edgar Alan Poe (Lyrics by Alan Parsons):

By the last breath of the cold winds that blow
I'll have revenge upon Fortunato
Smile in his face I'll say "Come let us go
I've a cask of Amontillado"

Sheltered inside from the cold of the snow
Follow me now to the vaults down below
...

Replace Fortunato with Poettering and the cask of Amontillado with any torture object of your choice and you'll get the idea. But well, he made his statement in modifying a stable system environment to become more like the unstable Redmond insanity. Disgusting.

Als Kurzfassung:

Raspberrymatic (3.67.10 oder neuer) installieren. System ganz normal konfigurieren (Netzwerk, LEDs, SSH), einen Sicherheitsschlüssel vergeben, dann die Board-Seriennummer mit "cat /var/board_serial" auslesen und mit "touch /usr/local/HMLGW" vorbereiten.

Raspberrymatic rebooten, läuft jetzt als LAN-Gateway. Zum Beenden des LAN-Gateway Modus per ssh "rm /usr/local/HMLGW" und dann rebooten.

Auf der CCU ein neues Homematic RF Gateway anlegen, Seriennummer ist die Board-Seriennummer, Zugriffscode ist der Sicherheitsschlüssel und die IP-Adresse die konfigurierte IP.

Der proprietäre Code auf der CCU macht Probleme, wenn ein LAN-Gateway beim Neustart nicht erreichbar ist. In diesem Fall sicherstellen, dass das LAN-Gateway im Netz von der CCU aus erreichbar ist (ping) und dann CCU Neustart.

Ich hatte Probleme mit der Raspberrymatic Version 3.69.7, mit 3.67.10 ging es dann. Ein Fix ist in Arbeit, der Nightly Build vom 30.6.2023 funktioniert bereits.

Ich verwende Raspberrymatic auf einem Pi 3B. Das Blinken der Ethernet LEDs ist dann des Nachts störend. Laut dieser Anleitung sollte das durch Ergänzung von /boot/config.txt so gehen:

Pi 3B:

# Turn off Ethernet ACT LED
dtparam=eth_led0=14
# Turn off Ethernet LNK LED
dtparam=eth_led1=14

Pi 4B:

# Turn off Ethernet ACT LED
dtparam=eth_led0=4
# Turn off Ethernet LNK LED
dtparam=eth_led1=4

Das funktioniert möglicherweise auch bei einem Pi 3B+, aber nicht bei einem Pi 3B. Für dieses Modell bedarf es eines Tools namens "llctl". Die Quellen dafür sind hier und ein vorcompiliertes Binary hier zu finden. Falls diese Originale nicht mehr zur Verfügung stehen sollten, habe ich eine lokale Kopie.

Homematic nutzt ausschließlich 868,3 MHz. Homematic IP dagegen nutzt 868,3 MHz und 869,525 MHz. Dabei findet die normale Datenkommunikation sowohl bei Homematic als auch Homematic IP auf 868,3 MHz statt. 869,525 MHz wird ausschließlich für Wake on Radio verwendet.

Die Logik dahinter ist simpel. Für 868,3 MHz gilt ein Duty Cycle von 1%, d.h. ein Gerät darf maximal 36 Sekunden je Stunde senden. Nun dauert eine Wake on Radio Preambel allerdings 360 Millisekunden, d.h. nach 100 solcher Preambeln ist auf 868,3 MHz bereits ein Duty Cycle von 100% erreicht. Deswegen dann bei Homematic IP das Aussenden dieser Preambeln auf 869,525 MHz, denn auf dieser Frequenz gilt ein Duty Cycle von 10%, d.h. ein Gerät darf maximal 360 Sekunden je Stunde senden.

Eine normale Preambel mit Syncwort dagegen dauert ab etwa 6,4 Millisekunden. Dazu kommen dann noch die eigentlichen Daten, diese dauern zwischen 10 bis 24 Millisekunden bei Homematic und 10 bis 51 Millisekunden bei Homematic IP.

Batteriebetriebene Homematic IP Geräte mit Wake on Radio schalten also ihre Empfangsfrequenz auf 869,525 MHz für Wake on Radio, wenn sie im Energiesparmodus sind. Da allerdings der Sender nicht wissen kann, ob der Empfänger im Energiesparmodus ist, wird erst einmal ein Telegramm mit Wake On Radio Preambel auf 869,525 MHz gesendet und danach noch einmal das selbe Telegramn mit normaler Preambel auf 868,3 MHz.

Und deswegen kann es bei klassischer Homematic zum Duty Cycle Problem kommen, wenn etwa via Skript Wake on Radio ausgelöst wird. Nur ein paar Geräteabfragen und der Duty Cycle geht durch die Decke. Kann auch passieren, wenn man zu viele Geräte, die Wake on Radio beherrschen, direkt nacheinander konfiguriert. Ach ja, Geräte mit Wake on Radio sind die, die mit Batteriebetrieb arbeiten, aber z.B. für die Übernahme von Konfigurationsdaten keinen Tastendruck benötigen.

Es kann aber auch ohne Duty Cycle Problem dazu kommen, dass keine Homematic IP Kommunikation mehr stattfindet. Denn für Homematic IP gilt das Prinzip "listen before talk", d.h. vor dem Senden wird geprüft, ob die Frequenz auch frei ist. Sendet dann ein Störer dauerhaft auf 868,3 MHz, ist die Kommunikation von Homematic IP vollständig unterbunden. Für auch nur im mindesten sicherheitsrelevante Anwendungen gilt daher, niemals Homematic IP zu verwenden. Homematic dagegen sendet einfach, ob die Frequenz nun belegt ist, oder nicht. Daher ist es für Homematic IP wichtig, die Carrier Sense Werte im Blick zu behalten. Werte bis etwa 3% sind tolerabel, bei höheren Werten sollte man den Verursacher suchen.

Und nun ein kleines, aber feines Problem mit dem EQ3-RFA, dem ELV Funk-Analyzer für Homematic und Homematic IP. Dieser beherrscht nämlich nur 868,3 MHz. Für Homematic ausreichend. Ebenso für Homematic IP Geräte ohne Wake on Radio. Und was, wenn Wake on Radio nicht funktioniert, weil es einen Störer auf 869,525 MHz gibt? Nun, dann muss man zu regulären Messmitteln greifen, da einen dieses Gerät hier absolut im Dunkeln tappen lässt...

Das gilt vermutlich auch für die Duty Cyle und Carrier Sense Anzeigen bezüglich Homematic IP der CCU (z.B. Raspberrymatic) und der LAN Router (HmIP-HAP) in der CCU. Da hier keine zwei Frequenzbänder angezeigt werden, wird die Frequenz von 869,525 MHz wohl geflissentlich ignoriert. Wohl gemerkt, hier kann der Open Source Teil, also z.B. der Raspberrymatic Entwickler, nichts dafür. Die Daten müssten von den EQ3 Funkmodulen entsprechend bereit gestellt werden bzw. die Bereitstellung von EQ3 entsprechend dokumentiert werden. Möglicherweise wird der Duty Cycle von den Funkmodulen auch aggregiert und der jeweils höhere Wert für die beiden Frequenzen zurückgegeben, Dokumentation dazu kenne ich keine. Und für Carrier Sense wäre dies dann völliger Unfug.

Was fehlt, ist ein bezahlbares und einfach zu bedienendes Messgerät, welches eben nicht nur auf 868,3 MHz sondern auch auf 869,525 MHz arbeitet - für 869,525 MHz wäre sogar erst einmal eine Pegelanzeige ausreichend, um potentielle Störer finden zu können. Wer sich quälen will oder muss, kann es mit GQRX und einem RTL-SDR Stick versuchen - die Qual besteht dabei aus der Software Installation und Konfiguration. Ein RTL-SDR Stick mit SMA Buchse und ein nanoCUL USB Stick mit Firmware für den AskSin Analyser XS kosten zusammen in etwa auch so viel wie der EQ3-RFA und bieten deutlich bessere Analysemöglichkeiten - allerdings ist ein Laptop dann Pflicht.

Externe Antenne für die CCU zur Verbesserung der Funkreichweite

Das Funkmodul der CCU des Homematic Systems, egal ob CCU3 oder z.B. RPI-RF-MOD, hat eine kurze Drahtantenne, die nicht unbedingt für überwältigende Sende- und Empfangsqualität sorgt. Die übliche Vorgehensweise ist dann, die Antenne durch einen Pigtail mit SMA-Buchse zu ersetzen und an diese Buchse eine Stabantenne für 868 MHz anzuschließen. Das Ergebnis lässt allerdings oft zu wünschen übrig.

Ursache dafür ist, dass es sich bei einer Stabantenne, soweit nicht explizit anders spezifiziert, um einen Monopol handelt. Dieser ist, vereinfacht ausgedrückt, nur eine Hälfte der eigentlichen Antenne, die Massefläche der Platine(n) ist dann die andere Hälfte. Für 868 Mhz ist aber die benötigte Platinenfläche bei allen CCU Ausführungen zu klein. Das Ergebnis ist, dass die externe Antenne verstimmt wird, d.h. aus einer 868 MHz Antenne wird dann z.B. eine 920 MHz Antenne. Dass das dann zu keinem guten Ergebnis führt, dürfte jetzt jedem klar werden.

Für die meisten Installationen kommt dann nur eine Dipol-Antenne in Frage. Der Selbstbau mit zwei Stücken Draht in passender Länge führt allerdings auch nicht zum Erfolg, da sowohl die Impedanz der Antenne nicht stimmt, als auch ein Balun fehlt, d.h. eine Hälfte des Dipols ist dann nichts weiter als eine Erweiterung der Massefläche der Platine und die andere ein Monopol. Einen "vollständigen" echten Dipol kann man zwar selber bauen, man sollte dafür aber fundierte HF-Kenntnisse und entsprechende Messgeräte haben. Damit bin ich, wie wohl auch die meisten Homematic Nutzer, außen vor.

Es gibt nun aber fertige und bezahlbare Dipol-Antennen mit korrekter Impedanz und Balun. Eine solche Antenne ist dann unabhängig von der Massefläche der Platine und kann somit auch nicht verstimmt werden. Diese Antennen findet man allerdings nicht bei den üblichen und schlecht sortierten Händlern, sondern bei gut sortierten Elektronik Distributoren. Ein Beispiel für einen solchen Distributor, der auch an Privatkunden liefert, ist DigiKey. Dort kann man nach "ANT-868-CW-HWR-SMA" oder "ANT-868-MHW-SMA-S" suchen. Während erstere wie ein normaler Stab-Monopol aussieht, sieht letztere wie ein üblicher Dipol aus. Es sind aber beides Dipol-Antennen mit Balun und passender Impedanz (siehe Datenblatt). Mit solchen Antennen wird es dann auch etwas bezüglich besserer CCU Kommunikationsreichweite. Das gleiche gilt natürlich auch für den nanoCUL USB Stick mit Firmware für den AskSin Analyser XS. Der Empfang verbessert sich hier bei Ersatz der mitgelieferten Antenne gegen eine "ANT-868-CW-HWR-SMA" erheblich.

Zu beachten ist allerdings, dass ein Dipol gegenüber einem Monopol eine andere Wellenausbreitungscharakteristik hat. Bei einer Dipol-Antenne kann man sich das so vorstellen: man stellt den Dipol vertikal auf und steckt diesen durch das Loch eines Donuts. Das enspricht ganz gut dem Bild der Wellenausbreitungscharakteristik eines Dipols. Für einen Monopol muss man dann den Donut mittig horizontal durchschneiden und die untere Hälfte entsorgen. Steckt man dann den verikal aufgestellten Monopol durch das Loch der oberen Hälfte (die Schnittfläche des Donuts entspricht dann dem Erdboden) des Donuts, so entspricht dies ganz gut dem Bild der Wellenausbreitungscharakteristik eines Monopols. Demensprechend muss dann natürlich die Antenne positioniert werden (Versuch macht klug).

Erwähnt sei noch, dass es natürlich auch noch andere brauchbare Antennenformen gibt. Ich persönlich enpfinde aber z.B. eine Ground Plane Antenne wie die "Aurel GP 868" als ungeeignet für die Montage in einer Wohnung. Abgesehen davon ist diese Antenne derzeit scheinbar auch nicht erhältlich.

RSSI Verwirrung

Die Homematic bzw. Raspberrymatic RSSI Anzeige führt regelmäßig zur Verwirrung, da je Gerät ein oder zwei Werte angezeigt werden und manche Werte (<=-128) eigentlich unsinnig sind.

Zuerst einmal: RSSI ist immer ein relativer Empfangswert und keine absolute Angabe wie ein Wert in dBm, man kann den Wert mit der Balkenanzeige der Verbindungsqualität eines Handys vergleichen. Weiterhin gilt, dass ein größerer Wert besseren Empfang bedeutet, z.B. entspricht -30 gutem Empfang und -90 schlechtem Empfang.

Nun zu den zwei Spalten je Gerät, die via Devconfig und RSSI List angezeigt werden. In den Spalten für einen Aktor bzw. Sensor zeigt die linke Spalte den RSSI Wert für Kommunikation, die von der CCU initiiert wird, z.B. eine Statusabfrage. Die rechte Spalte zeigt dagegen den RSSI Wert für eine Kommunikation, die vom Aktor bzw. Sensor initiiert wird, z.B. einen Tastendruck.

Bei den Zeilen für die CCU bzw. der LAN Adapter ist dies nun genau anders herum, d.h. die linke Spalte zeigt den RSSI Wert für vom Aktor bzw. Sensor initiierte Kommunikation, die rechte den RSSI Wert für die von der CCU iniitierte Kommunikation.

In den Geräteeinstellungen der Raspberrymatic entspricht dann der Wert für den Pfeil nach unten dem RSSI Wert für von der CCU initiierte Kommunikation und der Wert für den Pfeil nach oben dem RSSI Wert für vom Aktor bzw. Sensor initiierte Kommunikation.

Es gibt also, wie man sieht, je nach Initiator der Kommunikation einen RSSI Wert.

Nun gibt es aber Werte <= -128, die scheinbar völlig unsinnig sind. Diese Werte werden angezeigt, wenn eine Kommunikation in eine Richtung zwar iniitiert werden kann, dies aber seit dem letzten Neustart der Homematic bzw. Raspberrymatic nicht erfolgt ist (z.B. noch kein Tastendruck am Aktor). Die angezeigten Werte entsprechen dann dem letzten bekannten RSSI Wert vor dem Neustart minus 128, wobei ich vermute, dass genau -128 bedeutet, dass es keinen solchen Wert gibt.

HmIP-HAP als LAN Router zur Verlängerung der Funkreichweite

Grundvoraussetzung ist hier eine CCU3 oder eine Selbstbau-CCU, die das "RPI-RF-MOD" Funkmodul verwendet, da nur dieses die benötigte Funktionalität für die HAP-Anbindung als LAN-Router bereitstellt. Nach derzeitigem Wissensstand sind maximal zwei HmIP-HAP je CCU möglich, was sich angeblich zukünftig auf acht Geräte ändern soll.

Wichtig: Ab Version 3.69.6 der Homematic bzw. der Raspberrymatic gibt es die Schaltfäche "Access Points mit inkompatibler FW" in der Systemsteuerung nicht mehr. Der HmIP-HAP wird jetzt wie jedes andere HmIP Gerät an der CCU angelernt. Für ältere CCU Firmware kann man gemäß dieser Anleitung vorgehen.

Will man dem HmIP-HAP eine feste IP-Adresse zuordnen, so kann dies mit dem NetFinder von EQ-3 (Version 1.3.0) erfolgen. Dieser funktioniert allerdings scheinbar nicht mit den neuesten Java-Versionen, es sollte Version 7 bzw. 8 oder OpenJDK 1.7 bzw. 1.8 verwendet werden. Das zur Änderung benötigte Kennwort ist auf der Rückseite des HmIP-HAP aufgedruckt.

Hat man im Homematic Netzwerk keinen DHCP Server laufen, so ist es nicht unbedingt notwendig, für die Installation des HmIP-HAP "Klimmzüge" durchzuführen, man kann auch kurzfristig einen DHCP Server auf der CCU starten. Dazu besorgt man sich ein "busybox static" Debian Paket (.deb) für aarch64, packt dieses mit "ar xv" unter Linux aus und hat dann das Archiv "data.tar.gz", dass man mit "tar xf" entpacken kann. Das darin enthaltene "busybox" Binary als auch die Datei "udhcpd.conf" auf die CCU in das Verzeichnis "/tmp" kopieren, "udhcpd.conf" editieren und die Konfiguration für das lokale Netz und die Aufführung in "/tmp" anpassen und dann den DHCP Server mit "/tmp/busybox udhcpd -I <CCU-IP> /tmp/udhcpd.conf" starten.

Anmerken möchte ich noch, dass es natürlich auch noch das "Homematic Funk-LAN Gateway HM-LGW-O-TW-W-EU" gibt. Dieses ist allerdings nur für die älteren Homematic-Komponenten (nicht HmIP) geeignet und somit nur für Bestandsinstallationen interessant. Auch hier gilt, dass zur Konfiguration der NetFinder von EQ-3 (s.o.) verwendet werden kann.

Schließlich noch zu den wirren Aussagen, dass das Anlernen via "Managed Switch" nicht funktioniert, veraltetes Broadcast verwendet wird und ähnlichen Unwissenheiten. Tatsächlich benutzen die Homematic Geräte im Netzwerk IPv4 Multicast. Bei einem "Managed Switch" bedarf es dann einem korrekt konfigurierten und aktivierten IGMP Querier, damit die Multicasts an den Switch Ports, an denen sie benötigt werden, auch korrekt "freigeschalten" sind (man kann dafür statt eines Queriers auf dem Switch auch z.B. "xorp" unter Linux einsetzen). Alternativ kann man als Notlösung auch das Multicast-Filtering an den Switch Ports der Homematic Komponenten abschalten. Bei Einsatz eines "Managed Switch" sollte man eben mehr Netzwerkkenntnisse als "Stecker in Buchse" haben, damit das Netzwerk dann auch wie gewünscht funktioniert.

Why isn't there any switch manufacturer that completely fills the huge gap between unmanaged aka dumb switches for, well, similar users and multi billion big business devices? Why are there so many "managed" switches for sale with virtually no IPv6 support? Why some manufacturers sell switches with "Windows only" configuration tools?

There is for sure demand for semi-professional devices for home use that are not constructed of hardware that was designed 10+ years ago. Think power users, think extended home office. A 10GBit home backbone with at least some NBase-T ports and some 10GBit ports not allocated for the backbone would be nice. Switches located close together should be interconnected by SFP+ DAC cables, whereas remote (a.k.a. other room) switches should be interconnected by 10GBase-T if the existing wiring allows for it, otherwise via NBase-T. This results in the following wish list:

• Preferably NBase-T, at least 2.5G, supporting 10/100/1000/2500(/5000), with POE+ support
• Either 10GBase-T or SFP+, preferably combo port(s), at least two ports
• Standard ports (10/100/1000) with POE+ support, can be substituted by 10/100/1000/2500 POE+ ports
• Fanless, absolutely mandatory
• Software allows port LEDs to be disabled, absolutely mandatory, no nightly light show
• Managed with complete dual stack, no crippled IPv4 only management
• Web GUI as an alternative to command line (if you don't configure switches on a daily base CLI configuration is cumbersome)
• Stacking would be nice as no fan typically implies multiple units
• Affordable, i.e. in the 3 digit € range per unit

The only switches I could find that do mostly fit the the above list are from Cisco:

• CBS250-24P-4X (24x GBit, no NBase-T, 4x SFP+, usable as a central distribution unit on a home backbone)
• CBS350-24P-4X (24x GBit, no NBase-T, 4x SFP+, usable as a central distribution unit on a home backbone)
• CBS350-8MGP-2X (6x Gbit, 2x NBase-T 2.5G, 2x 10G combo ports, no stacking)

As for stacking even as Cisco advertises "Hybrid Stacking" between CBS350-24P-4X and CBS350-8MGP-2X online there seems to be no way (at least in the Web GUI) to configure any kind of stacking on the CBS350-8MGP-2X.

If one then looks for POE PD powered switches without a nightly light show there is actually only a single device, again from Cisco:

• CBS250-8T-D (10/100/1000 only, no POE passthrough)

I couldn't find any POE PD powered device with POE passthrough with an option to switch off the port LEDs. The same goes for IPv6 support (most devices sold) as well as a POE PD powered NBase-T port (all devices I could find). Is this so impossible to implement?

And yes, being able to switch off the port LEDs is the actual "killer application" for home (office) use. Most people don't have a dedicated network closet in their home (though this may have changed in about 100 years). A nightly light show in bright green, yellow and orange (possibly accompanied by a stylish and bright blue or white power indicatior) from inside the office, in the living room or even better in the bedroom is not to everybodys taste. And though one can usually tape a power LED easily this is typically not so simple with port LEDs - the fun then begins when one needs the port LEDs for those five minutes once a year...

For the same reasons fanless devices are required, except for those who prefer a running lawn mower at night in their bedroom...

I do really wonder how many decades it will take for switch manufacturers to  accept that 10/100/1000/2500 is the new minimum standard, 5000 is a plus value and 10000 is the power user (and not a $$$ premium) version. When will switch manufacturers accept the fact that a dedicated network closet is not the rule but the exception in most facilities (a.k.a homes)? Instead I do actually see 10/100 desktop devices still being sold which does give me the creeps. The same goes for the 10MBit requirement - but unfortunately there are still such devices out there that one may need to connect to a switch port.

And well, as for the above mentioned Cisco switches, if one does find a bug one may keep it. No $$$ service contract, no bug report, it's as simple as that. One can only hope that a bug also affects a user with a service contract...

That all seems to suggest that the management decisions of switch manufacturers are made by persons that mentally live at least 10 years in the past. I just can't see any other reason.

Der Aschram des ehemaligen Guru und jetzigen Zombie Aiwanger mit seinen freidrehenden Wählern hat dank der der globulisierenden Wirkung des heilenden Odeldufts die bundesweite Inzidenzkrone mit einem Wert von über 3500 erobert. Gratulation zu diesem Erfolg.

Dazu auch noch Glückwünsche an Markus Söder für seine wahltaktischen Lockerungsbemühungen, die diesen Erfolg erst so richtig ermöglicht haben.

Bayern ist endlich wieder bundesweite Spitze - bezüglich der Infizierten. Da kann der Söder doch gleich mit Ursula von der Leyen kuscheln und weitere wahlkampftaktische Lockerungen einführen. Die blöden Wahlsklaven sind doch sowas von unwichtig...

Derweil  hat Frankreich die Marke von 20 Millionen Infizierten gerissen und Deutschland ist mit 11 Millionen ganz gut dabei.

Die Anzahl der Infizierten in der EU hat die 900000 überschritten. Die Anzahl der Toten nähert sich kontinuierlich der Marke von einer Million, es fehlen nur noch etwa 38000. Gratulation an Ursula von der Leyen und Thierry Breton zu diesem Erfolg.

Derweil wurde in Deutschland die Marke von 10000000 Infizierten geknackt und Italien fehlen nur noch 10000 Tote, um Großbritannien einzuholen.

Nur ein bedauerlicher Einzelfall...

Ja, eine Luftnummer, genauergesagt eine Nullnummer. Wie wäre es denn, wenn die Regierenden generell den ICE nehmen müssten? Dann würde vielleicht dafür gesorgt werden, dass die Bahn irgendwann einmal funktioniert.

Wer nicht regieren kann, muss zumindest Partys feiern können...