Daan van Gorkum

Bridging a Cloud Condo Intercom to Home Assistant with Rust, SIP, and MQTT

2026-10-17T00:00:00Z

In a well-tuned smart home, almost every physical interaction is programmable. Lighting scenes adapt to the time of day, climate control reacts to occupancy, and alerts route cleanly through a single dashboard in Home Assistant.

Yet in many modern condominiums in Singapore, one piece of hardware stubbornly resists integration: the building intercom.

Instead of exposing a standard local LAN doorphone inside the apartment, many residential developments route their lobby call panels through cloud-managed property management apps—such as iPlus Living backed by a Fermax MeetMe SIP infrastructure. When a visitor or delivery driver dials your unit from the lobby or side gate, your phone receives a push notification from a proprietary app, you wait for the app to cold-start and negotiate a video stream, and you tap an icon to buzz the gate open.

From a home automation perspective, this is a dead end:

Siloed notifications: You cannot route doorbell events or camera snapshots into Home Assistant notifications, wall tablets, or TVs.
No programmable access: You cannot trigger an unlock from a Home Assistant dashboard, an NFC tag, or a temporary "delivery window" automation.
Single-platform lock-in: Everything depends on a mobile app staying logged in and surviving aggressive mobile OS background battery killers.

I wanted the condo intercom to behave like any other native device in my cluster. So I built iplusliving2mqtt—a self-contained Rust daemon running in Kubernetes that bridges the entire intercom lifecycle into Home Assistant via MQTT Auto-Discovery.

Why Standard SIP Clients Don't Work

At first glance, a SIP-based intercom sounds trivial: grab the SIP credentials, point baresip, Asterisk, or Home Assistant's VoIP integration at the server, and wait for an incoming INVITE.

In practice, inspecting the protocol flow revealed three layers that prevent a standard SIP client from ever receiving a call:

1. Split-Key Encrypted Provisioning API

Rather than giving residents static SIP credentials, the iPlus Living mobile app dynamically provisions them after login. Every HTTP request and response body is encrypted with AES-256-CBC using a fixed initialization vector, while the 32-byte AES key is hidden inside a 42-byte random alphanumeric prefix prepended to the base64 ciphertext (payload[:16] + payload[22:38]).

Authenticating through the four-step login sequence (user/login → user/logindetail → intercom/meetmelicencedetails → intercom/intercomconfiguration) returns:

Cloud MeetMe SIP credentials (sip.fermax.com)
Building PBX SIP credentials (the development's Grandstream server)
The call panel directory (mapping numeric SIP caller IDs like 14 or 22 to human-readable gate and lobby names)

2. The Push Notification Catch-22 (RFC 8599)

Even with valid SIP credentials and an active TLS connection to Fermax's Flexisip proxy (_sips._tcp.sip.fermax.com), a standard SIP client will sit idle forever when someone presses the doorbell.

Why? Because the Flexisip server is configured for mobile push notifications under RFC 8599 with pn-timeout=0:

Contact: <sip:USER@IP:PORT;pn-prid=FCM_TOKEN;pn-provider=fcm;pn-param=SENDER_ID;pn-silent=1;pn-timeout=0;transport=tls>

With pn-timeout=0, the SIP proxy assumes mobile clients go to sleep immediately after registering. When the lobby panel places a call:

Flexisip pauses the incoming INVITE transaction.
It dispatches a high-priority data push (title: "IC_CALL") through Google Firebase Cloud Messaging (FCM) to the pn-prid token registered in the Contact header.
It waits for the client to wake up and send a fresh SIP REGISTER over TLS.
Only after receiving that REGISTER does Flexisip release the held INVITE to the client.

Without a real FCM token and a persistent listener on Google's Mobile Connection Server (mtalk.google.com:5228), the SIP server never forwards the call.

3. Early-Media H.264 Video & Dual-Mode DTMF

Once the INVITE arrives, the lobby panel streams H.264 video during early media (183 Session Progress) before the call is answered. However, the door relay controller ignores unlock commands during early media—to actually buzz the gate open, the client must transition the call to answered (200 OK with SDP), wait for the ACK, and transmit DTMF unlock tones before hanging up (BYE).

System Architecture

To make this rock-solid in Kubernetes without relying on external headless Android emulators, ffmpeg subprocesses, or Python scripts, I built iplusliving2mqtt as a single static Rust binary:

  ┌──────────────────────────┐        ┌──────────────────────────┐
  │    iPlus Living API      │        │   Google FCM / MCS       │
  │  (AES-256-CBC Provision) │        │ (mtalk.google.com:5228)  │
  └────────────┬─────────────┘        └────────────┬─────────────┘
               │ 1. Fetch SIP + Panels             │ 2. Push "IC_CALL"
               ▼                                   ▼
  ┌──────────────────────────────────────────────────────────────┐
  │                      iplusliving2mqtt                        │
  │                                                              │
  │  ┌──────────────────────┐         ┌───────────────────────┐  │
  │  │  Provisioning State  │         │  Native FCM Listener  │  │
  │  │     (state.json)     │         │  (Protobuf over TLS)  │  │
  │  └──────────┬───────────┘         └───────────┬───────────┘  │
  │             │                                 │ Wake Signal  │
  │             ▼                                 ▼              │
  │  ┌────────────────────────────────────────────────────────┐  │
  │  │            Dual-Account SIP/TLS Engine                 │  │
  │  │        (MeetMe Cloud + Building Grandstream)           │  │
  │  └──────────┬─────────────────────────────────┬───────────┘  │
  │             │ RTP H.264 + RTCP PLI            │ SIP Events   │
  │             ▼                                 ▼              │
  │  ┌──────────────────────┐         ┌───────────────────────┐  │
  │  │   OpenH264 Decoder   │────────▶│  MQTT Auto-Discovery  │  │
  │  │   & JPEG Encoder     │         │   & Command Bridge    │  │
  │  └──────────────────────┘         └───────────┬───────────┘  │
  └───────────────────────────────────────────────┼──────────────┘
                                                  │
                                                  ▼
                                      ┌───────────────────────┐
                                      │    Home Assistant     │
                                      │ (Camera, Lock, Ring)  │
                                      └───────────────────────┘

Zero-Touch Provisioning & FCM Emulation

On startup, if no cached state exists on its persistent volume, iplusliving2mqtt performs a two-stage bootstrap:

FCM Registration: Emulates an Android check-in against android.clients.google.com/checkin and registers with Google Cloud Messaging (/c2dm/register3) using the official app's Firebase project parameters to obtain a valid fcm_token.
iPlus Auto-Provisioning: Logs into the iPlus Living API using the resident's email and password, binds the fcm_token, and caches the resulting SIP accounts and call panel directory to state.json.
MCS Stream: Opens a persistent TLS connection to mtalk.google.com:5228 speaking Google's binary MCS framing + Protobuf protocol. The moment an IC_CALL data message arrives, it signals the SIP worker tasks over an internal tokio::sync::mpsc channel to fire an immediate SIP REGISTER.

In-Memory H.264 Keyframe Extraction

Lobby panels stream H.264 video encapsulated in RTP packets (RFC 6184), including fragmented NAL units (FU-A, type 28) and aggregation packets (STAP-A, type 24).

Rather than spawning ffmpeg on every doorbell ring, iplusliving2mqtt handles the media stream directly in memory:

Sends UDP NAT-punching packets plus an RTCP Picture Loss Indication (PLI) and a SIP INFO (picture_fast_update) request immediately upon answering with 183 Session Progress so the panel transmits an IDR keyframe right away.
Reassembles fragmented H.264 NAL units (SPS, PPS, and IDR slices) and feeds the Annex-B bitstream into Cisco's openh264 decoder in memory.
Converts the decoded YUV420p frame to RGB and encodes a JPEG snapshot directly onto the MQTT camera topic (fermax/intercom/snapshot/image) and an HTTP /snapshot.jpg endpoint.

Dual-Mode DTMF Unlock

Different intercom relays along the call path can be picky about how DTMF digits are delivered. When you press the Unlock button in Home Assistant (or when auto-unlock is enabled), the daemon:

Answers the pending INVITE with 200 OK (if still in 183 Session Progress).
Transmits RFC 2833 (telephone-event/8000) RTP payload packets with the end-of-event marker bit and triple redundancy.
Follows up with synthesized in-band G.711 µ-law (PCMU) dual-tone sine waves (697–941 Hz + 1209–1477 Hz) at 8,000 Hz so both digital SIP gateways and analog door strike controllers reliably trigger.
Sends a clean SIP BYE to release the lobby panel.

A Fun Dual-Stack Debugging Quirk: IPv6 vs. IPv4 in SIP

When testing the daemon on a dual-stack host with native IPv6 connectivity, the initial SIP TLS connection to sip5.fermax.com:5223 completed its TLS handshake and then immediately dropped with an EOF.

Digging into the packet trace uncovered two separate issues:

RFC 3261 IPv6 Formatting: sip5.fermax.com publishes both A and AAAA records. Because the host preferred IPv6, tcp.local_addr() returned an IPv6 address. Formatting Via and Contact headers as ip:port without enclosing the IPv6 literal in square brackets ([2a09:...]:5060) caused Flexisip's parser to reject the REGISTER packet immediately.
IPv4-Only Media Relays: Even with bracketed IPv6 headers, the building's local PBX and the RTP audio/video media relays (c=IN IP4 ... in SDP) are strictly IPv4. Because the SIP engine learns its external NAT address from the SIP server's Via: ...;received=<ip>;rport=<port> response header to advertise in the SDP answer, registering over IPv6 leaves the media engine with an IPv6 address that an IPv4 RTP relay can never reach.

Explicitly resolving and selecting IPv4 socket addresses for the SIP/RTP path immediately brought both the MeetMe and Grandstream registrations to 200 OK.

Home Assistant Integration

Because iplusliving2mqtt publishes Home Assistant MQTT Auto-Discovery payloads under homeassistant/#, zero manual YAML configuration is required in Home Assistant. All entities automatically group under a single Fermax MeetMe Intercom device:

Entity	Type	Description
Doorbell Ringing	`binary_sensor`	Turns `ON` the instant an incoming `INVITE` arrives from any gate or lobby panel.
Call State	`sensor`	Tracks the call lifecycle: `idle` → `ringing` → `answered` → `unlocked`.
Last Caller	`sensor`	Displays the resolved lobby or gate name (e.g., Side Gate or Block Lobby) plus JSON attributes.
Intercom Camera	`camera`	Live JPEG snapshot decoded from the panel's H.264 RTP video stream.
Unlock Door	`button`	Immediately answers the active call and sends the DTMF unlock sequence.
Door Lock	`lock`	Reflects `LOCKED` / `UNLOCKED` state and supports standard Home Assistant lock actions.
Auto-Unlock on Ring	`switch`	Optional toggle that automatically answers and buzzes the door open after a configurable delay.

With everything in Home Assistant, a doorbell ring now triggers an instant push notification to our phones with the live decoded camera snapshot attached and an inline "Unlock Gate" action button—plus a temporary "expecting a delivery" toggle that auto-unlocks the lobby gate for the next ring and then turns itself off.

Kubernetes Deployment

True to the rest of my home infrastructure, iplusliving2mqtt is packaged as a minimal multi-stage container (gcr.io/distroless/cc-debian13:nonroot, running as UID 65532 with a read-only root filesystem and all Linux capabilities dropped) and deployed via a Helm chart with /healthz and /readyz probes that verify both MQTT broker connectivity and active SIP registration state.

Fixing Entra ID / Azure AD AADSTS75011 on Ceph Dashboard SAML

2026-10-17T00:00:00Z

While configuring SAML 2.0 Single Sign-On (SSO) for the Ceph Dashboard against Microsoft Entra ID (formerly Azure AD), standard password authentication works out of the box. However, the moment you authenticate with modern, phishing-resistant credentials—such as FIDO2 security keys, Windows Hello, or passwordless MFA—Entra ID rejects the login with AADSTS75011:

AADSTS75011: Authentication method 'MultiFactor, Fido' by which the user 
authenticated with the service doesn't match requested authentication method 
'Password, ProtectedTransport'. Contact the Ceph Dashboard application owner.

At first glance, the error seems backwards: authenticating with a FIDO2 hardware key and MFA is strictly more secure than a password, yet the Identity Provider blocks the session.

Here is why this happens in Ceph and how to fix it cleanly in the Ceph monitor configuration store without patching Python files inside the ceph-mgr container.

Why It Happens: `python-saml` and `RequestedAuthnContext`

Under the hood, the Ceph Dashboard relies on OneLogin's python-saml library to act as a SAML Service Provider.

By default, python-saml initializes its security configuration with:

'requestedAuthnContext': True

Unless overridden, every outbound AuthnRequest generated by the Ceph Dashboard includes an explicit <samlp:RequestedAuthnContext> block demanding PasswordProtectedTransport with Comparison="exact":

<samlp:RequestedAuthnContext Comparison="exact">
  <saml:AuthnContextClassRef>
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

Because Comparison="exact" is enforced, Entra ID checks the exact authentication method used to satisfy the session. When a user signs in with a passkey/FIDO2 token or MFA, Entra ID records the session context as MultiFactor, Fido. Since that does not literally match Password, ProtectedTransport, Entra ID aborts the SAML flow with AADSTS75011.

To allow FIDO2, passkeys, and MFA, Ceph needs to omit <samlp:RequestedAuthnContext> from its AuthnRequest and let Entra ID's Conditional Access policies govern acceptable authentication methods.

The Fix: Updating `ssodb_v1` in the Monitor Store

The ceph dashboard sso setup saml2 CLI command does not expose a flag to toggle requestedAuthnContext, and inspecting ceph dashboard sso show saml2 will show it enabled by default:

$ ceph dashboard sso show saml2 | jq '.onelogin_settings.security.requestedAuthnContext'
true

Instead of modifying sso.py on the container filesystem—which would be wiped on the next container restart or Ceph upgrade—we can patch the serialized SSO database (mgr/dashboard/ssodb_v1) directly in the Ceph monitor config-key store.

1. Export the Current SSO Configuration

Dump the raw JSON configuration from the monitor store:

ceph config-key get mgr/dashboard/ssodb_v1 > ssodb.json

2. Disable `requestedAuthnContext` Under `.saml2`

Ceph stores SAML 2.0 settings under .saml2.onelogin_settings. Use jq to set both requestedAuthnContext and failOnAuthnContextMismatch to false inside .saml2.onelogin_settings.security:

jq '.saml2.onelogin_settings.security += {
  "requestedAuthnContext": false,
  "failOnAuthnContextMismatch": false
}' ssodb.json > ssodb_updated.json

Verify the updated security block before applying it:

$ jq '.saml2.onelogin_settings.security' ssodb_updated.json
{
  "nameIdEncrypted": false,
  "authnRequestsSigned": false,
  "logoutRequestSigned": false,
  "logoutResponseSigned": false,
  "signMetadata": false,
  "wantMessagesSigned": false,
  "wantAssertionsSigned": false,
  "wantAssertionsEncrypted": false,
  "wantNameIdEncrypted": false,
  "metadataValidUntil": "",
  "wantAttributeStatement": false,
  "requestedAuthnContext": false,
  "failOnAuthnContextMismatch": false
}

3. Write the Configuration Back and Reload the Dashboard

Write the updated JSON back to mgr/dashboard/ssodb_v1:

ceph config-key set mgr/dashboard/ssodb_v1 -i ssodb_updated.json

Reload the dashboard manager module so ceph-mgr picks up the new settings from the monitor store:

ceph mgr module disable dashboard
ceph mgr module enable dashboard

Confirm that the active SAML configuration now reflects false:

$ ceph dashboard sso show saml2 | jq '.onelogin_settings.security.requestedAuthnContext'
false

Persistence and Operational Notes

With requestedAuthnContext disabled, SP-initiated logins to the Ceph Dashboard omit the <samlp:RequestedAuthnContext> constraint, allowing Entra ID to complete authentication using FIDO2 security keys, Windows Hello, or MFA without triggering AADSTS75011.

Because the configuration lives in the Ceph monitor database (config-key), it persists across ceph-mgr failovers, container restarts, and node reboots. The only caveat to keep in mind is that running ceph dashboard sso setup saml2 in the future (for instance, when rotating IdP signing certificates) will regenerate the .saml2 dictionary and reset requestedAuthnContext to true—so keep this jq patch in your cluster runbook or configuration management whenever SAML metadata is re-imported.

Why I Built BCRSTracking: Telemetry for Singapore's Bottle Return Scheme

2026-09-12T00:00:00Z

Few things in modern municipal living are as quietly frustrating as carrying two giant tote bags of rinsed plastic bottles and aluminum cans through Singapore's midday heat to your neighborhood supermarket, only to be greeted by a glowing red screen:

Machine Status: Bin Full. Please try again later.

Singapore’s Beverage Container Return Scheme (BCRS) is a fantastic sustainability initiative. Across the island, Reverse Vending Machines (RVMs) accept beverage containers and return deposits. But like any physical infrastructure distributed across hundreds of residential hubs, MRT stations, and supermarkets, real-world machines fill up, experience mechanical jams, or undergo routine maintenance.

As a Site Reliability Engineer, I don't like guessing whether a distributed system is healthy before interacting with it. If a network node has a status, it should have telemetry.

So I built BCRSTracking.

The Upstream API

When inspecting how the official tracking system works (bts.bcrs.sg), it turns out the platform exposes public API endpoints under /forapi/v2/. These endpoints provide:

Location Listings (/locations): A directory of all deployed RVM stations across the island, including operating hours, physical coordinates, and machine identifiers.
Bin Status & Telemetry (/bin-status): Real-time machine operational status, current bin capacity percentage, and hardware availability.

While the data was publicly accessible, there was no historical trend tracking, no differential event stream, and no way to query capacity curves over time to see when specific machines are emptied or filled.

Engineering Requirements

When architecting the tracker, I wanted it to be lightweight, resilient, and polite:

Polite Upstream Concurrency: Never overwhelm public services. Polling must use strict token-bucket rate limiting (golang.org/x/time/rate), bounded worker pools, and exponential backoff with jitter on HTTP 429 or 5xx responses.
Differential State Engine: Instead of blindly dumping snapshots, compute state transitions in memory (MACHINE_ADDED, STATUS_CHANGED, CAPACITY_THRESHOLD_CROSSED) so downstream systems can alert on state changes.
Fast Columnar Analytics: Store telemetry snapshots in ClickHouse using compressed columnar engines (ReplacingMergeTree for current state, MergeTree with TTL for historical bin levels).
Native Observability: Expose Prometheus metrics for scrapers, queue depth, upstream latency, and error rates, scraped by VictoriaMetrics.

System Architecture

The resulting service is written in Go 1.27 and runs as a lightweight container in Kubernetes:

               ┌───────────────────────────────────────────────┐
               │           Upstream BCRS Platform              │
               │            (bts.bcrs.sg/forapi/v2)            │
               └──────────────────────┬────────────────────────┘
                                      │
                                      │ Rate-Limited HTTP/2 (Token Bucket)
                                      │ Exponential Jittered Backoff
                                      ▼
               ┌───────────────────────────────────────────────┐
               │               bcrs-tracker                    │
               │                                               │
               │  ┌─────────────────────────────────────────┐  │
               │  │      Location Poller & Diff Engine      │  │
               │  └────────────────────┬────────────────────┘  │
               │                       │ Active RVM IDs        │
               │                       ▼                       │
               │  ┌─────────────────────────────────────────┐  │
               │  │   Bin Worker Pool (Bounded Concurrency) │  │
               │  └────────────────────┬────────────────────┘  │
               │                       │                       │
               │                       ▼                       │
               │  ┌─────────────────────────────────────────┐  │
               │  │    Batch Writer (500 rows / 5s flush)   │  │
               │  └────────────────────┬────────────────────┘  │
               │                       │                       │
               └───────────────────────┼───────────────────────┘
                                       │ Native Batch Insert (LZ4)
                                       ▼
               ┌───────────────────────────────────────────────┐
               │             ClickHouse Database               │
               │                                               │
               │   • rvm_current        (ReplacingMergeTree)   │
               │   • rvm_events         (MergeTree)            │
               │   • rvm_bin_snapshots  (MergeTree + 2yr TTL)  │
               └───────────────────────────────────────────────┘
                                       ▲
                                       │ SQL / PromQL
                                       │
               ┌───────────────────────┴───────────────────────┐
               │      VictoriaMetrics & Grafana Dashboards     │
               └───────────────────────────────────────────────┘

What the Telemetry Reveals

Having continuous time-series telemetry on reverse vending machines across Singapore reveals fascinating patterns:

The Weekend Surge: Neighborhood machines near residential housing estates typically reach 80–100% capacity on Saturday and Sunday between 2:00 PM and 6:00 PM.
Clearance Cadence: Logistics crews typically clear bins during early morning runs between 7:00 AM and 9:30 AM on weekdays.
Pre-Trip Confirmation: Instead of walking down hoping for the best, I can query my nearest machine via Prometheus/Grafana or a quick API curl to confirm it is operational and has available bin capacity.

Open Source

The entire tracker—including the Go poller, ClickHouse migrations, and Helm charts—is open-source on GitHub:

Repository: github.com/TheDJVG/BCRSTracking

If you're in Singapore and interested in tracking local smart-city infrastructure, feel free to check out the repository, submit PRs, or send me feedback at me@dj.vg.

The 'Datacenter at Home': A Multi-Homed BGP & WireGuard Mesh Architecture

2026-01-31T00:00:00Z

For the past five years, my home network hasn't just been a gateway to the internet; it's been a miniature ISP backbone. While most residential setups rely on a single ISP router doing basic NAT, I wanted something more robust: carrier-grade reliability, deterministic traffic engineering, and seamless multi-homing using my own public Autonomous System Number (AS209792).

By applying hyperscale datacenter design principles—like eBGP-on-the-host and Infrastructure as Code—I’ve built a network that treats residential ISPs as mere transport utilities.

The High-Level Architecture

The core of the network is built on redundancy. I am connected to two primary fiber ISPs in Singapore, MyRepublic and ViewQwest, along with a 5G backup link. Instead of relying on these ISPs for routing, I use them as "underlay" transport to reach my "Upstream Edge Cloud"—a fleet of six VPS nodes (edge1.sin through edge6.sin) hosted across providers.

The edge nodes are the true gateways to the internet. They announce my public prefixes to the global BGP table, while my home Core Router manages the paths between them.

The Connectivity Fabric: WireGuard and Deterministic Addressing

To link my Core Router to the cloud, I use a mesh of WireGuard tunnels. Rather than managing a messy internal IPAM (IP Address Management) database, I use a deterministic addressing logic.

Every tunnel interface is assigned an IPv6 address and a specific UDP listen port generated procedurally based on the IDs of the two nodes. This ensures that the same two peers always get the same IP pair and port, making firewalling and BGP peering definitions completely predictable across the entire mesh. To simplify things further, I utilize RFC 5549, which allows me to carry IPv4 routing information over an IPv6 next-hop, eliminating the need for private IPv4 point-to-point links.

Design Choice: eBGP Everywhere

A common question in BGP design is whether to use internal BGP (iBGP) or external BGP (eBGP). While iBGP is standard for single-ASN networks, it introduces complexity with split-horizon rules and requires Route Reflectors.

I chose the "eBGP in the Datacenter" approach. Every node in my network—the Core Router, the VPS edges, the pfSense firewall, and the Kubernetes nodes—operates under its own unique private ASN (645xx range).

Why this works:

Loop Prevention: BGP’s AS_PATH attribute naturally prevents loops. If a node sees its own ASN in a path, it drops the route.
Observability: I can look at my routing table and instantly see the path a packet took by looking at the sequence of ASNs.
A Clean Public Face: To the internet, I am a single entity. My edge nodes use BIRD (Internet Routing Daemon) with a strict export filter that "scrubs" these internal private ASNs, ensuring the world only sees a clean, single-hop path originating from AS209792.

The Brain: SaltStack & The Salt Mine

Orchestrating this manually would be impossible. I use SaltStack as the network’s "Control Plane." The secret sauce is the Salt Mine, a secure metadata store on the Salt Master.

Metadata Exchange: When a node joins, it generates its own WireGuard keys locally and pushes them, along with its current ISP IP, into the Salt Mine.
Automated Handshakes: All other nodes query the Mine and automatically "wire" themselves to the new peer.
Full System State: Salt doesn't just configure BGP. It manages the entire stack:
- systemd-networkd: Generates .netdev and .network files for the tunnels.
- Firewalling: Automatically opens the procedurally generated UDP ports only for authorized peers.
- BIRD: Templates the BGP sessions and filters.
- Kubernetes: Peering pfSense with the K8s nodes so that Pod/Service IPs are reachable across the entire network without NAT.

Reliability and Convergence

With residential ISPs, "silent failures" (where the link is up but traffic is blackholed) are a reality. To counter this, every BGP session runs BFD (Bidirectional Forwarding Detection). If a link drops even a few packets, BFD detects the failure in milliseconds and BGP reroutes traffic to a healthy ISP.

As a final failover, the 5G link is configured with heavy AS-path prepending. It stays in standby, receiving no traffic, until every other fiber path is exhausted.

Conclusion

This setup has been rock-solid for over five years. By moving the "intelligence" into SaltStack and using BGP for what it does best—path selection—I've created a home network that behaves like a professional datacenter fabric. It’s stateless, modular, and can scale to a new cloud provider with a single state.apply.

Easy and free Dynamic DNS

2025-10-04T00:00:00Z

The nasty need for dynamic DNS.

For a while now I've been maintaining a couple of 4G/5G enabled out of band devices. These devices are used to provide access to serial consoles of network devices. Why you ask? Well, sometimes a configuration error or something else causes the normal access paths to be unavailable. Who hasn't made a L2 loop by accident...

I call these devices "last resort". They provide a last resort access to my network when everything else fails, and they use 4G/5G for connectivity. The downside? They don't have a fixed IP address, quite often the IPs change. For most cases this is fine because I have reverse tunnels, but I still want to access them in case those fail. But for that to work I need to know 1 crucial thing: its IP address on the internet.

I'm sure many people have used a service like "dyn.com" to solve this problem, the device in question sends a HTTP request (we wish those devices support HTTPS...) and a DNS record gets updated with the IP of the requesting device. That way every time the IP changes the DNS record gets updated and we can access it using the DNS name and it makes it easy to monitor its availibility. The main problem I had with this solution is the cost (also the annoying ratelimiting, but I partially blame the devices in question), it was not worth the money to use "dyn.com" for something I can make myself, right?

So I made a service myself.

When I started to think about this had the following requirements: - Dead simple to request a new dynamic hostname - No need for accounts - Compatibility with DynDNS style updates (/nic/update) (more to add?)

When I had the requirements clear I also wanted to make it stateless, who wants to keep track of what hostnames are in use and not? If you lose the credentials, just get a fresh hostname. I quickly wrote an implementation using FastAPI and looked in my unused domain invenstory for a good candidate.

I present to you: XYZ.FRL

Now the initial version of this service is deployed I really like it myself, mainly because how simple it is. You want to know how simple? Open your terminal and come along.

Request a new dynamic hostname

› curl -s https://xyz.frl/generate | jq .
{
  "hostname": "4bd36fd6538b45b3b5449e615afc8e21.xyz.frl",
  "username": "4bd36fd6538b45b3b5449e615afc8e21",
  "password": "+MihUvQ8pc1QwYA6/16A/D/155qHfJKlUqUhNgD6osE="
}

Update the hostname with a new IP

Simple use curl to send an update request and set the ip to the valuse set in the myip query param (you can also leave it out to use the IP the request is coming from).

› curl -s --user '4bd36fd6538b45b3b5449e615afc8e21:+MihUvQ8pc1QwYA6/16A/D/155qHfJKlUqUhNgD6osE=' 'http://xyz.frl/nic/update?myip=192.0.2.0,100::'

Check your new IP!

It might take a brief moment for changes to propagate

› host 4bd36fd6538b45b3b5449e615afc8e21.xyz.frl
4bd36fd6538b45b3b5449e615afc8e21.xyz.frl has address 192.0.2.0
4bd36fd6538b45b3b5449e615afc8e21.xyz.frl has IPv6 address 100::

Profit.

From now simply use your compatible client (or curl) with our without the myip query param to update the IP address in the record. Make your own life easy by simply CNAMEing to this hostname and you should be good to go.

Final thoughts

This was a small fun project that I threw together on a Saturday morning when I got a renewal notice (and now cancellation) for DynDNS. I hope it can benefit others too.

Do you have any ideas to make this service even better? Contact me on me@dj.vg.

Security

While I've applied pretty aggressive rate limiting (1 request per minute on the generate and update endpoints) it's of course possible people might try to abuse this, if that happens I'll deal with it.

Timelapse system: a start

2022-01-25T00:00:00Z

Everyone that’s interested in technology will at some point face the same struggle: how do I apply all these interesting technologies in my own projects.

This is really the start of a system that (at the moment of writing) stores over 750 thousand photos occupying 6.2 terabyte of storage and every single minute this grows.

In the following comparison you can see a picture taken just after I started this project and one that has been taken on the day of publishing this piece.

Just after starting the project

Day of publishing

Times are changing

I’m living in an area that’s actively being developed and for some reason I can’t let go of the past. I want to keep track of how the area is changing and feel nostalgic on “how thing once were”. This is why is decided to put a camera on my balcony, with a Raspberry Pi and a Cronjob to take a picture every single minute using gPhoto2. The pictures would be saved on a simple NFS share backed by 2 times 1TB hard disks in raid 1. That was it. Anyone working in IT will immediately see a couple of problems with this approach, just to name a couple:

Reliability
Monitoring
Observability

Reliability

As I was not actively looking at the pictures it would happen multiple times that the Raspberry Pi was hanging or that for some reason the camera was not responding ending up with thousands of hanging Cronjobs. Also unreliable Wifi from outdoor made NFS very sad. That had to change, it should just work, even if one of the components is not working.

Monitoring

As mentioned in the previous paragraphs I was not aware of these problems. It was just (not) running and that is not great for a project that tries to capture a changing landscape one minute at a time. The moment there’s a problem with the setup I want to know about and preferable it should recover automatically (by for example resetting the power of the camera).

Observability

Taking a photo is one thing, but there’s so much extra information that I was not aware of. Some of the information is obvious, for example the ISO and exposure, which is stored in the Exif portion of the file. Other information that I wanted to store was: Outside temperature and relative humidity, how much time is spend on the camera, how reliable is this process, how long does it take to write the file to storage, and how much energy does all of this consume!

How to get there

In the blogs after this I will write down exactly how I got to a system that I almost never have to touch. How videos are automatically created daily. How the camera and controller is able to recover from almost any failure, how data is stored and replicated to the other side to the world.

So if you’re interested in Kubernetes, Ceph (and its S3 compatible API radosgw), Django, VictoriaMetrics (and metrics in general), Home Assistant, and many more (don’t forget the hardware). Come back soon to see how all of these things are combined to create a system that allows me to take reliable pictures that I plan to store forever!

Daan van Gorkum

Bridging a Cloud Condo Intercom to Home Assistant with Rust, SIP, and MQTT

Why Standard SIP Clients Don't Work

1. Split-Key Encrypted Provisioning API

2. The Push Notification Catch-22 (RFC 8599)

3. Early-Media H.264 Video & Dual-Mode DTMF

System Architecture

Zero-Touch Provisioning & FCM Emulation

In-Memory H.264 Keyframe Extraction

Dual-Mode DTMF Unlock

A Fun Dual-Stack Debugging Quirk: IPv6 vs. IPv4 in SIP

Home Assistant Integration

Kubernetes Deployment

Fixing Entra ID / Azure AD AADSTS75011 on Ceph Dashboard SAML

Why It Happens: python-saml and RequestedAuthnContext

The Fix: Updating ssodb_v1 in the Monitor Store

1. Export the Current SSO Configuration

2. Disable requestedAuthnContext Under .saml2

3. Write the Configuration Back and Reload the Dashboard

Persistence and Operational Notes

Why I Built BCRSTracking: Telemetry for Singapore's Bottle Return Scheme

The Upstream API

Engineering Requirements

System Architecture

What the Telemetry Reveals

Open Source

The 'Datacenter at Home': A Multi-Homed BGP & WireGuard Mesh Architecture

The High-Level Architecture

The Connectivity Fabric: WireGuard and Deterministic Addressing

Design Choice: eBGP Everywhere

Why this works:

The Brain: SaltStack & The Salt Mine

Reliability and Convergence

Conclusion

Easy and free Dynamic DNS

The nasty need for dynamic DNS.

So I made a service myself.

I present to you: XYZ.FRL

Request a new dynamic hostname

Update the hostname with a new IP

Check your new IP!

Profit.

Final thoughts

Security

Timelapse system: a start

Times are changing

Reliability

Monitoring

Observability

How to get there

Why It Happens: `python-saml` and `RequestedAuthnContext`

The Fix: Updating `ssodb_v1` in the Monitor Store

2. Disable `requestedAuthnContext` Under `.saml2`