multicast routing with pimd – a story of ups and downs with examples

By default, multicast traffic is not routed for good reason. Usually one wants to keep this traffic in it’s own network. This is the first important lesson. Nearly all multicast generating software is setting by default a max-hop-counter (time to live) on packages of 1 (the IP TTL field). This counter is decreased by every router by 1 on the way from sender to recipient. The counter is to avoid loops / forever looping packages in network. With a TTL of 1, the package is dropped on the first router.

$ ping 
PING ( 56(84) Bytes Daten. 
64 Bytes von icmp_seq=1 ttl=113 Zeit=28.3 ms 

See? The ping has a TTL of 113 set. So the icmp package can be forwarded by 112 routers until it gets dropped. We have to keep that in mind so that our multicast traffic does not get dropped.


Multicast is a fairly simple mechanism to communicate with a group of receivers. A sender sends out traffic to a group and all group members receive the same data. Multicast is a uni-directional (one-way!) communication. This is the next important lesson. That means, that it relies on a protocol that does not require session initiation. Hence multicast only works with UDP-traffic and – as stated – only in one-way.

One-way means for example, a sender streams a video-signal to a group of receivers. Or a sender sends out a chat message to a group. No acknowledgment of data by receivers, no answer, no re-sending of missed/lost packages. No fancy TCP features at all if multicast is used.

Group-Management with IGMP explained

Joining or leaving a group is something an application does automatically or can be achieved manually for testing purpose. Technically, joining/leaving a group is – from a client perspective – just accepting packages from this moment on, that have the multicast destination-address set. But as others need to know, that we’ve joined/left a multicast group or would like to get traffic at all, a protocol is required. The protocol that does the whole „group management“ (announcing groups, joining groups, leaving groups) is called IGMP (internet group management protocol). A better word would be membership information and management protocol – but what do i know? There is IGMPv1-v3 but lets keep it simple.

The protocol is basically used for 3 tasks:

  • Announce an available group to others in the local network „This is group – who wanna join!!?!?!“
  • Inform others about joining a specific group „I’m now part of group that will be awesome!“
  • Inform others about leaving a group „Im out of this group, it sucks“

Lets catch some fancy IGMPv3 packages with tcpdump to show it in detail:

Joining the group with a linux box and what tcpdump shows:

ip addr add dev wlp3s0 autojoin
21:19:44.976186 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) > igmp v3 report, 1 group record(s) [gaddr to_ex, 0 source(s)]

Leaving the same group right after:

ip addr del dev wlp3s0 autojoin
20:08.996151 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) > igmp v3 report, 1 group record(s) [gaddr to_in, 0 source(s)]

Note the gaddr in the message we are interested in and the to_ex and to_in.

gaddr is just the group, we are interested in/reporting for.

One could think of, that if a group is joined, it should be IN and on leave, it should be EX, but keep in mind, that these IGMP-messages are just REPORTS of the devices, that join or leave a group on it’s own and just inform the network about the local change. So the first message reports, that the client is not to exclude from the group (meaning it is in now).

The leave-report means, the same client is not included anymore (meaning it left the group) in the group

Now one or many clients can form a multicast-group just by opting-in/out the group as stated above.

A sender that wants to send traffic to the group afterwards, just sends UDP-traffic to the group-IP.

This is all working fine in local network. For routing multicast traffic between networks that are not connected directly (no layer 2 connection) you need at least a router in each network with pimd installed.

So what about routing and how does pimd work?

pimd operates in 3 steps:

1, pimd is setup on the routers that have 2 or more interfaces and listens for IGMP-reports all the time. pimd learns all groups in each networks and it’s associated members.

2, without further configuration, pimd „detects“ other pimd-routers and all of them elect a primary router. The detection just happens by listening to IGMP-reports on foreign networks as well. This primary router (called RP – Rendezvous Point) will receive from now on all multicast-traffic from all other pimd’s. This is called rendezvous point, as all multicast traffic will come here together.

3, each pimd is sending all multicast-traffic, that it sees in it’s own network, to the elected rendezvous point. The rendezvous point is then either routing the traffic to all recipient-pimds (all pimd’s, that have locally group members, that awaiting the multicast traffic or/and sending the traffic out of it’s own local network interface towards final destinations.

One has to keep in mind, that pimd is not using the operating systems routing table. pimd(s) building up and keep maintaining own dynamic routing tables. And, most importantly, the „routed traffic“ is encapsulated on it’s way from one pimd to the RP or othre pimds. The IP-packages that are routed from pim to pim are unicast-packages. Let me repeat this to make it clear:

pimd is encapsulating the multicast-UDP-packages in a special crafted IP-package and sends it via unicast to the RP or final recipient pimd. This IP-packages have no multicast destination IP.

Encapsulated in this IP package is the origin UDP multicast package. Last but not least.

Lessons learned

  • TTL timer must not be 1 if routing should take place
  • Keep MTU-size of UDP-segments in mind. I had to lower the MTU to 1450. With default MTU of 1500, packages got dropped on routers as the maximum segment size ist usually 1500bytes for the IP packages, so a UDP-package of 1.500 does not fit.
  • make sure, no firewall is in place or if so, is configured properly
  • make sure, all the independent networks with multicast receivers have individual networks (we had issues, having more than once)
  • Use NAT/masquerading if the same network is present more than once

Finally, some debugging hints for pimd:

Debugging pimd:

pimd -d (run in foreground-mode with debug flag)

pimd -r (shows current routing tables, learned neighbors and multicast-members in each group, as well as live join/leaves for each group)

Fanvil / 3CX – individuelle Klingeltöne

3CX selbst dient als Provisionierungssystem, wenn man über die empfohlenen Wege, Tischtelefone einbindet. Das heißt, ein Telefon frägt bei jedem Boot/Reboot, beim Provisionierungssystem die aktuelle Konfiguration an.

Das heißt – jede manuelle Änderung am Telefon selbst, über das Web-Interface oder am Display, wird u.u. von der 3CX beim nächsten Reboot überschrieben, WENN, und jetzt wird es wichtig, diese Option durch 3CX provisioniert wird. Welche Optionen provisioniert werden, lässt sich dem jeweiligen Template entnehmen. Bzw. vereinfacht, alles was sich im Provisionierungsdialog der Nebenstelle einstellen lässt pro Telefon. Siehe hierzu:

Einstellungen -> Vorlagen

Wählt man jetzt in der 3CX-Nebenstelle für das Telefon den Klingelton 3 aus, erzeugt 3CX dazu für das Telefon eine Konfigurationsdatei.

Konkret heißt das, wählt man „Ring 3“ aus, zeigt das auf eine Datei namens 3.wav. Diese liefert Fanvil selbst mit jedem Telefon aus. Diese Dateien liegen auf dem Telefon selbst und können nicht verändert werden.

Möchte man jetzt individuelle Klingeltöne, lassen sich diese am Telefon selbst, hochladen.

Hier wurde eine individuelle Datei ring1.wav hochgeladen. Achtung: Diese muss 8 oder 16K Herz haben und 8 oder 16Bit Resolution. Maximal sollte die Datei 30 Sekunden lang sein bzw. muss kleiner als 256K sein in Summe.

Jetzt muss dieser Klingelton nur noch der jeweiligen Leitung im Telefon zugewiesen werden.

Line -> SIP -> Advanced Settings -> Ring Type (rechts unten)

Wenn das geht, fehlt nur noch der letzte Step, diesen eigenen Klingelton über die 3CX-Provisionierung auswählbar zu machen, damit 3CX beim Provisionieren, nicht „drüberbügelt“.

LSI megaraid – megacli – Vergrößerung Raid nach Plattentausch

Wurde ein bestehendes Raid 1 einmal mit z.B. 2 x 250GB Platten erstellt und tauscht man jetzt nachträglich die 250GB Platten durch größere 1TB, „zaubert“ dies das Raid nicht automatisch größer.

Dies muss nachträglich vergrößert werden. Die Vergrößerung läuft dann im Hintergrund. Nachfolgend der konkrete Ablauf inkl. Übersicht.

# megacli -LDInfo -LAll -a0

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 232.375 GB
Sector Size         : 512
Is VD emulated      : Yes
Mirror Data         : 232.375 GB
State               : Optimal
Strip Size          : 64 KB
Number Of Drives    : 2
Span Depth          : 1
Default Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Enabled
Encryption Type     : None
Bad Blocks Exist: No
Is VD Cached: No

# megacli -LdExpansion -p100 -Lall -aAll
Expansion of Virtual Drive 0 on Adapter 0 Success.

# megacli -LDInfo -LAll -a0

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 931.0 GB
Sector Size         : 512
Is VD emulated      : Yes
Mirror Data         : 931.0 GB
State               : Optimal
Strip Size          : 64 KB
Number Of Drives    : 2
Span Depth          : 1
Default Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Enabled
Ongoing Progresses:
  Background Initialization: Completed 28%, Taken 15 min.
Encryption Type     : None
Bad Blocks Exist: No
Is VD Cached: No

# echo 1 > /sys/block/sda/device/rescan

[22659.422628] sd 1:2:0:0: [sda] 1952448512 512-byte logical blocks: (1000 GB/931 GiB)
[22659.422630] sd 1:2:0:0: [sda] 4096-byte physical blocks
[22659.422672] sda: detected capacity change from 249510756352 to 999653638144

parted /dev/sda resizepart 3 100%

fdisk /dev/sda
hier jetzt die letzte Partition löschen & größer anlegen - Part-Tabelle nicht anfassen.

partprobe /dev/sda

pvresize /dev/sda3

Beweisführung der Zustellung im E-Mail-Verkehr

Die Unternehmenskommunikation und Digitalisierung stellt alte Abläufe in Frage. Wird langsam aber
sicher die Briefpost mit ihren Zustellformen wie dem Einschreiben-Einwurf oder dem Einschreiben-
Rückschein durch E-Mail abgelöst, existieren längst neue Methoden zur rechtssicheren Beweisführung einer E-Mail-Zustellung für den Absender. Neben der Protokollauswertung von Mail- und Webserver-Logdateien, existieren Funktionen wie die Übermittlungs- und Lesebestätigung die auf
Knopfdruck angefordert werden können. Bei der Beweiserhebung und Konservierung gilt es, diese
bereits frühzeitig im Unternehmen zu aktivieren um im Bedarfsfall auf aussagekräftige Nachweise
zurück greifen zu können. Hierzu gehört die Aktivierung und Protokollierungen von E-Mail-
Zustellungen auf Systemebene sowie die Verwendung von geeichten Zeitservern. Aber auch der
Einsatz von digitalen Signaturen untermauert die Echtheit. Auch die Besonderheiten beim Einsatz
eines Viren- und Anti-Spam-Filters oder der automatischen Abwesenheitsnachricht im E-Mail-Verkehr
können sich positiv für den Absender auswirken. Um eine positive Würdigung der eigenen Beweise
vor Gericht zu erreichen, müssen diese nachvollziehbar und lückenlos sein und plausibel vorgetragen
werden. Die Zugangsfiktion ist ein nötiges Instrument um Sonderfälle bei der Zustellung zu
berücksichtigen und ersetzt nicht den stringenten Beweisvortrag.

Zur Arbeit:

E-Mail-Zustellung, Zugangsbeweis, SMTP, Zugangsfiktion, DSN, E-Mail-Annahme, MDN, Protokolle
E-Mail delivery, message acceptance, send mail transfer protocol, delivery status notification, DKIM
protocols, S/MIME

Betriebsurlaub vom 08.08 bis einschließlich 19.08.22

Sehr geehrte Damen und Herren,
liebe Kunden und Partner,

Im Zeitraum vom 08.08 bis einschließlich 19.08.2022 macht cubewerk Betriebsurlaub. Zusätzlich nutzen wir diesen Zeitraum, um zwei cubewerk-interne IT-Systeme zu migrieren. Falls in dieser Zeit dringende IT-Projekte oder Umstellungen bei Ihnen geplant sind, finden wir sicher eine Lösung für Sie. Rufen Sie uns dazu bitte früh genug an. Für Kunden mit gültigem Wartungsvertrag stehen wir auch innerhalb der Urlaubszeit eingeschränkt per E-Mail zur Verfügung. Aufgrund der stark reduzierten Personalstärke in der Urlaubszeit, werden Anfragen mit geringerer Priorität u.U. erst nach unserem Urlaub beantwortet.

Bitte beachten Sie, dass der letzte Termin für IT-Änderungen & Anpassungen der 03.08.22 ist. Bitte teilen Sie uns Ihre Änderungswünsche somit bis spätestens 03.08.22 mit. Änderungswünsche nach dem 03.08.22 werden erst ab dem 22.08.22 umgesetzt.

Vielen Dank für Ihr Verständnis.

CVE-2022-30190 – Was ist zu tun

gerade wurde eine kritische Sicherheitslücke¹ in Microsoft Windows/Office entdeckt. Diese führt dazu, dass bereits das Öffnen einer präparierten Office-Datei bzw. eines präparierten Links es Angreifern ermöglicht, Ihr System aus der Ferne zu übernehmen. Bitte seien Sie ganz besonders vorsichtig beim Öffnen von Links im Internet sowie bei Anhängen aus E-Mails.

Es besteht dringender Handlungsbedarf.

Um die fehleranfällige Komponente auf Ihrem Windows-PC selbst zu entschärfen, führen Sie folgenden Befehl als Administrator auf der Windows-Kommandozeile aus:

reg delete HKEY_CLASSES_ROOT\ms-msdt /f

Starten Sie anschließend den PC einmal neu.


nftables statisches Nat – DNAT

Einfaches static-NAT IP auf IP (Zieladresse wird umgeschrieben)

nft add rule nat prerouting ip daddr dnat

Paket mit Ziel-IP wird durch das verarbeitende System (Router) auf die Ziel-IP übersetzt. (DST-IP im IP-Header wird geändert). Das ganze passiert in der PRE-Routing Tabelle des Kernels, da es VOR (pre) dem eigentlichen Routing passieren muss. Würde es danach erst passieren, wäre die Entscheidung ja schon gefallen, welchen Weg das Paket nimmt. Da das routing aber abhängig vom Ziel ist, muss die Änderung der Zieladresse VORHER (pre) passieren.

Regeln anzeigen lassen:

nft -a list table nat

Regel löschen:

nft delete rule nat prerouting handle 8

Hinweis: handle steht jeweils in obiger Ausgabe am Ende jeder Regel

Yubikey 5NFC Zertifikat via Windows CA erneut ausrollen lassen

Hat man das auto-enrollment konfiguriert und möchte nachträglich das Zertifikat auf dem Stick erneut generieren, lässt sich dies manuell auf einem Windows-System anstoßen.

Voraussetzung ist, dass in der Windows-CA, das Zertifikat des Users revoked wurde.

Jetzt als jeweiliger User, welcher für sich ein Zertifikat auf seinem Key speichern möchte, an der Windows-Domäne anmelden.

Erscheint rechts unten kein Zertifikats-Enrollment-Aufforderungsdialog (geiles Wort), kann dies manuell angefordert werden.

mmc.exe -> Zertifikat auswählen bestätigen.

Rechtsklick auf Eigene Zertifikate – > Alle Aufgaben -> neues Zertifikat anfordern. Dialog wie in der Bilderstrecke folgen.

Achtung: Die YubikeyKeyTouchPolicy kann nur durch Neu-Anforderung eines Zertifikates geändert werden. Egal was in einer GPO bzw. lokalen Registry gesetzt ist, diese Einstellung 1,2,3)… greift nur einmalig beim Enrollment des Keys und kann nachträglich auch nicht ausgelesen werden.

Datev Umsatzabruf – Belege – Steuerberaterwechsel umstellen

Hatte der alte Steuerberater Zugriff über das Datev-RZ auf die eigenen Bankkontoumsätze und erfolgte hier ein Wechsel zu einem neuen Steuerberater, muss sich der neue Steuerberater ggü. der Datev einmal legitimieren um Zugriff auf die Bankauszüge zu haben.

Es gibt hier das Dokument … von Datev, welches unter Punkt 2.1 diesen Weg beschreibt.

Der Steuerberater benötigt dazu einen beliebigen Umsatz (Datum + Betrag) aus den letzten 180 Tagen zur Legitimation.

Ein bei der eigenen Hausbank erteiltes Mandat in Form des Dokumentes

„Vereinbarung über die Teilnahme am Verfahren für die Bereitstellung von Kontoauszugsinformationen zum Abruf durch Service-Rechenzentren mittels Datenfernübertragung“ muss nicht erneut erteilt werden. Diese hat weiterhin Gültigkeit. Die Hausbank liefert dadurch ja bereits in das Datev-RZ die täglichen Umsätze. Durch o.g. Dokument wird bei Datev nur die Zuordnung zum neuen Steuerberater vollzogen.

Yubikey AD-Verteilung, NewKeyTouchPolicy – ActiveDirectory Anleitung

Heutiges Projekt: Yubikey 5 NFC verteilen per Auto-Enrollment für 2FA als Anmeldung an Windows 10 PRO und IPSec VPN-Verbindungen.

NewKeyTouchPolicy kann per GPO verteilt werden. Wissenswert ist, dass sich dies nachdem einmal ein Schlüssel verteilt wurde, nicht mehr ändern lässt. Der Schlüssel muss auf dem Stick manuell entfernt werdne mit ykman.

Gerne unterstützen wir Sie beim Rollout der Yubikey-Sticks in Ihrer Umgebung. Rufen Sie uns an.