jfx's site

Moving to Podman Quadlets

Sat, 11 Oct 2025 00:00:00 +0000

Prelude

My personal website & blog is jfx.ac where I blog about once a month

That was a lie, where have I been? I got back from a holiday, moved to a MacBook at work, switched to GrapheneOS, caught the flu, and have been trying out Linux on some interesting mini PCs. Too many distractions, and I hope to get back into my blogging routine.

Introduction

For the past few years I’ve been using Podman containers to run most of my services. Before moving to containers, I would install services via a package manager, or build them from source, and run the binaries and manage the lifecycle with systemd services.

The move to containers gave huge benefits. It made spinning services quick and easy, but managing the lifecycle of containers and performing mass upgrades for my many services across a couple of hosts felt cumbersome. I wanted to avoid heavy solutions and was yearning for something similar to the past. It was much easier to run a system upgrade and rely on systemd to manage my services.

I eventually started using a systemd template unit to manage my podman containers in rootless fashion, and over the years landed on the template below:

# /etc/systemd/system/podman-compose@.service
[Unit]
Description=%i rootless pod (podman-compose)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=always
RestartSec=20s
TimeoutStartSec=2min
User=%i
Type=oneshot
RemainAfterExit=true
WorkingDirectory=/etc/podman/%i
ExecStart=/usr/local/bin/podman-compose up -d --remove-orphans
ExecStop=/usr/local/bin/podman-compose down

[Install]
WantedBy=default.target

The interface was familiar, and I could simply run systemctl status podman-compose@homeassistant.service to manage my container for Home Assistant.

The term after the @ and before the type-suffix (in this case .service) is the instance of the unit, and is substituted in the %i variable in the definition. This substitution is used twice: once for the User= which runs the container, and a second time in the WorkingDirectory= path. This resulted in a simple and standardised way of managing rootless containers.

The unit file above worked OK, but occasionally after a reboot some containers would fail to start - which would annoyingly require manual intervention.

It always felt like I was forcing Podman into a systemd shape it wasn’t designed for.

Enter Quadlets

Quadlets integrate Podman directly with systemd, making containers behave like first-class system services.

What are Quadlets?

The official documentation says:

Quadlet is a tool for running Podman containers under systemd in an optimal way by allowing containers to run under systemd in a declarative way.

The (now frozen) Quadlet repository gives a longer explanation:

Containers are often used in a cloud context, and they are then used in combination with an orchestrator like Kubernetes. They are also commonly used during development and testing to manually manage containers on an ad-hoc basis.

However, there are also use cases where you want some kind of automatic container management, but on a smaller, single-node scale, and often more tightly integrated with the rest of the system. Typical examples of this can be embedded or automotive use, where there is no system administrator, or disconnected or edge servers.

The recommended way to do this is to use systemd to orchestrate the containers, since this is an already running process manager, and since podman containers are just child processes. There are many documents that describe how to use podman with systemd directly, but the end result are generally large, hard to maintain systemd config files. And often the container setup isn’t optimal.

Basically, anywhere you want to run a containerised system service without requiring human intervention, it’s wise to use systemd via Quadlets to manage your locally running Podman containers.

Because systemd carefully manages your container, you can rest easy that the lifecycle is tightly coupled to systemd.

Availability

Quadlets were first available to the public via their own repository on September 27th 2021. The project was then merged into Podman, and first released in Podman 4.4 on February 1st 2023.

Many of my hosts had Debian 12 bookworm installed, which shipped with Podman 4.3.1, missing the cutoff for Quadlet support. Debian 13 trixie, which was recently released on August 9th 2025 included Podman 5.4.2, which has support for Quadlets.

Getting started with Quadlets

An example of a Quadlet container is:

# sleep@.container
[Unit]
Description=The sleep container
After=local-fs.target

[Container]
Image=registry.access.redhat.com/ubi9-minimal:latest
Exec=sleep %i

The definition uses the familiar systemd unit file format, and the attributes under the [Container] section match those of a Docker Compose file. The complete spec for the [Container] section is available here: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html#container-units-container

A benefit of Quadlets is the containers have specific directories they will live, these are:

For system container files:

/run/containers/systemd/
/etc/containers/systemd/
/usr/share/containers/systemd/

For rootless container files:

$XDG_RUNTIME_DIR/containers/systemd/
$XDG_CONFIG_HOME/containers/systemd/ or ~/.config/containers/systemd/
/etc/containers/systemd/users/$(UID)
/etc/containers/systemd/users/

Once you place the sleep@.container in one of the directories - you can then run systemctl {--user} daemon-reload followed by systemctl {--user} start sleep@1000.container to start the container.

Moving to Quadlets

I was keen to use Quadlets and quickly upgraded my hosts to Debian 13 to leverage the capability. As one can imagine, the biggest obstacle is converting compose files to the Quadlet unit service file format.

To make this easier, there’s an open-source tool available called podlet, created by the containers community, which outputs Quadlet files from an existing Podman command or compose file. I had about 20 services to convert and podlet made it a very quick process.

My existing Home Assistant container had some complex device and group mappings to avoid running in privileged mode, but I was able to migrate without adjusting any of the output from podlet.

My old compose file looked like:

version: "3.8"
services:
 homeassistant:
 container_name: homeassistant
 image: ghcr.io/home-assistant/home-assistant:latest
 runtime: crun
 group_add:
 - keep-groups
 environment:
 - TZ=Australia/Melbourne
 - PYTHONPATH=/config/deps
 volumes:
 - /etc/podman/homeassistant/homeassistantconfig:/config
 network_mode: host
 devices:
 - /dev/ttyUSB0:/dev/ttyUSB0 # zigbee USB
 logging:
 driver: journald

To migrate I ran:

podlet compose /etc/podman/homeassistant/compose.yaml > /etc/containers/systemd/users/1001/homeassistant.container

I wanted the container to auto-start on boot and recover automatically, so I added to the bottom of the service file the following snippet:

[Service]
 Restart=always
[Install]
 WantedBy=multi-user.target default.target

This resulted in the following Quadlet container file, which lives in /etc/containers/systemd/users/1001/homeassistant.container:

# homeassistant.container
[Container]
AddDevice=/dev/ttyUSB0:/dev/ttyUSB0
ContainerName=homeassistant
Environment=TZ=Australia/Melbourne PYTHONPATH=/config/deps
Image=ghcr.io/home-assistant/home-assistant:latest
LogDriver=journald
Network=host
PodmanArgs=--group-add keep-groups
Volume=/etc/podman/homeassistant/homeassistantconfig:/config
GlobalArgs=--runtime crun
AutoUpdate=registry

[Service]
Restart=always

[Install]
WantedBy=multi-user.target default.target

Now the container is able to be managed by systemd as my rootless user, homeassistant which has UID 1001:

systemctl --user --daemon-reload
systemctl --user start homeassistant.service
systemctl --user status homeassistant.service

Handling upgrades

I also wanted to be able to check and apply upgrades easily, so for all my containers I add AutoUpdate=Registry under the [Container] section. This is to use the podman auto-update feature.

Don’t let the name fool you - it only auto-upgrades if you enable the podman-auto-update.timer. I wanted to avoid auto-upgrades as many services (such as Home Assistant) have breaking changes on upgrade. I like my lamps working in my home unless I choose to break them :)

You can check for upgrades with a simple command:

podman auto-update --dry-run --format '{{.Image}} {{.Updated}}'

And apply them when needed:

podman auto-update

How things are a month later

I’ve been using Quadlets for well over a month and my systemd units are still running:

homeassistant@medusa:~$ systemctl status --user homeassistant.service
● homeassistant.service
Loaded: loaded (/etc/containers/systemd/users/1001/homeassistant.container; generated)
Active: active (running) since Tue 2025-08-26 00:31:53 AEST; 1 month 16 days ago

I don’t regret the move and am so glad this technology is available. It makes self-hosting so much easier. Hope this helps others who have a similar need.

My KVM is better than yours

Fri, 18 Apr 2025 00:00:00 +0000

Damn right, it’s better than yours.

Introduction

My KVM (Keyboard, video, mouse) switch setup lets me use my home desktop and work laptop with ease.

Without giving away too much of the implementation (don’t worry, I’ll tell you in a bit), the key features:

USB 3.0 device support
Can control with an API :)
Controllable via Stream Deck or keyboard bindings
Supports HDMI/DisplayPort to any supported resolution and refresh rate of the monitor
- My 240hz 1080p monitor works great
No display disconnecting
- On Windows, if you disconnect a display, windows get moved to other monitors. This is incredibly annoying and does not happen on my setup
Relatively quick
Cheap
- My end costs were $40 AUD

Things I wanted to avoid:

Software-based KVM solutions - my home and work machines should not be aware of each other. I don’t feel comfortable sending keystrokes across machines.
An external monitor switcher hub device
- Mainly due to the lack of 240hz support and display disconnecting
Spending lots of money
- How do I justify the need to spend $300 on a high quality KVM to my company? or myself?
Slowness

Here’s how I did it

Handling USB

To switch my USB devices, I got a boring USB 3.0 hub which can switch between two machines from Amazon. It took a day to arrive, and costs about ~$30 AUD on sale.

I bought the popular UGREEN USB 3.0 Switch Selector. I’ve tried about 3 other ones and none were as good as this for the price, performance, and USB 3.0 support.

The USB hub comes with a toggle button on the top and no API. This worked well for a while, but I got tired of leaning across the table to press the button. I wanted it to have an API so I could switch it via my Stream Deck.

I bought a second USB hub, pulled it apart, and saw the electronics are simple. There’s a tactile switch which grounds a circuit momentarily to “toggle” which machine the device is serving USB to. Playing around with a multi-meter I was able to toggle the connected machine easily.

I had a Raspberry Pico lying around ($10 AUD) so I soldered a cable to the PCB in the spot to ground. I then wrote a simple program to quickly ground a pin on the Pico and connected the soldered cable to the Pico.

To my amazement the program actually worked:

Next I wrote a dirty HTTP server, connected it to my WiFi, and I was able to do the same via curl. For $40 (Pico + USB hub), I had a USB 3.0 hub I could control with an API.

Handling Displays

I’d tried an external device for switching between displays, but due to my monitors high refresh rate and Windows freaking out when displays were disconnected I found it not suitable. Luckily, I discovered that it’s possible to control displays with software.

There’s a not well-known protocol called Display Data Channel (DDC) developed by the Video Electronics Standards Association (VESA). DDC is essentially a bus that allows for digital communication between a computer display and video card.

Separately, there’s another protocol called Monitor Control Command Set (MCCS) which allows for controlling the properties of a monitor. Using DDC as a data channel, you can send MCCS messages bidirectionally between a computer and monitor.

With MCCS, you can do things like adjust the brightness or contrast of your monitor - but even more useful, you can set the current input of the monitor! The same as pressing the input button on your monitor yourself.

There’s a ton of software based implementations of MCCS via DDC on the internet. I decided to use monitorcontrol cause it was written in Python and worked across many platforms.

With a simple shell command, I could set my monitor to HDMI for my work laptop: monitorcontrol --monitor=2 --set-input-source HDMI1

The best part is this is completely free, so you do not need to pay for another device. You only need cables for each display and device.

Integrating USB and Display

I wanted to add custom buttons to my Stream Deck which allowed switching between my devices. To do this, I use this third-party Stream Deck Python library as Elgato’s Stream Deck software doesn’t work on Linux (shakes fist).

I added two buttons on my StreamDeck, one for switching to my laptop, and one for switching to my desktop. Both buttons effectively:

Send a web request to my Raspberry PI Pico to toggle the switch
Run monitorcontrol to set the device appropriately

I also created a third button that toggles only the USB device.

The reason why I wanted a button for each machine and not a toggle button - is cause displays get disconnected due to device sleep or cables slipping, so I had the need to explicitly select which device to switch to.

Unfortunately, I had no way of keeping track of which USB device my KVM connected to. This is cause the Pico has no state and grounds the pin whenever it receives a web request. I thought about tapping into the light on my KVM and using that for state management, then I realised there’s a simpler solution.

My Stream Deck is always directly connected to my desktop (not via KVM), and my desktop machine is always on. Due to this I could cheat a little.

When I press the button on my Stream Deck, my script runs lsusb and checks whether the USB hub is listed as a connected device. If I press the button to switch to my desktop, and the USB hub is connected, then there’s no need to call my Pico API to toggle the USB hub as the USB hub is connected to the correct device. If the USB hub did not appear in lsusb, then this would mean my USB hub was connected to my laptop, so my Stream Deck code correctly makes a web request to my Pico API to toggle the USB hub.

Cause of this cheat, I had a way to reliably detect whether the USB device was connected to the right PC or not, and only switch when appropriate. I combined this with monitorcontrol, and with a single button press I have a way to switch my display and USB devices.

A simpler alternative

I reflected on my KVM setup and I realised that there is a fairly simple alternative which does not require soldering or taking apart the UGREEN KVM.

Using udev rules, you can detect when a device is connected or disconnected from your Linux machine and run a shell command. You can create these rules on a single “main” machine - and listen to events on the USB hub device. When disconnected, you could run monitorcontrol to switch the display input to your other machine - and when connected switch back to the main machines display input.

For the UGREEN KVM, here are two rules which implement the above:

ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="5e3/610/663", RUN+="/bin/su -c '/home/jfx/.local/bin/monitorcontrol --monitor=2 --set-input-source DP1' jfx"

ACTION=="remove", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="5e3/610/663", RUN+="/bin/su -c '/home/jfx/.local/bin/monitorcontrol --monitor=2 --set-input-source HDMI1' jfx"

This is what works for me as I have monitorcontrol installed in my local users Python installation.

This setup requires you to press the button on the KVM, but saves you from needing to switch your monitor input yourself. It also saves you from soldering!

This will also only work on Linux due to udev, but I’m sure there’s a similar implementation for other operating systems.

Conclusion

A big factor of working from home is being comfortable, so it pays to have a setup to switch between your devices. You don’t need to perform brain surgery on your USB hub to be happy. If your company gives you an allowance for equipment, definitely try out a switchable USB hub with a button. I highly recommend the UGREEN one.

There is no financial cost of using free software like monitorcontrol - the only cost is your time. Try it out on your display and perhaps create a key-binding or two to switch between your display inputs.

I also enjoyed the opportunity to learn more about electronics and use a Pico to solve a problem. I’m not the strongest electronics person so this was a great learning project. Thank you to all the friends who helped out.

The code

The code for my Stream Deck is available here: https://github.com/itsjfx/dotfiles/blob/24a6e418244909d059a4d057645af0bb1f6996bc/lib/streamdeck.py#L144-L156

The code for my Pico API is available in this Gist: https://gist.github.com/itsjfx/647cb9cb142cb4eb3233214ec6a50229

Engineering project management

Fri, 21 Feb 2025 00:00:00 +0000

Introduction

As a Senior Engineer, one of my duties is breaking down large pieces of work into ordered and prioritised set of tasks, each scoped appropriately, ideally sized no more than 1 - 3 days.

It’s unlikely each task initially discussed during a planning session will be part of the final set, nor is it likely they appear in the initial ordering. As sessions progress, tasks may need to be re-prioritised, dependencies between tasks may get raised, and the scope of existing tasks may grow or shrink as newer tasks are discussed. It’s great to have a quick workflow which deals with these inevitable changes as it will result in more productive sessions.

I found working in a text box driven GUI slow as I had to repetitively open dialogs, move my mouse between text boxes, type words, and submit.

I was looking for a way to work smarter, do less tedious project management manual processes, and focus on solving real engineering problems.

For these reasons I made scrumfaster, which allows you to create GitHub issues and project items with Markdown.

The initial inspiration of using Markdown (other than it being great) came from an initial planning session of a project where my client had no project board set up, so we wrote a high level plan of the next few months in markdown. The client did not want to pay for or set up a Jira instance, so we decided to trial GitHub projects.

scrumfaster was initially a disgusting 50-line Bash script I wrote on a Friday night to get the tasks from that markdown doc into GitHub. From there we continued using it to create new sprints and bootstrap future projects. I decided it needed a rewrite in Python, which would allow more advanced features and less bugs, so I did that and published it online.

A showcase

Below is an example of some markdown which scrumfaster will accept (also referenced in the repo):

# my cool board

## Sprint 1

* [ ] Profile avatars
 * [ ] Create database migration for avatar field [@itsjfx] [status=Done] [labels=database] [1]
 * Name the field `avatar` in the `users` table
 * Set value for existing users to https://...
 * [ ] Accept avatar parameter in `update_user` API call [@itsjfx] [labels=api] [1]
 * Use existing image upload mechanisms
 * Limit image size to 10mb
 * [ ] Display and allow updating avatars on frontend [labels=frontend] [2]
 * Only display avatars on the users public profile page
 * Thumbnails aside comments to be implemented in later card
* [ ] Dark mode
 * [ ] Add ui toggle for dark mode [labels=frontend] [1]
 * Store preference in local storage
 * [ ] Implement styles [labels=frontend] [2]
 * Apply styles dynamically based on user preference
* [ ] Delete jeff from database [labels=database] [1]

Some key notes:

the nested tasks are syntactic sugar to create a task for each of the lowest children which the parent tasks as prefixes
- e.g. Profile avatars: Create database migration for avatar field would be the first task created
you can specify assignees, labels, points, and status in-line of the card
milestones can be specified as markdown headings
you can create GitHub issues, or GitHub project draft items

The result is a natural and readable markdown representation of a project.

There’s much more information on the repository, so if this got your interest please check it out: https://github.com/itsjfx/scrumfaster

Always be an Engineer

The main takeaway of this post is not the cool project I wrote, but that engineering should span across everything you do. Sadly, as you get promoted, you will find yourself getting more duties, and doing less engineering work. You’ll be responsible for people, be more involved in your companies politics, and spend a lot more time in meetings.

I believe a good engineer will be able to find ways to make their non-technical or tedious work exciting by identifying clear gaps and iteratively creating a solution which makes them more productive. You may be able to complete additional technical work or other important non-technical tasks as a result. More importantly, you will continue practising your engineering skills and demonstrate your competency to your peers. Never lose the engineer within you as you become more senior, but you must not neglect your key duties.

Debugging my stupidity with mitmproxy

Tue, 28 Jan 2025 00:00:00 +0000

Introduction

A colleague showed me a Neovim plugin that displayed errors from their LSP on virtual lines below their code, instead of adjacent to the code which is the default in Neovim. This interested me as I’d never thought about customising how errors are displayed in my Neovim.

I opened up ChatGPT and had a quick conversation on which plugins were available for doing customising error messages. To my surprise, ChatGPT suggested the same plugin that my colleague had just shown me. I then asked ChatGPT to tell me how to install the plugin with my plugin manager, Lazy.vim. What followed was a waste of 15 minutes of my day.

The problem

The plugin my colleague showed me was lsp_lines.nvim. It looks like this:

I looked at the README and was convinced to try it out, so I asked ChatGPT to “help me install lsp-lines.nvim”.

ChatGPT then suggested I add the following to my Lua config for lazy.nvim:

{
 "https://git.sr.ht/~whynothugo/lsp-lines.nvim",
 config = function()
 require("lsp_lines").setup()
 end,
}

I eyeballed the README for the project and it looked OK, so I slapped it in my Neovim config and tried it out.

After restarting Neovim, I got a HTTP 403 error during cloning the repository from Sourcehut.

Not what I was expecting. I had no clue why Sourcehut would give me a 403 for a repository that clearly existed! It couldn’t be SSH keys as I’d specified a HTTP URL. My first thought was Lazy was appending .git to the URL which works on GitHub but not on Sourcehut.

I looked at my colleagues config and his looked the same, and we also had the same version of Lazy installed.

Next, I went to the directory where Lazy clones plugins, copied the URL for the repository from my browser, and ran git clone … and that worked! But when I opened Neovim, it tried cloning the repository and it failed again.

I checked the source code for Lazy and saw it ran git clone, but didn’t seem to modify the URL, so my .git hypothesis was unlikely. I found it odd that Lazy would attempt cloning the repository even though the repository was on my machine, maybe cause I’d cloned it manually?

I needed to get more information on what was happening when it reached out to Sourcehut.

Enter mitmproxy

I’ve wrote about mitmproxy before when I was hacking IoT devices. It can be used to look at the HTTP requests Lazy makes when pulling the plugin.

First we need to start capturing traffic. I have an alias that runs mitmdump --flow-detail=4 --showhost --set hardump=/tmp/dump.har, which outputs traffic to the terminal in real time and will write a HAR file (essentially a HTTP traffic dump in JSON format) on exit.

Enter mitmwrap

Next, we need Neovim to send its traffic through the proxy, and also make sure Neovim trusts the SSL certificate for mitmproxy. I have a script in my dotfiles called mitmwrap for this.

The usage is mitmwrap [MITM_ARGS] PROGRAM [ARGS]. It currently has two modes: setting the HTTP_PROXY variables to point to my mitmproxy, or using proxychains to force an application to use mitmproxy. I plan on adding graftcp support later.

The script attempts to set common environment variables used by programs to look up the systems SSL store. I point these to the mitmproxy SSL certificate. Lastly, it runs the program in a lightweight container using bubblewrap , with /etc/ssl/certs/ca-certificates.crt mounted to our mitmproxy certificate in case the program does not use any of those earlier environment variables.

bubblewrap not only has a cool name, but is also a cool program, and is used internally by Flatpak to sandbox applications.

Why are we using bubblewrap? We aren’t using it to sandbox our program for security reasons, but cause /etc/ssl/certs/ca-certificates.crt is owned by root. I don’t want to run commands as root to change the file when I should be able to do everything in user-land.

I also don’t want mitmproxy’s certificate in my systems cert store as it affects every program on my system, and is a potential security risk.

Instead bubblewrap can be run with --dev-bind / / which is supposedly a no-op, before giving --ro-bind MITM_CERT_FILE /etc/ssl/certs/ca-certificates.crt to bind the SSL file in read-only mode. There’s a lot of options that could be set, but I set as little as possible to not break any programs.

The time to launch bubblewrap is a few milliseconds which is great for this use case. There’s a detailed blog on bubblewrap performance and using it as a Docker replacement if you’re curious.

I’ve ran my mitmwrap script a lot to write CLI wrappers for programs that make API calls. Most recently I used it to craft an API call similar to what the GitHub CLI (gh) made to its GraphQL endpoint. It was quicker than reading the docs and figuring out how to craft the query myself.

Bonus from today: I used the script to troubleshoot how aider was communicating with AWS Bedrock as it was failing and there were no helpful logs. I noticed aider was hitting us-west-2 instead of ap-southeast-2, and I quickly realised my AWS_REGION environment variable was not set, while AWS_DEFAULT_REGION was… which Aider does not read. Whoops!

Getting to the bottom of my cloning issue

mitmdump gave pretty output in the console, but I still couldn’t figure it out. It looked like the URL was formed well.

I also ran the git clone that worked earlier via mitmwrap and captured the traffic, and the request looked identical, except it had a 200 response code.

Generally the console output is pretty helpful, but I knew something had to be different, so I decided to look at the HAR file. I finally got to the bottom of it after running this command:

diff <(cat /tmp/dump.har | jq -rc '.log.entries[0].request | select(.method == "GET")' | gron) <(cat /tmp/dump.har | jq -rc '.log.entries[1].request | select(.method == "GET")' | gron)

This command reads the first HTTP GET requests JSON with jq, and pipes it into gron, and does the same for the second HTTP GET request. It then diffs the two outputs.

jq is a very powerful CLI JSON processor, and gron flattens JSON to make them easier to grep or parse. e.g.

echo '{"hello": "blog", "x": [1, 2]}' | gron
json = {};
json.hello = "blog";
json.x = [];
json.x[0] = 1;
json.x[1] = 2;

I find gron nice for feeding JSON into diff as it flattens it onto new lines.

What was the cause?? Well here is the output:

30c30
< json.url = "https://git.sr.ht/~whynothugo/lsp-lines.nvim/info/refs?service=git-upload-pack";
---
> json.url = "https://git.sr.ht/~whynothugo/lsp_lines.nvim/info/refs?service=git-upload-pack";

The difference is clear as day on my colourised diff output. I had been giving my Neovim lsp-lines.nvim, when the real URL is lsp_lines.nvim with an underscore.

How did this happen

I never typed the complete URL out manually in my Neovim config, so how did this happen? Well earlier in #the-problem, I had asked ChatGPT to give me the config for lsp-lines.nvim. I had not typed the name of the repository properly, so ChatGPT ran with it and gave me the URL in the same form with a hyphen instead of an underscore.

I also had no coffee for the day.

Reflecting

The URL in the example given by ChatGPT was incorrect, so I was doomed from the start. I reflected afterward and realised there were red flags and clear signs of why this was happening:

The 403 error was likely due to a URL typo
Cloning the repository locally
Neovim still trying to pull the plugin with the folder existing

At each of these points I should’ve figured out what was going on. Using mitmproxy and all the other tools felt like using a chainsaw to cut butter, but I’d already had these things pre-baked, so consuming them was not costly.

I was very grateful to have my own tooling to help me out here, as the next step was probably to get someone to pair with me and waste their time :) or drop the whole thing :)

I hope this story encourages you to brush up your scripts and keep them around in your dotfiles. You never know when you may need them again.

The plugin

At the end of the day I decided not to continue using lsp_lines.nvim, as in certain repositories it was moving lines around a lot and got annoying. I may use it again in the future with a toggle, but the default diagnostic view from Neovim is fine with me for now. I really wasted my time.

WebAuthn in the CLI

Fri, 20 Dec 2024 00:00:00 +0000

Introduction

The first thing that often comes to mind about FIDO2 WebAuthn clients is their integration with modern web browsers. Typically, users are prompted on a website to verify their identity by entering a PIN and interacting with a physical security key. This user-friendly flow is designed to to be fast, secure, and reduce reliance on passwords.

But what if you need to implement this functionality outside of a browser? What if your application runs in a command-line interface (CLI)? The good news is this is possible, but it’s not well documented or commonly implemented. I was motivated to implement this as leaving a terminal and waiting for a page to load to tap a device seemed wasteful.

This post will guide you through the process of implementing a FIDO2 WebAuthn client in Python. In our example, we wrap https://webauthn.io and cover some of the main concepts along the way. With enough focus this approach could be used to wrap any IDP or service.

Deep dive into WebAuthn

Summary

Mozilla has a detailed explanation here . I will try summarise below.

A typical WebAuthn authentication process in a browser looks like this:

The “relying party” (the website) sends user and server information to the web app handling the registration process, along with a “challenge”
The browser asks the authenticator device (e.g. YubiKey) to sign the challenge via a navigator.credentials.get() call. This process is called getting an assertion.
If the authenticator contains one of the given credentials and is able to successfully sign the challenge, it returns a signed assertion to the web app after receiving user consent
The web app forwards the signed assertion to the relying party server to validate
If everything checks out, the relying party will return a successful response to the web app

(from Trscavo at English Wikipedia available here)

Input

Drilling further into navigator.credentials.get(), it expects the following fields as parameters/inputs:

challenge - a value originating from the relying party’s server and used as a cryptographic challenge
rpId (optional) - a string that specifies the relying party’s identifier
- This is used for identifying which keys to use and for preventing cross-origin attacks
- an example value may be login.microsoft.com
allowCredentials (optional) - A restricted the list of acceptable credentials. An empty array indicates that any credential is acceptable.
- An empty list is typically used when the relying party is unaware of your username
- For example, GitHub sends an empty allowCredentials list when you press “Sign in with a passkey”.
- If you have multiple credentials registered under the relying party, your browser will ask you to select a credential to authenticate with
timeout (optional) - a hint indicating the time the relying party is willing to wait for the retrieval operation to complete
userVerification (optional) - A enumerated string specifying the relying party’s requirements for user verification of the authentication process
- e.g. whether or not to do PIN verification

More detail on each option is available:

In the Mozilla developer documentation
and in the WebAuthn specification

Most fields are optional, however if specified by the relying party they are important and should not be omitted.

Output

The function then returns an object with type PublicKeyCredential. Typically an identity provider (IDP) will expect this entire object to be sent back, or a subset of the fields under the response key which has type AuthenticatorAssertionResponse.

The important fields are:

authenticatorData - contains information about which relying party and credential was used
- your device may set an interesting field, signCount, a signature counter used to prevent device cloning
- if signCount is set, then repeated assertions will not return an identical authenticatorData value, thus each signature will be a unique value
clientDataJSON - contains the challenge and the origin used to prevent cross-origin attacks
signature - the combined signature of authenticatorData and clientDataJSON, signed with the private key of the selected credential associated with the relying party

Once a server receives these values, it can verify the signature was created by the correct credential, and can validate the contents of authenticatorData and clientDataJSON.

Inspecting webauthn.io

https://webauthn.io is a public service for testing passkeys. This makes it the perfect test bed for understanding the flow for a WebAuthn client and testing our CLI client. We may create a bunch of malformed requests, so it’s better to do this to a test service and not a real IDP as we may get locked out of our real account.

I won’t be covering registering passkeys in a CLI cause this is only completed once per security key. For the curious, this done in the browser via navigator.credentials.create().

Assuming we have already registered our passkey to a username, we can open the network explorer and observe a dual request log in flow:

A POST call to https://webauthn.io/authentication/options
- With a JSON request body: {"username":"jfxac","user_verification":"preferred"}
- And a JSON response body: {"challenge": "BASE64URL_CHALLENGE", "timeout": 60000, "rpId": "webauthn.io", "allowCredentials": [{"id": "BASE64URL_ID", "type": "public-key", "transports": ["usb"]}], "userVerification": "preferred"}
  - Luckily these are the exact key value pairs used by navigator.credentials.get()
A POST call to https://webauthn.io/authentication/verification
- With a JSON request body: containing the full response of navigator.credentials.get()
- And a JSON response body: {"verified": true}

With all the information required, we can write some code to call the APIs and feed the values into a WebAuthn client.

Writing some code

Yubico have a created a Python package called fido2 which has a WebAuthn client. They also provided an example which acts as both a server & client and allows for registering a credential and getting an assertion. We will use this code as a base for our webauthn.io wrapper.

The psuedocode is roughly:

Initialise a FIDO2 WebAuthn client
Call https://webauthn.io/authentication/options with username provided by command-line arguments
Pass the assertion options to the client, and wait for the user to complete the perform the actions
Once complete, call https://webauthn.io/authentication/verification with the values returned by the WebAuthn client
If successful, write something to the terminal and exit successfully - - otherwise write any errors to the terminal and exit unsuccessfully

A POST request to webauthn.io to kick off a log in:

import requests

COOKIES = {
 'csrftoken': generate_random_string(32),
 'sessionid': generate_random_string(32),
}

def get_options(username):
 data = {
 'username': username,
 'user_verification': 'required',
 }

 response = requests.post('https://webauthn.io/authentication/options', cookies=COOKIES, json=data)
 return response.json()

print(get_options(username))

This will give our challenge, rpId, allowCredentials, and userVerification values.

We can then call our WebAuthn client, passing in the above key value pairs:

I’ve removed the client initialisation code for this snippet but it’s available here: https://github.com/Yubico/python-fido2/blob/main/examples/exampleutils.py#L70

from fido2.utils import websafe_decode
...
...
options = get_options()
client = get_client()
request_options = {
 'rpId': options['rpId'],
 'challenge': websafe_decode(options['challenge']),
 'timeout': 600000,
 'allowCredentials': [PublicKeyCredentialDescriptor(type=cred['type'], id=websafe_decode(cred['id']), transports=cred['transports']) for cred in options['allowCredentials']],
 'userVerification': options['userVerification'],
}
result = client.get_assertion(request_options)
result = result.get_response(0)

result will contain our signed assertion, which can be sent to webauthn.io

Note the websafe_decode method used to give the FIDO2 library the raw challenge. A typical mistake is to give the WebAuthn client the challenge incorrectly encoded. In that case, the client will still sign an assertion, but the IDP will return a failure as the challenge is incorrect.

With the assertion from our device, we can make a POST request to webauthn.io with the fields populated:

from fido2.utils import websafe_decode
import requests

def respond(username, result):
 data = {
 'username': username,
 'response': {
 'authenticatorAttachment': 'cross-platform',
 'clientExtensionResults': {},
 'id': websafe_encode(result['credentialId']),
 'rawId': websafe_encode(result['credentialId']),
 'type': 'public-key',
 'response': {
 'clientDataJSON': websafe_encode(result['clientDataJSON']),
 'authenticatorData': websafe_encode(result['authenticatorData']),
 'signature': websafe_encode(result['signature']),
 'userHandle': websafe_encode(result['userHandle']),
 },
 },
 }

 response = requests.post('https://webauthn.io/authentication/verification', cookies=COOKIES, json=data)
 return response.json()

Note using websafe_encode to encode many of the fields. The data needs to be encoded as it’s in raw bytes. Typically Base64 URL encoded strings are used, but some IDPs may encode values differently. Make sure to identify the correct encoding.

Piecing it all together

With all the pieces found we can write a complete CLI tool. Here is a demo:

And here is the complete code that I published as a gist

Most of the code is initialising the FIDO2 WebAuthn client based on the example code mentioned earlier. The complexity lies in signing the assertion correctly and creating web requests exactly the way webauthn.io expects. This includes cookies and headers. It may take a bit of trial and error to get everything perfect.

Handling WSL

The following works great on Linux, Mac, and on native Windows, but does not work on WSL. Windows does not pass-through USB devices to WSL natively.

There are a few solutions however:

Install Python + fido2 package on Windows, call python.exe and capture the assertion (e.g. via stdout)
Follow this guide by Microsoft to expose the USB device to WSL
- With enough elbow grease you could automate this process

Conclusion

I enjoy working with hardware keys and have a keen interest in how FIDO2 works, so this was a really fun post to write. If you don’t write a CLI application with WebAuthn, I hope you still learnt something about how it works.

VS Code to Neovim

Sun, 15 Sep 2024 00:00:00 +0000

I decided to stop using VS Code completely and see how long I could use Neovim. It’s been 5 weeks and so far it’s been great. I wish I’d done it earlier.

What is Vim and Neovim

Vim

Vim is a free and open-source text editor that evolved from the original vi editor which dates back to 1976. It allows users to perform complex editing tasks through keyboard shortcuts without relying on a mouse. Vim has a text user interface (TUI) instead of a Graphical user interface (GUI).

Vim is a mode-based editor, with the popular modes being “Normal”, “Insert”, and “Command” mode. Vim users will navigate and issue editor commands in Normal mode, type text in Insert mode, and issue commands (e.g. saving, quitting, or find and replace) in Command mode.

Vim’s modes simplify tasks as they separate typing from actions and eliminate complex multi-key operations. Complex operations are issued via keystrokes with a clear purpose, resulting in a smoother process with minimal keystrokes and minimal movement from the keyboard’s home row. The caveat is switching modes and learning the keystrokes is complex and takes a while before it feels right.

Despite the complexity, in a StackOverflow 2023 survey, Vim was voted the 5th most popular text editor. 22.29% respondents said they regularly used Vim and wanted to continue to using it.

Neovim

Neovim is a fork of Vim that strives to improve the extensibility and maintainability of Vim. Neovim supports Lua scripting in addition to VimScript, making it easier for the community to extend the editor. You can learn more here about the vision of Neovim.

Compared to Vim, it has new powerful features such as: a well documented API, job-control, LSP support, built-in parser support, and more. Overall it feels more community-focused than Vim.

In the StackOverflow survey mentioned earlier, it was voted the 10th most popular text editor, however it was the most admired editor.

Learning Vim

During my annual leave January last year (20 months ago) I decided to learn Vim. I got curious after watching and talking to Vim users at work. Before Vim I used nano in the terminal for many years and VS Code as my GUI text editor and IDE of choice.

I chose to try Neovim on my workstation and Vim on remote servers.

I learnt the basics from the Tutor built into Vim via :Tutor. I also read sections of the Learn Neovim book by Ofir Gal which was helpful for understanding key concepts.

I found Vim and Neovim perfect for working on remote servers, changing configuration files, and making basic changes. However, I found it difficult to use for app development as it was too limiting.

I tried building out a basic Neovim configuration and installed plugins to make it more feature rich, but combined with learning Vim it was too much for me to handle. Instead I continued using VS Code for app development.

The Vim concepts and keybindings still intrigued me, so I installed a Vim extension for VSCode. The extension provides the productivity boost and behaviours of Vim alongside the powerful feature-set and familiarity of VS Code. I recommend it to anyone interested.

I also enabled Vim keybindings in Obsidian. I was definitely working faster after using Vim bindings in my editors for a few months as I was relying on the keyboard and less on the mouse. Cause I’d adjusted to the bindings from using the GUI programs, I was able to edit files a lot faster in the terminal. I no longer found editing files remotely over SSH a hindrance and was willing to do more changes over shell sessions. This helped me out a lot at work.

Switching over

The itch to stop emulating Vim and use the real thing was too big so I decided to try give switching another chance. I wanted more control over my text editor as I was doing JavaScript & CSS injection in VS Code’s Electron runtime to customise it which would break on most updates. I also felt like a heavy opinionated Electron editor was no longer for me and a terminal based workflow would be nice.

Before switching I thought about all the VS Code features I wanted in my new environment:

Buffer manager
- Go to bindings
- Re-ordering bindings
Indentation detection
Indentation guides
Git integration
File finder (Ctrl + P)
Text finder (Ctrl + Shift +F)
Syntax highlighting
- Treesitter
- LSP
Language Server Protocol (LSP)
- Manager
- Go to definition
- Show definition
Completion
- LSP
- Snippets
- Command line
Styling
- A nice theme
- Highlighting on TODOs
- Colouriser for hex codes
Status line
Directory manager
Session management
Rainbow parentheses
Indentation guides

I suggest doing the same exercise.

As mentioned earlier, I previously attempted setting up a Neovim environment and it was incredibly time-consuming. Most of the features I wanted are not available out of the box and require third-party plugins. After asking people for plugin suggestions the list quickly piled up. I just wanted something that would work that I could change later when I felt like customising/ricing it to suit me.

Trying out presets

Struggling with distributions

Luckily people online have tried solving my problems by having Neovim configurations available.

There’s generally two ways of getting started:

using a Neovim distribution
- fully-fledged, opinionated, and feature-rich IDE-like Neovim environments
- probably has more things than you need
- feels like its own editor, not like Neovim
- e.g. LunarVim, AstroNvim
using and modifying a basic configuration
- less feature-rich
- likely missing a couple of things you want
- generally people’s dot-files, Neovim “templates”, or “basic configurations”

I tried two popular Neovim distributions (based on GitHub stars) and both of them gave me a giant wall of errors each time I opened a buffer. I’m not going to name and shame them as it’s likely my fault. I was frustrated after waiting for an absurd number of plugins to download for it to not to function.

I immediately kicked into troubleshoot mode and started fixing problems. Eventually I sat back and came to the realisation that it shouldn’t be this hard.

kickstart

Before I gave up again, a colleague suggested I try kickstart.nvim. It’s absolutely amazing.

kickstart is a highly documented less opinionated starting point / basic configuration for Neovim. It has LSP, treesitter, telescope (fuzzy finder), some sane default options, and that’s it.

If you’d like additional LSP servers or treesitter parsers, it’s written in the config how to add them. The result is a reasonably light Neovim environment, most of the config is just documentation in the comments.

Here’s how kickstart looks:

Kickstart out of the box

Telescopes file finder

Telescopes live grep

Kickstart clocks at only 26 plugins, most of which enhance language features or add Telescope functionality, so it's fairly lightweight but lacking a couple things from the list mentioned earlier.

My setup

Configuration

Which brings us to me. I run a modified version of kickstart. Typically I break my dot-files up into multiple files (see my zsh and tmux), but I’ve not done that yet and just extended the single file kickstart.

To help extend my config I used a bunch of plugins from rockerBOO’s awesome-neovim list, Tim Pope (tpope), and /r/neovim. So far I’ve not run into issues with plugins fighting each other or being incompatible.

In addition to kickstart’s configuration, I installed:

buffer manager
- using barbar.nvim
directory manager
- using the wonderful oil.nvim
- and neo-tree.nvim for my sidebar
colorizer
- nvim-colorizer
session manager
- using vim-obsession to get a similar experience to VS Code workspaces
- (more below)
rainbow parentheses
- using nvim-ts-rainbow forked by the wonderful lincheney
indentation guides
- indent-blankline.nvim
fzf.vim instead of telescope
- (more below)
movement plugins
- leap.nvim crazy plugin to navigate to the exact word you want
- quick-scope enhances the f mode to highlight the first character of each word
- mini.move to quickly move things around instead of using d & p (highly recommend this)
more git plugins
- vim-fugitive for some extra Git bits
- vim-flog for browsing Git logs
- vim-gh-line for opening stuff in the browser
- kickstart has gitsigns.nvim out of the box which is a great plugin for seeing changed lines/hunks
a bunch of small quality of life plugins
- bullets.vim for editing markdown lists
- mini.cursorword to show other matches on highlighted words
- committia.vim nicer git commit editor
- vim-easy-align for aligning things, e.g. by whitespace or colon
- nvim-treesitter-context for getting function scoping when scrolling
- rainbow_csv for clarity when editing tsv-like files
- vim-repeat

I’m not likely to keep this post updated. Source of truth is available in my dotfiles, but I hope the above list and three links (especially awesome-neovim) will help people get started.

I’ve got 52 plugins installed in total (including some not mentioned above), so I’ve doubled the amount from kickstart.

Kickstart comes out of the box with telescope.nvim which is a fuzzy finder for Neovim. I try use fzf (another fuzzy finder) everywhere I can, so while telescope was installed and working well I use fzf for Ripgrep and file finding. The telescope setup in kickstart works really well though so I suggest people to try it out first.

Screengrabs

My Neovim with the file manager shown

A demo of me using Neovim. leap + fzf + LSP (recorded with asciinema, click to enlarge)

Working remotely

The nice thing about Neovim running in a terminal is I can resume my sessions remotely as all my shell sessions run within a tmux session. This is a reference to my-workflow-philosophy#resumable. Check out my other post if you have not :)

Sometimes I work on my desktop, and other times on my laptop on the couch. When I move to the couch I SSH to my desktop, press CTRL + b (my prefix key for tmux), then press s to interactively see my tmux sessions, select my Neovim session and continue working. When I go back to my desktop everything is the same as when I finished on my laptop. Super seamless.

To match the Remote SSH VS Code extension I either run Vim directly on a server, or mount the remote file system with SSHFS or SFTP over rclone and edit locally via Neovim.

VS Code key bindings

I was used to VS code’s keybindings for commenting (CTRL + /) and searching for files (CTRL + p), so I bound those in Neovim too. Eventually I want to remove these hot-keys and rely more on Vim modes instead, however keeping some bindings has greatly aided transitioning.

Session Management

When using VS Code I create VS Code workspaces for each project and save them in ~/.code-workspaces/. I had a Rofi selector which let me select and open my workspaces. It looked like this:

For Neovim I use vim-obsession by Tim Pope which extends the in-built Vim mksession command to save and resume sessions more aggressively, effectively behaving like VS Code workspaces. Starting a session is done with :Obsession ~/.nvim-sessions/x and resuming sessions is by nvim -S ~/.nvim-sessions/x.

To make resuming sessions easier I use a shell command vw with custom tab completion. It looks like this:

The source code is located here:

Things to improve

Right now I’m very happy overall but there’s a few things I want to improve on.

I don’t have a debugger nor dev containers working in Neovim at the moment. A project I work on utilises these two things heavily so I may need to continue using VS Code until I figure out how to get it working nicely in Neovim.

There’s also a ton of plugins I’ve installed but have not understood much about. For example, Gitsigns, Fugitive, and oil have a bunch of powerful features and bindings I’m not utilising, so I hope I figure these out eventually.

I also miss having a multi line buffer manager in VS Code, and while barbar is nice it continues overflowing horizontally if I open too many buffers, so I hope to find a buffer manager that works like VS Code did.

There’s also a ton of Vim stuff I still need to learn :)

Conclusion

I hope this helps someone else switch to Neovim and gives some ideas on how to do the move. I highly recommend learning how to Vim in the shell, then trying out Vim bindings in your current editor (if possible), and then trying out Neovim as your main editor if you feel like moving.

Learning Vim in the shell as a minimum will be extremely fulfilling and help you doing basic operations in the terminal.

Remember nobody is forcing you to use Vim everyday and you can always go back to VS Code or your original editor :)

Homelab & Mikrotik inspection network

Wed, 31 Jul 2024 00:00:00 +0000

Introduction

I wanted to reverse engineer the protocols of IoT devices, but it had been a while since I’d last traffic inspected a device and I needed to set up something fresh.

In the past I would’ve run Linux on a laptop, spawn an AP, run tcpdump and call it a day. But I put so much effort into building a home network with my Mikrotik router and Ubiquiti APs, and have the ability to use VLANs, so I wanted to do something better.

My goals:

no reliance on a desktop/laptop for the capturing to function. my home lab server and wireless APs are always on so I want to use these
TLS termination as I’d need to capture HTTPS & MQTTS traffic
strong WiFi coverage and speed
- Coverage: I’ll be inspecting robot vacuums which will physically traverse my whole house
- Speed: I’ll be dumping and transferring file systems via the network from IoT devices once I gain root. These may be large and I don’t want to spend too long waiting
easily capture and override DNS lookups
easily toggle the inspection
- it’s generally annoying to reset WiFi on an IoT device, so being able to toggle inspection on the Mikrotik is super convenient
harness the power of mitmproxy and *shark programs like wireshark and tshark to understand the protocols on these devices

Building it out

Mikrotik

Create a new IP pool, assign a VLAN ID
Create a DHCP server, point the gateway to Mikrotik router, and DNS to something like Google/Cloudflare temporarily

Ubiquiti

Create a new “Network”, assign it the VLAN ID of the inspection VLAN created above
Create a new WiFi network, assign it to the network just created
1. Suggest using an alphanumeric SSID and password as some IoT devices play funny with symbols
2. Suggest forcing 2.4Ghz + WPA2 for compatibility, however if you know the device can support 5Ghz use that

VM

Fortunately I run Proxmox, so it’s very easy for me to spin up a VM for inspection:

ens18 - main NIC on main network, can connect to it from my desktop
ens19 - secondary NIC assigned to VLAN ID earlier

Make sure the route tables still have your main NIC as the default route. I’m running Debian and needed to edit /etc/network/interfaces. If you’re using another distro or NetworkManager, follow the appropriate steps.

In the Mikrotik DHCP server, assign this server a static IP, e.g. 192.168.30.2

Software

Install mitmproxy
Install dnsmasq
Install tcpdump
Install iptables

mitmproxy

mitmproxy will be used for TLS decryption and termination. The mitmdump output can also be handy to see what’s going on, however we will mainly be using it to capture the pre-master secrets used in TLS handshakes and throw them into tshark/wireshark later.

Run mitmproxy with SSLKEYLOGFILE set to capture the TLS pre-shared keys. For information see here

I run this script. The first argument is the name of the output capture file, and I generally run it out of the directory I want to store my captures. I don’t look at the mitmproxy output often, but it’s nice to have it stored. I call this script mitm.

These commands are from:

#!/usr/bin/env bash

set -eu -o pipefail

# ensure dependencies
# https://docs.mitmproxy.org/stable/howto-transparent/#linux
sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo sysctl -w net.ipv4.conf.all.send_redirects=0
for cmd in iptables ip6tables; do
 sudo "$cmd" -t nat -A PREROUTING -i ens19 -p tcp --dport 80 -j REDIRECT --to-port 8080
 sudo "$cmd" -t nat -A PREROUTING -i ens19 -p tcp --dport 443 -j REDIRECT --to-port 8080
 sudo "$cmd" -t nat -A PREROUTING -i ens19 -p tcp --dport 8883 -j REDIRECT --to-port 8080
done

# for wireshark
export SSLKEYLOGFILE="$HOME"/.mitmproxy/sslkeylogfile.txt
outfile="$1".mitmdump.txt
shift
mitmdump -m transparent --save-stream-file="$outfile" --tcp-hosts='192.168.30.0/24' --raw --ssl-insecure "$@"

dnsmasq

dnsmasq is used for capturing and overriding DNS lookups. Some devices may bypass this of course, but I’ve found most of the time it works well.

Setup dnsmasq to log requests to a file, and point to an upstream DNS

My config looks like this. Anything I want to override I set at the bottom

interface=ens19
server=1.1.1.1
log-queries
log-facility=/var/log/dnsmasq.log
listen-address=127.0.0.1,192.168.30.2
#address=/jmq-ngiot-au.area.ww.ecouser.net/192.168.30.2
address=/jmq-ngiot-au.area.ww.ecouser.net/127.0.0.1

tcpdump

tcpdump is used for capturing TCP/IP traffic on a network interface. It can later be parsed.

Run tcpdump to dump a .pcap flie.

A basic usage is something like this:

sudo tcpdump -i ens19 -U -w idle.pcap
sudo tcpdump -i ens19 -U -w idle.pcap 'host xxx.xxx.xxx.xx'

Setting capturing up

Go back in the Mikrotik and set the DHCP server’s gateway and DNS to the VM’s IP
Force a DHCP request by having the device reconnect to the AP
All requests should be going through the VM, see output in the mitmdump script above

Tying it all together

Things aren’t as usable as they could be as we’re using a VM. I’ve solved a lot of friction by tunnelling things over SSH.

I do the following:

SSH ProxyJump

I use ssh X -J VM to connect to my IoT devices on the inspect network, effectively using my inspect VM as a bastion or jump host.

-J is the ProxyJump flag in SSH. See man ssh for more information

network capture script

I got a bunch of hacky scripts I put together in the heat of the moment to get everything captured in an efficient enough way.

I have a “capture” script, which lives on the VM, and which I execute over SSH. It runs tcpdump and writes output a file on the VM, as well as stdout, and runs mitmdump and outputs the logs to stderr

The capture script looks like this, where ./bin/mitm is the mitmproxy script earlier :

#!/usr/bin/env bash

set -eu -o pipefail

capture_name="$1"
shift
./bin/mitm "$capture_name" >&2 &
pid="$!"
echo 'Run mitm, running tcpdump' >&2
trap 'kill "$pid"; echo dead >&2' EXIT
sudo tcpdump -i ens19 -U -w - 'host xxx.xxx.xxx.xxx' | tee "$capture_name".pcap

I also have a cleanup script. It makes sure everything is dead cause running these commands over SSH does not always gracefully exit.

#!/usr/bin/env bash

killall mitmdump
sudo killall tcpdump

I wrap this in a script on my local machine. I call it capture-mitm:

#!/usr/bin/env bash

set -eu -o pipefail

capture="$1"
shift
trap 'ssh inspect ./bin/cleanup' EXIT
ssh inspect ./bin/capture "$capture" "$@"

In another shell on my machine, I run a script to stream SSLKEYLOGFILE to a file, so tshark and wireshark work as expected.

ssh inspect 'tail -F -n +1 "$HOME"/.mitmproxy/sslkeylogfile.txt' >/tmp/sslkeylogfile.txt

I can now run capture-mitm CAPTURE_NAME | wireshark -k -i - and see in real-time the traffic inspection in wireshark over SSH.

If I look back at the command I can see mitmdump output. If I exit out of the command it’ll stop capturing traffic on the VM. Any session information is stored on the VM in a CAPTURE_NAME.pcap file, so I can revisit it later and parse it with tshark or wireshark again.

I like this setup cause I get live data as well as the “raw” data saved, which is super helpful if you struck upon gold.

socat & dnsmasq

I also use socat & dnsmasq on the VM to expose any services to the IoT device

similar premise to ssh -J, I’m using the VM to forward and expose ports from my local machine to the IoT device
e.g. sudo socat tcp-listen:443,reuseaddr,fork tcp:192.168.88.x:1883
- in this example I’m redirecting my IoT devices cloud server to my VM via DNS rewrite using dnsmasq, then I’m exposing port 443 on my VM to port 1883 on my machine on my home network
- when the IoT device wants to connect to the cloud, it’ll resolve the VM via DNS, then connect to the VM, and the VM will connect to my machine which is on another subnet/VLAN and forward the traffic
- if I want the robot to connect to the real cloud, I can replace my machines IP in the socat command with the IP of the real cloud. I could point the DNS record back, but then that’ll require restarting dnsmasq and flushing DNS cache on the IoT device (likely doing a reboot)

The result

I want to write a separate post on how I do crazy parsing on MQTT traffic via tshark, however here’s a sneak peek of what I can do with the setup above:

Using Wireshark:

Using my fork of mqttshark:

Using a hastily written script which parses the output from tshark , understands the cloud-specific protocol, and dumps an aggregated summarised version into yaml (batches requests and responses), which is easier to read and also parse with tools like jq, gron, and grep:

I got 3 different ways to get information about my IoT device and the messages, which makes reverse-engineering much simpler!

Robot vacuum hacking

Mon, 24 Jun 2024 00:00:00 +0000

Important Notice

I’m writing this post to give a lens into robot hacking and the work being done by the community. This is not aimed to sell the idea of hacking your robot.

Please do your research and understand the goals and risks of hacking your robot before you try.

Introduction

This is a long post on things I wish I knew earlier about hacking robot vacuums. This is not a replacement for existing documentation or help guides. If you only care about rooting your robot and freeing it for the cloud and don’t care about how the robot works, chances are this post won’t be that helpful to you.

Earlier this month, I installed custom firmware and a cloud replacement on a second Dreame L10s Ultra robot vacuum. Also released this month (2024-June) was root and cloud-replacement support for the new Dreame X40 Ultra and Dreame L10s Pro Ultra Heat, so it’s certainly still an exciting time to get into robot hacking!

I’ll quickly cover about my views on robot vacuums, the robot hardware, the hacking community, the software, and write briefly about my experiences. Feel free to skip over my preamble into robot vacuums if you’re not interested.

Why am I crazy about robot vacuums?

Robot vacuums are a great purchase as you can only vacuum and mop your home so much. Dust builds up very quickly and unless you’re regularly vacuuming your home daily, you’ll find that dust will travel across the house onto more surfaces.

Modern robots have advanced mop heads which spin at fast speeds to get your floors clean. They can take in clean water from a water tank in the dock, use detergent, self-clean & dry the mop, and empty the dirty water into a secondary dirty water tank for you to empty into your drain.

The mop means my hardwood floors are shiny which makes me happy. I find mopping tiring so it helps relieve some physical hardship.

I also got a robot for my elderly parents which helps reduce physical effort needed by them to maintain a tidy house. It’s a great piece of luxury hardware if you can justify spending the money on one.

Why am I also unhappy with robot vacuums?

One of the main factors is privacy. As a consumer you place a lot of trust on the vendor. You don’t have any control of the software running on the robot. It requires internet access, has cameras, sensors, and local AI models equipped.

These aren’t crazy concerns to have. If you watch Dennis Giese & braelynn’s talk at 37C3, they showcase that robots made by a specific vendor have user data which is publicly accessible, remains on cloud servers past account deletion, and remains on the robot past factory reset. The same vendors robots software avoids TLS checks as they have shell scripts with wget --no-check-certificate in the firmware. Additionally they showcased an exploit where the live video feed for a robot is accessible under certain conditions as a pin check is enforced client side in the application.

Other than privacy, you may not want a robot due to high cost, messy or uneven flooring, or carpet, which in recent years is less of an issue due to detachable mop vacuums.

Update: Dennis Giese published a zero-touch RCE via BLE for the same vendors robot. An article is available here showcasing the exploit: https://www.abc.net.au/news/2024-10-04/robot-vacuum-hacked-photos-camera-audio/104414020

Robot hardware breakdown

Below is a hardware breakdown diagram from the same talk mentioned earlier.

The SoC

The system on a chip (SoC) is the application processor which handles navigation, mapping and networking. It typically runs Linux.

Custom vendor software runs on the robot as a daemon and does most of the heavy lifting handling cloud communication, OTA, robot control, mapping, and other user facing functions. On Dreame this software is called ava, and on Ecovacs it’s called medusa.

Some interesting things I found:

Some vendors have a lot of shell scripts with poor bash/shell scripting practices which get called on the SoC. These scripts may interact with the OS, handle WiFi (e.g. interact with wpa_supplicant), or interact with the custom vendor software.
As the camera is part of the SoC, on some devices it can be accessed as a video device on /dev/videoX .
Newer robots can be seen having 4 core SoCs, 1-2GB of RAM, 4-8GB of flash storage, and getting more powerful overtime.
My robot, the Dreame L10s Ultra runs Athena Linux ARM64 on the SoC
- Linux r2228_release 4.9.191 #1 SMP PREEMPT Wed Sep 13 15:19:31 CST 2023 aarch64 GNU/Linux

The MCU

The micro-controller unit (MCU) handles real-time operations such as motors and sensors. This has it’s own firmware separate to the SoC’s firmware/OS. Information on the MCU firmware for the Dreame Z10 is available here if you’d like to learn about what lives in the MCU for a robot.

MCU interest is not as popular. It requires a different set of skills. There’s a lot of secret sauce baked into the MCU, so vendors make it difficult for people to understand what’s happening. Most people are interested in the SoC and the cloud integration. I’d suggest only learning more if you’re interested in hardware or MCUs.

Finding hardware information

Dennis Giese has done research on a large number of robots and published information here. Information on the hardware used as well as software & firmware versions, links to rooting methods and custom firmware downloads are available for many robots.

There are sometimes breakdowns of the robot boards themselves. It’s an extremely valuable resource to understand what builds up a robot.

The robot hacking community

The community seems to be broken down to the following groups of people:

People interested in removing the cloud from their robot
- This is the average hacker and makes a large portion of the community
- Mixed level of skills
- Many sadly incapable of reading documentation/FAQs or following instructions and complain on Telegram or GitHub
- It’s disappointing to see in the chats as it makes approaching the community as an outsider more difficult as such
People interested in the hardware
People interested in the firmware/software on the SoC
- Gaining root
- Building custom cloud implementations
- Research
People interested in the firmware on the MCU

There are many people who contribute greatly in the community, but it boils down to these two people (who are the most public):

Dennis Giese, an IoT researcher
- Dennis maintains Dustbuilder, a website which allows you to create custom rooted firmware for robot vacuums
- Dennis also maintains the Robot Info website (mentioned earlier)
- Dennis and others discover root methods, gain persistence, and verify vendor claims
Sören Beye (known as Hypfer) who is the maintainer of Valetudo, a cloud replacement software for robot vacuums
- Hypfer is very vocal about his views and vocalising the strug of maintaining a popular open-source project and providing support. See the “On not burning out” section in this release: https://github.com/Hypfer/Valetudo/releases/tag/2024.06.2. It’s a good read. Don’t be like these people if you visit the Telegram chat.
- FWIW: I found that the Valetudo/rooting how-to guides and surrounding documentation are simple enough to follow and answer enough questions that you shouldn’t need additional support in Telegram.

Dustbuilder

Once a root method is discovered and published, a Dustbuilder page for a robot is generally created sometime later.

Dustbuilder creates a patched firmware to run on your SoC, and gives you an MCU firmware image. It saves you from dumping and patching the firmware yourself (which may not be possible), and saves you from doing it incorrectly.

It has several patches to allow you to gain persistence on the robot, and disable cloud connectivity, calling home features like telemetry, video recordings. It allows you to use Valetudo, and much more. You can see the diff from the original firmware image which is really helpful in understanding what it does.

If a vendor updates the firmware, it’s likely the Dustbuilder firmware will also be updated (once determined stable). This means you can continue to receive vendor updates to the MCU/SoC even when rooting.

Valetudo

What is it? (tech wise)

As a preface, I’d suggest reading the Valetudo Newcomer Guide and come back here. I’m going to write mostly about my observations about tech itself rather than what the software offers and it’s goals. Please read the official documentation to understand the project.

As mentioned, Valetudo is a cloud replacement for robot vacuums. It has a frontend written in React + TypeScript, and a backend written in Node.js.

Valetudo is an interesting piece of software as it will run an API, serve a frontend, act as an MQTT client, and implement the robots cloud all as a single binary on your robot.

It’s not a firmware replacement unlike other articles on the internet mention. Instead it sits alongside existing firmware on the robot, typically a patched firmware from Dustbuilder. As it does not replace the firmware, you shouldn’t lose functionality of the original robot.

Before installing Valetudo I was expecting that I’d have to host it on another machine as it’s a cloud replacement, but this is not the case. It has no dependencies on other infrastructure like a server, except for NTP, and has no dependency on a mobile app interface like stock firmware robot vacuums.

Cause of it’s architecture, Valetudo won’t face any issues due to infrastructure being down or having a conflicting version. It will simply operate as expected as long as it can continue to run on the robot. If you have multiple robots, then they will each run their own instance of Valetudo.

This has the con that the robot has to be powerful enough to run Valetudo as well as its original firmware, however the maintainer has taken a lot of efforts to ensure Valetudo runs with a low hardware footprint.

Valetudo officially supports 35 different robots across different vendors. Officially supported means each robot has been tested by Hypfer, with the root method documented for each robot. It’s insane that a single piece of software not only works with so many robots, but that the developer has also tested it themselves and continue to hold the software to this standard.

Valetudo has well documented releases every few months with breaking changes documented, and can also update itself in the UI. Newer versions may have UI updates, bug fixes, but more importantly support for newer robots.

Using it

To use Valetudo, you simply go to it’s web UI, which is accessible via your robots private IP, or by port forwarding to the web server on the machine via SSH. The web UI offers you control of your robot like you would in a native app.

Of course it can integrate with systems like Home Assistant via it’s MQTT client, which will then allow you to control it via Home Assistant with various integrations. At the moment, I use this card to control my robot in Home Assistant.

Why/why not

I’m not going to write about why or why not to use Valetudo. If this got your interest, read the below pages, and the surrounding documentation on the Valetudo website:

My rooting journey

I followed the Dreame fastboot instructions for both my Dreame L10s Ultra’s. The robot is slowly approaching end of life so I was lucky to get it on sale. I couldn’t easily obtain the Valetudo rooting PCB board so I used some dupont cables and an old USB mouse with a USB 2.0 cable (rip mouse). It worked OK minus some USB 2.0 shenanigans. If I could do it again, I would put the effort in to obtain the PCB board as I probably wasted 2 hours getting the USB connection to work correctly.

I previously had a Roborock S6 MaxV which I couldn’t root and faced many issues getting the Home Assistant integration working. Occasionally the vendor would rate limit my Home Assistant integration or change their API, meaning I’d have to wait for the maintainer of the integration to address the issue. I’ve not faced any issues with my L10s Ultra and Valetudo due to its native MQTT client and Home Assistant support. The robot has not skipped a beat and is far more responsive than my previous vendor cloud locked Roborock. I also have no internet calls coming out of my robot (using a NTP server on my LAN), so I’m super pleased with that.

What’s upcoming in the community?

In Dennis Giese’s recent talk he covered Ecovacs vacuums. The root method for many models is now public, however there is no Valetudo support for them right now. Please do not ask the maintainers when they will supported. We can only hope there’ll be Valetudo support in the future or a cloud replacement for these robots.

Update

I spent a month hacking my Ecovacs X1 Omni. I published some notes and a forked version of Valetudo which works on my robot.

See the links below:

My workflow philosophy

Sun, 12 May 2024 00:00:00 +0000

Introduction

This is a overview of my “workflow”, a really long rant on how I deal with technology choices related to my workflow, and why I do things “my way”. I’m hoping somebody will find this useful in making their choices.

I’m also writing this as a preface for my future blog posts where I discuss part of my workflow. I’ll keep the below updated with links as they come out:

Working anywhere with SSH, FIDO2, and Git (coming soon)

Summary of my workflow

At the moment I use 3 hosts (almost) daily:

my desktop (Linux)
- Windows dual booted for gaming
my personal laptop (Linux)
my work laptop (Linux)

On each hosts, some key technologies:

Arch Linux encrypted with LUKS + btrfs (see Linux Install)
Encrypted self-hosted WireGuard VPN to access most of my hosts, and TailScale for others
I use SSH via FIDO2 to connect to my hosts, copy files
- Alternative “personal” SSH Agent on my work machine to not leak keys from work
Git operations to GitHub, commit signing, all with my FIDO2 key. Works over an SSH connection from another one of my hosts.
File copying with SCP & rsync
VS Code with the Remote SSH extension
- Can do all the operations listed above in the built-in terminal
- and a ton of other extensions to help with my workflow
Neovim
tmux
- Using my custom tmux status bar to give me context of my shell without flooding my prompt
- if I’m working heavily in a shell, then I’ll work in a tmux session over SSH, which means I can resume work from any one of my machines later
Obsidian for note taking
- Notes synced across devices
Same base config and bootstrap across machines, through my dot files, all managed in Git
- the same i3/x11 setup, key bindings, etc
as well as a ton of other programs and utilities
- more mentioned below

I will try write blog posts on each thing above. In the meantime, most of it is in my dot files, or I scribbled about it in my public notes if you’re bold enough to fish them out.

Principles

Generally I try to follow these principles in regards to my workflow. I also follow some of these when I approach new technologies in system design, but not all are mutually exclusive:

1) secure

This is a no-brainer.

Keep in mind, this is rated number one in importance, but not in practice. There’s a fine balance to strike as things must be secure, but still practical and useable.

If I really wanted things to be truly secure, then I would have no computer or smart phone, and only pay in cash. Of course this is not practical.

Some relevant rules I try to follow are:

limited public facing services (e.g. limit exposure of SSH to the internet)
adopt hardware keys where supported (and where not lazy)
where hardware keys are not possible, use a password manager, and other forms of 2 factor
long passwords

These rules are important cause they dictate how I’m able to work. Now in order to work, I should have easy access to hardware keys, and easy access to my non-public facing services.

2) simple and boring

I use a lot of boring technologies. If it’s not boring, then I’ve likely had a good reason to choose it, and have a decent understanding on how it works. I likely understand how the “boring” alternative works in case the “cool” thing I’m using is no longer “cool”.

It’s easy to bet on a bad technology that will no longer be supported or maintained, but it’s even easier to pick a good one. Use proven software that has already solved the problem and has stood the test of time. Software like Linux and GNU.

I’m also generally a slow adopter of new “cool” technology due to being cynical and lazy. Unless I try something for the first time and really think, “wow this is insane, I can’t believe nobody else is using this!”, I’ll probably keep an eye on it and see how it stands the test of time.

If I’m also getting all I need out of something, and I don’t wish to put more time into improving it, why would I risk my current workflow to move to something “cooler”? I call this tactical laziness.

Adopting new technologies takes time and effort. That said, it’s low risk and effort to try something and see what life is like on the other side.

An example is Obsidian. A colleague showed it to me, I was impressed, then it took me a year to switch from my existing workflow with Joplin and VS Code. Why? Cause I had everything set up great already. Linting rules, note sync working, spell checking, and settings I felt were sensible. Everything was just right.

To switch to Obsidian, I needed to migrate my notes, get my sync working, get my settings right, plus learn whatever default / new features are applied by Obsidian and flick things on or off. And the final thing (which will never stop) is to learn how to optimise my workflow with all the new things I can do in Obsidian.

The move to Obsidian has paid off though. It’s made me take more notes and feel better doing it. However, in the year between my colleague showing me Obsidian and when I finally switched to Obsidian, I probably dealt with some more important things short-term things, but I still wish I’d switched sooner.

3) stable, but also have workarounds

Reality is things will catastrophically fail at some stage. If I cannot access to my network via my VPN, do I have another point of access or some form of break-glass?

This cascades from the last point: generally simple things are stable, or simple to troubleshoot and resolve.

4) use my preferred technology where possible

Some examples are:

Linux as a desktop instead of Windows or Mac
Firefox, with a container based workflow so I can continue using the same browser session
- e.g. to login to multiple accounts
- this means i retain my open tabs, hotkeys, extensions, and history
- i may use profiles if different Firefox settings are needed
CLI / terminal
- I love using CLI tools or a terminal over a GUI as you can be more efficient. GUIs are opinionated, can differ between application, and are generally heavier and slower than using a terminal.
open-source tooling over proprietary tooling (where applicable)
- I still use Microsoft’s Visual Studio Code build over the open-source one
VS Code or vim to edit files, and finding ways to integrate more into these editors
Hardware keys instead of 2FA
Unix programs:
- bash
- grep
- cut
- sed
- jq
- fzf to find things

5) fast

Building from my previous point. I want to be fast when working on the computer. If you do things faster, then you can do more things. It’s a superpower, and addicting. Once you get used to being fast you can’t go back to being slow.

Having good, quick tooling, shortcuts / quicker ways of gaining access to something or obtaining information will make you faster than most people.

This doesn’t mean a bleeding edge, fast machine, or a gigabit internet connection. It means spending less time doing or thinking about how to do “crap” (cause you’ve automated it, or figured out you don’t need to do it), and spending that time on more meaningful things.

An example is git aliases, or tools like bash-my-aws. It seems like a gimmick at first, but overall you save a lot of time not typing out the same verbose commands 20 times a day. Once you get used to them, you’ll find yourself using them all the time instead of GUIs, and wanting to use GUIs less.

6) resumable

If I’m working on something I’d like to be able to resume it at any given time on the same machine or another one. This helps me not skip a beat as I may drop what I’m doing to do something else, or move somewhere (e.g. the couch) and want to continue what I was doing quickly.

Examples:

my shell sessions all run tmux, so if I use a different machine I can SSH back in and attach the tmux session and pick up from where I was
my Obsidian vault is synced live across my machines using obsidian-livesync so I can write things on my phone and get it real-time on my machines (and vice-versa).
my cmus sessions resume from where I last used cmus by setting resume=true. See man cmus

7) seamless experience between machines

I find it frustrating when devices or software across machines behave differently. Of course it takes some effort to set up a “settings sync” (built into many modern applications now days), or dot files, but it pays off.

This is why I like hotkeys and config to be consistent across devices. It means I don’t need to think about how I’m using one of my machines, and I just use it.

Working across fundamental barriers (such as operating systems) makes this challenging, but I’ve tried to keep things as seamless as possible.

For example, my i3 setup uses tools like alttab and i3-automark which make it feel a lot like Windows, which I used as my daily desktop operating system until 2022. This makes it easy for me to use a Windows machine again as I’ve not lost all my habits. I also don’t think I’ve made myself slower by doing this. I like to think that I’ve taken the best from Windows and brought it to my tiling window manager workflow.

I also bootstrap my machines the same way with my dot files and my scripts. Even on Windows.

8) consistent experience across applications

I prefer using vim bindings where possible so I don’t need to learn application specific hotkeys. This enables me to use the keyboard more and be more efficient.

Other basic things, like CTRL/ALT+Number to select tabs, CTRL + T to open tabs. I want things to be the same.

9) version controlled

If I’ve set something up I like, it should be in some form version control. And if not version controlled, then documented so I can revisit in the future.

Iterators and Generators in Go

Sun, 21 Apr 2024 00:00:00 +0000

Introduction

Something I’ve found missing in Go is built-in generator functions and an iterator interface. Python & JavaScript both have them and I find myself using them regularly. Having syntactic sugar to express a generator & iterators is great for consistency sake, and also makes them more accessible for implementers.

What are generator functions?

A generator function produces values on the fly or “lazily”, instead of generating them all at once and storing them in memory.

In most languages/implementations, it typically utilises the yield keyword to temporarily suspend execution and “yield” a value to the caller, allowing the function to be resumed later, efficiently maintaining its state.

To a consumer iterating over the function, it behaves similar to a function that returns an array, making it easy to consume.

Generators significantly reduce memory overhead and improve performance where memory constraints are a concern, or when dealing with computationally expensive operations. Iterators created with generator functions facilitate clean and concise code, which improves readability and maintainability.

Go 1.22 rangefunc experiment

Luckily Go 1.22 shipped with a preliminary implementation for function iterators. It can be enabled by setting GOEXPERIMENT=rangefunc when building your Go program.

Using VS Code? Add this to your settings.json to fix the errors displayed:

"go.toolsEnvVars": {
 "GOEXPERIMENT": "rangefunc"
}

I’ve been using it the past month and found it pleasant. Below I’ll quickly explain the interface and also show some examples.

the simplest generator

A generator function which yields integers would have this interface:

func (yield func(int) bool)

Where the function will call the exposed yield function to “yield” results, and return to complete.

Below is an example of the above function prototype with a rate limited fibonacci generator

package main

import (
 "fmt"
 "time"
)

func Fibonacci(yield func(int) bool) {
 a, b := 0, 1
 for {
 a, b = b, a+b
 if !yield(a) {
 return
 }
 }
}

func main() {
 for num := range Fibonacci {
 fmt.Println(num)
 time.Sleep(200 * time.Millisecond)
 }
}

checking the return value of `yield()`

Why must we check the return value of yield() ? This is how the generator knows it should stop yielding values, and can clean up anything before ending execution by returning. If the function ignores the return value of yield() and continues it will panic.

yielding an error

We can also yield up to two values (but no more than 2!)

e.g:

func (yield func(int, error) bool)

This makes it great for returning errors in our second argument, then the generator can clean up any resources and return to complete execution.

what about parameters?

The generator function prototype above does not allow you provide any parameters, which in most situations would be pretty useless. Fortunately the new iter package returns iter.Seq and iter.Seq2 types, which you can use in a parent function to return your iterator.

A simple example which yields the same string parameter (with value ahh) ten times looks like this:

func Generate(value string) iter.Seq[string] {
 return func(yield func(string) bool) {
 for i := 1; i <= 10; i++ {
 if !yield(value) {
 return
 }
 }
 }
}

func main() {
 for x := range Generate("ahh") {
 fmt.Println(x)
 }
}

an example with http

Here’s an example hitting a paginated HTTP endpoint and yielding the data. Errors also yield back to the consumer stop execution.

package main

import (
 "encoding/json"
 "fmt"
 "iter"
 "net/http"
)

type Pokemon struct {
 Name string `json:"name"`
 URL string `json:"url"`
}
type APIResponse struct {
 Count int `json:"count"`
 Next *string `json:"next"`
 Previous *string `json:"previous"`
 Results []Pokemon `json:"results"`
}

func Generate(limit int) iter.Seq2[Pokemon, error] {
 return func(yield func(Pokemon, error) bool) {
 var data APIResponse
 url := fmt.Sprintf("https://pokeapi.co/api/v2/pokemon?limit=%d&offset=0", limit)
 for {
 response, err := http.Get(url)
 if err != nil {
 yield(Pokemon{}, err)
 return
 }

 err = json.NewDecoder(response.Body).Decode(&data)
 response.Body.Close()
 if err != nil {
 yield(Pokemon{}, err)
 return
 }
 for _, pokemon := range data.Results {
 if !yield(pokemon, nil) {
 return
 }
 }

 if data.Next == nil {
 break
 }
 url = *data.Next
 }
 }
}

func main() {
 for pokemon, err := range Generate(10) {
 if err != nil {
 panic(err)
 }
 // stop anytime
 fmt.Println("Name:", pokemon.Name, "URL:", pokemon.URL)
 }
}

jfx's site

Moving to Podman Quadlets

Prelude

Introduction

Enter Quadlets

What are Quadlets?

Availability

Getting started with Quadlets

Moving to Quadlets

Handling upgrades

How things are a month later

See also

My KVM is better than yours

Introduction

Handling USB

Handling Displays

Integrating USB and Display

A simpler alternative

Conclusion

The code

Engineering project management

Introduction

A showcase

Always be an Engineer

See also

Debugging my stupidity with mitmproxy

Introduction

The problem

Enter mitmproxy

Enter mitmwrap

Getting to the bottom of my cloning issue

How did this happen

Reflecting

The plugin

See also

WebAuthn in the CLI

Introduction

Deep dive into WebAuthn

Summary

Input

Output

Inspecting webauthn.io

Writing some code

Piecing it all together

Handling WSL

Conclusion

See also

VS Code to Neovim

What is Vim and Neovim

Vim

Neovim

Learning Vim

Switching over

Trying out presets

Struggling with distributions

kickstart

My setup

Configuration

Screengrabs

Working remotely

VS Code key bindings

Session Management

Things to improve

Conclusion

See also

Homelab & Mikrotik inspection network

Introduction

Building it out

Mikrotik

Ubiquiti

VM

Software

mitmproxy

dnsmasq

tcpdump

Setting capturing up

Tying it all together

SSH ProxyJump

network capture script

socat & dnsmasq

checking the return value of `yield()`