x2q

bchunk — convert .bin/.cue images to .iso and .wav on Linux and macOS

2026-04-22T00:00:00+00:00

TL;DR —</strong> bchunk</code></strong> — sometimes called binchunker</code></strong> — is a small, old, Unix command-line tool that takes a .bin</code>/.cue</code> pair (a raw CD image with a cue sheet) and splits it into a proper .iso</code> file for the data track</strong> and one .wav</code> file per audio track</strong>. It’s the right tool when a download or archive gave you game.bin</code> + game.cue</code> and you actually want to mount the data track</strong> or re-burn the audio tracks</strong>. Install with apt install bchunk</code> on Debian/Ubuntu, brew install bchunk</code> on macOS, or build from source on anything else. Usage is bchunk [options] image.bin image.cue basename</code> — you get basename01.iso</code>, basename02.wav</code>, basename03.wav</code>, and so on.</p>

What .bin/.cue is, and why you’d want to split it</h2> A .bin</code>/.cue</code> pair is a raw, bit-accurate CD image</strong> plus a plain-text sheet that describes the track layout. The .bin</code> contains every sector of the CD back-to-back — including data tracks (Mode 1 or Mode 2), audio tracks (raw Red Book PCM, 2352 bytes per sector, no filesystem), and the gaps between them. The .cue</code> tells you where each track starts and what type it is.</p> This format is the standard output of CD-ripping tools like cdrdao and of old game-preservation scrapes, because it preserves everything</em> — pregaps, CD-TEXT, mixed-mode CDs, CD-DA audio. That’s also why you can’t just rename game.bin</code> to game.iso</code> and mount it: a mixed-mode CD has non-filesystem sectors</strong> at the beginning, audio tracks that aren’t a filesystem at all, and per-sector headers that ISO expects stripped.</p> bchunk</code> does the conversion properly:</p> Data tracks</strong> become ISO 9660 files (.iso</code>) — the 2352-byte CD sectors are trimmed to 2048-byte ISO sectors, headers discarded.</li> Audio tracks</strong> become 16-bit stereo 44.1 kHz .wav</code> files, each with a proper WAV header.</li> </ul> After that you can mount -o loop</code> the .iso</code>, play the .wav</code>s, or feed them to a burner.</p> Installing</h2> Debian / Ubuntu / Mint</h3> sudo apt install bchunk </code></pre> macOS (Homebrew)</h3> brew install bchunk </code></pre> Arch / Manjaro</h3> sudo pacman -S bchunk # or from AUR: yay -S bchunk </code></pre> Fedora / RHEL / CentOS</h3> bchunk</code> isn’t in the default repos; get it from RPMFusion or build from source:</p> git clone https://github.com/hessu/bchunk.git cd bchunk make sudo cp bchunk /usr/local/bin/ </code></pre> Windows</h3> Use WSL and apt install bchunk</code>. There’s an old native port but WSL is easier.</p> Basic usage</h2> bchunk game.bin game.cue game </code></pre> Output:</p> game01.iso # data track, mountable as ISO 9660 game02.wav # audio track 1 game03.wav # audio track 2 ... </code></pre> The basename</code> (game</code> in the example) is the prefix for every output file. Track numbers start at 01</code>.</p> Useful options</h2> bchunk</code> has a small, stable set of flags — most of them are there to handle specific CD quirks.</p> -v</code></strong> — verbose. Prints each track as it’s processed. Use this the first time you run it to confirm you’re getting the track layout you expect.</li> -w</code></strong> — write .wav</code> files (default). Explicit form.</li> -r</code></strong> — raw audio output instead of .wav</code>. Useful if you’re piping into sox</code> or ffmpeg</code> and don’t want a second header-stripping step.</li> -p</code></strong> — Psx/PlayStation mode</strong>. Treats Mode 2 sectors more loosely — needed for many PlayStation CD images where the cue sheet is imprecise.</li> -s</code></strong> — swap byte order on audio tracks. Needed if the .bin</code> was produced by a ripper that wrote little-endian audio where bchunk</code> expects big-endian (or vice versa). Symptom: output .wav</code> sounds like white noise.</li> -W</code></strong> — write .wav</code> with a verified (rather than computed) header size. Rarely needed.</li> -E</code></strong> — use the exact track boundaries from the cue sheet rather than probing. Use this if audio tracks sound clipped at the beginning or end.</li> </ul> Mounting the resulting .iso</h2> On Linux:</p> sudo mkdir /mnt/cd sudo mount -o loop game01.iso /mnt/cd ls /mnt/cd </code></pre> On macOS:</p> hdiutil attach game01.iso </code></pre> Common gotchas</h2> “Illegal or unsupported track type” or empty output</h3> Your cue sheet is malformed or references a .bin</code> size that doesn’t match. Open the .cue</code> in a text editor — it’s plain text — and check:</p> The FILE "..."</code> line points at the right .bin</code> filename, case-sensitive.</li> TRACK</code> entries are numbered sequentially with types MODE1/2352</code>, MODE2/2352</code>, or AUDIO</code>.</li> Index entries (INDEX 00</code>, INDEX 01</code>) are MM:SS:FF, with FF being frames (0–74).</li> </ul> Audio tracks sound like static</h3> Byte order mismatch. Retry with -s</code>:</p> bchunk -s game.bin game.cue game </code></pre> Single .iso</code> is fine, but audio tracks are silent or truncated</h3> Try -E</code> to force cue-sheet-exact boundaries:</p> bchunk -E game.bin game.cue game </code></pre> PlayStation/PSX image won’t split cleanly</h3> Use -p</code>:</p> bchunk -p psx.bin psx.cue psx </code></pre> This is the most common complaint on forums — PSX cues are almost always Mode 2 and bchunk</code> without -p</code> is strict about them.</p> Multiple .bin</code> files referenced in the cue</h3> Some rippers produce one .bin</code> per track plus a combining cue sheet. bchunk</code> expects one .bin</code> for the whole disc. Concatenate them first with cat track01.bin track02.bin ... > combined.bin</code> and point a single-file cue at combined.bin</code>.</p> Alternatives worth knowing</h2> cdemu</code></strong> — user-space CD emulator for Linux. Can mount a .bin</code>/.cue</code> directly without splitting. Useful if you just want to read</em> the data track temporarily.</li> ecm-tools</code></strong> — different format (.ecm</code>), but same problem space. Worth knowing if you encounter it.</li> 7z</code> / p7zip</code></strong> — newer 7-Zip versions can list and extract ISO 9660 data tracks from a raw .bin</code>, but can’t recover audio as .wav</code>.</li> ffmpeg</code></strong> — if you want MP3 / FLAC / Opus instead of .wav</code>, pipe the raw output: bchunk -r game.bin game.cue game && ffmpeg -f s16be -ar 44100 -ac 2 -i game02.raw game02.flac</code>.</li> </ul> Why it’s still useful in 2026</h2> Optical-media imaging has been a solved problem for decades, but .bin</code>/.cue</code> is still the default output of cdrdao</code>, still what old archives are stored as, and still what shows up when someone hands you a CD backup that isn’t an ISO. bchunk</code> is a ~1,000-line C program, written in the late 1990s, that does one job correctly and has barely changed in twenty years. It’s in every major distribution, it compiles cleanly on modern systems, and it’s the right tool.</p> If you’re trying to recover data from an old CD image: start here.</p>

binlist.net — how a Fuerteventura holiday side-project became iinlist.com 2026-04-22T00:00:00+00:00 TL;DR —</strong> binlist.net</a> is a free HTTP API</strong> that takes the first 6–8 digits of a credit card number (the BIN</strong> or IIN</strong>) and returns the issuing bank, country, card scheme (Visa, Mastercard, etc.), card type (debit/credit/prepaid), and category. I started it in August 2013 on a holiday in Fuerteventura</strong>, because I needed a BIN lookup for another project and everything that existed was either paywalled, stale, or behind a sketchy scraper. It was my first ever Go project</strong>, hit 100,000 queries/day</strong> within weeks, and crossed 1 million queries/day in 2015</strong>. It is still online, still free, still curl</code>-friendly. The commercial variant, iinlist.com</a>, is what I co-founded after binlist.net’s success; it’s the same idea with payment-industry-grade accuracy</strong>, 8-digit IIN support</strong> (mandated by ISO/IEC 7812 since 2022), ARDEF-backed ranges</strong>, and an SLA — built for banks, PSPs, fraud teams, and issuers who need to treat BIN data as production data.</p> BIN vs IIN — a one-paragraph primer</h2> The first six (historically) or eight (since 2017, mandatory 2022) digits of a card number are the Issuer Identification Number</strong> (IIN). The old name, still widely used, is Bank Identification Number</strong> (BIN). Given a BIN/IIN, you can determine:</p> Scheme / network</strong> — Visa, Mastercard, Amex, Discover, JCB, UnionPay, Diners.</li> Issuer</strong> — the bank or fintech that issued the card.</li> Country</strong> — country of the issuer, which is not necessarily the cardholder’s country but is a useful proxy for risk scoring, tax logic (EU/EEA VAT MOSS), and user experience (preferred language, local payment methods).</li> Type</strong> — debit, credit, prepaid, deferred debit, charge.</li> Category / product</strong> — Classic, Gold, Platinum, Business, Corporate, etc. Useful for acceptance cost routing (commercial cards cost more to accept).</li> </ul> All of this is “sensitive” in the sense that issuers don’t publish full BIN tables and card schemes consider them proprietary. In practice, BIN ranges leak constantly — every authorisation the scheme routes, every chargeback dispute — and there’s a whole cottage industry around keeping reasonably accurate BIN tables.</p> Why I built binlist.net on holiday</h2> Summer 2013. Playitas, southern Fuerteventura</strong> — the resort on the Atlantic side down by Gran Tarajal. Rented apartment, small balcony, Canary wind doing its thing. I had an idea for a side-project that needed to look up cards by BIN and I did not want to pay a payments vendor €200/month for it. The existing free options were:</p> Wikipedia’s IIN list</strong> — reasonably accurate for well-known schemes, woefully incomplete for niche issuers, updated by volunteers who don’t work in payments.</li> Pasted CSVs on forums</strong> — decent coverage for US issuers, always outdated.</li> Google Fusion Tables</strong> — deprecated by Google that same year.</li> Scrapers of merchant-bank lookup forms</strong> — ToS-violating, brittle.</li> </ul> What I wanted was curl http://example.com/40012345</code> returning clean JSON. So I built it.</p> The stack (then)</h3> This was my first ever Go project</strong>. I’d been reading about Go for a while and wanted a small, well-scoped excuse to try it; a single-endpoint JSON API over an in-memory BIN table was perfect. Ruby/Sinatra would have been faster for me to type, but I wanted to learn something, and the memory and latency characteristics of a Go binary turned out to be exactly what a free-tier public API needed.</p> Go</strong> — a single binary, net/http</code>, no framework. The whole server was a few hundred lines.</li> In-memory BIN range table</strong>, built at boot from a ~300 MB source file. Lookups were O(log n) over a sorted slice.</li> Deployed on a single Hetzner VM</strong> from day one (I briefly considered Heroku but Heroku’s free dyno memory limits didn’t fit a fully-loaded BIN table).</li> JSON + XML + CSV</strong> response formats, because 2013.</li> Data seed</strong> from a combination of public Wikipedia scrapes, the old “Mars Base” CSV from 2009, and a set of ranges I’d been accumulating at work.</li> </ul> Total build time on that balcony: a weekend — about half of which was me figuring out go build</code>, GOPATH</code> (Go modules didn’t exist yet), and how interfaces worked. I bought the domain on the Monday, deployed the binary, and tweeted about it.</p> Traffic curve</h3> Week 1:</strong> a few hundred queries/day, mostly me testing.</li> Month 1:</strong> ~100,000 queries/day</strong> after developers on Stack Overflow and a couple of e-commerce forums found it.</li> By early 2015:</strong> crossed 1 million queries/day</strong> sustained, with spikes above 2M during flash-sale events on merchants that called it on every checkout page-load.</li> </ul> Scaling to that point cost almost nothing because Go’s single-binary footprint meant a ~€5/month VPS handled the whole thing; the bottleneck for a long time was the NIC, not CPU or memory.</p> 13 years later</h3> binlist.net still runs. It has migrated infrastructure a few times — Hetzner VM → Hetzner fleet → a small fleet behind Cloudflare — and the data seed has been continuously updated, but the API surface (and most of the original Go code) is the same. Today it serves tens of millions of lookups per month</strong>, free, no API key required, with a soft rate limit on anonymous callers to keep it honest.</p> It has ~2,000 Google impressions/month</strong> for queries like “binlist”, “bin list bank identification number”, “list of bank identification numbers” — still picking up the long tail of developers who type the same question I typed into Google in 2013.</p> Why iinlist.com exists</h2> binlist.net’s data is good enough for “what country is this card from” decisions — risk scoring, currency presentation, analytics. It is not</strong> good enough for:</p> Acceptance-cost routing</strong> where you route commercial-card transactions through a different processor.</li> Interchange++ modelling</strong> where the margin difference between Classic and Platinum Mastercard is real money.</li> Scheme compliance</strong> — the ISO/IEC 7812 migration from 6-digit BINs to 8-digit IINs, mandated 2022, broke a lot of “I’ll just use the first six digits” logic.</li> Co-badged cards</strong> (e.g. Dankort + Visa Debit) where two networks both claim the card and the routing decision is business-critical.</li> ARDEF-grade accuracy</strong> — Visa’s Account Range Definition File is the source of truth; you really do want data derived from ARDEF for anything production-grade.</li> </ul> iinlist.com solves these, commercially. I co-founded it with a small team of people who know payments data professionally. It’s the product binlist.net is the free-tier advertisement for. Some of our customers are names you’d recognise; most are not. All of them eventually reach the same conclusion: BIN data that’s “mostly right” costs more in wrong decisions than accurate data costs in licence fees</strong>.</p> What iinlist.com is, specifically</h3> 8-digit IIN support</strong> across all schemes.</li> Daily updates</strong>, derived from ARDEF + scheme feeds + issuer announcements + internal verification.</li> Richer enrichment</strong>: card type, product category, issuing country, issuer branding, regulatory classifications (commercial vs consumer, prepaid flag, etc.).</li> SLA and support</strong>. You can file a ticket and it will actually reach a human.</li> On-prem / self-hosted option</strong> for customers whose compliance doesn’t allow “BIN lookup as a third-party API call in the authorisation path”.</li> Pricing</strong> that makes sense for both a scrappy fintech (monthly plan) and an established acquirer (annual, unlimited).</li> </ul> Can I just use binlist.net commercially?</h2> You can use binlist.net however you want; there’s no gate. But:</p> There’s no SLA, no uptime guarantee, and no contract. It’s a side project that happens to have stayed up for 13 years.</li> Rate limits on anonymous traffic will kick in at production volume. Buy a licence from iinlist.com and the problem is solved.</li> If your regulator asks where your BIN data comes from, “a free API my developer found” is not the answer you want to give.</li> </ul> For anything hobby, demo, or prototype: binlist.net is perfect. For anything where wrong BIN data becomes someone’s KPI: iinlist.com.</p> Using binlist.net today</h2> $ curl -sH "Accept-Version: 3" https://lookup.binlist.net/45717360 { "number": { "length": 16, "luhn": true }, "scheme": "visa", "type": "debit", "brand": "Visa/Dankort", "country": { "numeric": "208", "alpha2": "DK", "name": "Denmark", "emoji": "🇩🇰", "currency": "DKK", "latitude": 56, "longitude": 10 }, "bank": { "name": "Jyske Bank A/S", "url": "www.jyskebank.dk", "phone": "+4589893300", "city": "Silkeborg" } } </code></pre> Accept-Version: 3</code></strong> — pins to API v3.</li> Anonymous rate limit</strong> — documented on the site, plenty for casual use.</li> Zero warranties</strong> — if the response is wrong, submit a correction on the GitHub repo. For commercial guarantees, see iinlist.com.</li> </ul> FAQ</h2> Is BIN / IIN data regulated?</h3> BIN ranges themselves are not personal data under GDPR — a BIN identifies an issuer, not a person. Combining a BIN with a full card number is a different story and falls under PCI-DSS.</p> What changed with the 8-digit IIN migration?</h3> ISO/IEC 7812 formalised 8-digit IINs in 2017 with a hard migration deadline in April 2022 for the major networks. If your code still treats only the first six digits as the issuer identifier, you’re silently misrouting a growing share of traffic — modern Visa and Mastercard issuer ranges are defined at 8 digits.</p> Why not just look it up client-side?</h3> You can, with a static list in the browser. But you’ll accept a trade-off: freshness (the static list will be out of date within weeks) or bundle size (the current BIN table is megabytes uncompressed). A server-side API is the conventional answer.</p> Does binlist.net log the BINs I query?</h3> Aggregate analytics only — enough to detect abuse and rate-limit. Individual queries are not associated with a user. iinlist.com has a stricter no-logging posture for customers where that matters.</p> Is the source code open?</h3> The API surface of binlist.net is on GitHub, with contribution guidelines for data corrections. The data ingestion pipeline is not open-source; it relies on scheme feeds that require licences.</p> Are binlist.net and iinlist.com the same company?</h3> Separate projects, overlapping origins, same operator on my side. binlist.net is a personal free service; iinlist.com is a commercial company with co-founders and employees. The two are operationally independent but share institutional knowledge about BIN data that is not easy to accumulate from scratch.</p> Thirteen years in</h2> The thing I find most interesting about binlist.net is not the traffic — it’s the kind of questions</strong> developers are still typing into Google in 2026: “what is a bin list”, “bin number example”, “list of issuer identification numbers”. These are the exact queries I was typing in 2013 on that balcony in Playitas. Payments as an industry keeps adding layers, but the foundational questions don’t change.</p> If you’re sitting on a beach with a laptop and you have an itch for a side-project that scratches your own back, go build it — and while you’re at it, try the language you’ve been meaning to learn. Sometimes it turns out a lot of people have the same itch, and thirteen years later you have a useful thing to point them at and a working knowledge of Go.</p> My CM3588 project — a 4-NVMe ARM64 home NAS on 10 W idle 2026-04-22T00:00:00+00:00 TL;DR —</strong> The FriendlyElec CM3588 NAS Kit</a> is an RK3588-based compute module on a carrier board with four M.2 NVMe slots (PCIe 3.0 x1 each)</strong>, 2.5 GbE</strong>, 2× HDMI out</strong>, USB 3.0</strong>, and an 8- or 16-core ARMv8 CPU (4× Cortex-A76 + 4× Cortex-A55). Fully loaded with four NVMe drives it idles at about 10 W</strong>, peaks around 20 W under heavy I/O, and reads/writes an NVMe at roughly 1 GB/s (the bus limit, not the drive). My own unit runs Debian on the mainline kernel, with ZFS on root, four 2 TB NVMe drives in a raidz2</code> pool, Samba for LAN shares, and Tailscale for off-LAN access. It has replaced a tower PC running TrueNAS and cut NAS power draw by about 60 W.</p> Why this board</h2> I’d been running a tower PC as a home NAS for years: a second-hand desktop, six 3.5“ spinning disks, and a noisy fan. It worked, but it was using 70–80 W idle and sitting in a cupboard that needed active ventilation. The disks were loud enough that I’d moved them to the far corner of the house.</p> Three things I wanted from a replacement:</p> NVMe-only.</strong> Spinning disks are cheaper per terabyte but the noise, vibration, and heat aren’t worth it for a home NAS sized in the single-digit terabytes. 4× 2 TB NVMe is plenty.</li> ARM, for the power draw.</strong> An x86 board with 4× PCIe slots wired to NVMe would pull 30–40 W idle. ARM can do it in 10.</li> Mainline Linux, not a vendor fork.</strong> I want apt-get dist-upgrade</code> to work, zfs</code> to compile from DKMS against a current kernel, and no three-year-old vendor BSP.</li> </ol> The CM3588 NAS Kit hits all three.</p> Hardware</h2> SoC:</strong> Rockchip RK3588 (4× Cortex-A76 @ 2.4 GHz + 4× Cortex-A55 @ 1.8 GHz, Mali-G610 GPU, 6 TOPS NPU). ARMv8.2-A.</li> RAM:</strong> 8 GB LPDDR4X on the module I bought. 16 GB and 32 GB variants exist.</li> Storage:</strong> 64 GB eMMC on-module for OS + 4× M.2 Key-M 2280 slots, each PCIe Gen 3 x1</strong> (so ~1 GB/s per slot, not x4).</li> Network:</strong> 1× 2.5 GbE (Realtek RTL8125B).</li> USB:</strong> 2× USB 3.0 Type-A, 1× USB 3.0 Type-C (DisplayPort alt-mode), 1× USB 2.0.</li> Video:</strong> 2× HDMI out, 1× HDMI in</strong> (RK3588’s capture block).</li> Power:</strong> 12 V barrel jack. A 60 W brick is more than enough.</li> </ul> The board is small — roughly 10 × 10 cm — and passive over the SoC plus a small fan blowing across the NVMe drives. Mine sits flat on a shelf without a case.</p> NVMe compatibility caveat</h3> The one gotcha worth knowing: the CM3588 NAS Kit is not compatible with some WD Blue SN580 and WD Black SN850 drives</strong> — the linkup flaps at boot. I use Samsung 990 EVO and Crucial P3 Plus; both are fine. Check the FriendlyElec wiki compatibility list before buying NVMe drives.</p> OS and filesystem</h2> I run Debian 13 (trixie)</strong> with the mainline kernel</strong> — RK3588 support is good enough from 6.8 onwards for headless use. The FriendlyElec-provided Debian image works out of the box, but I reinstall on top of it to get a clean Debian rather than their BSP.</p> Root filesystem:</strong> ext4</code> on eMMC.</li> Data pool:</strong> zfs</code> raidz2</code> across the four NVMe drives. With 4× 2 TB, raidz2</code> gives ~3.5 TB usable with two-disk redundancy. Yes, raidz2</code> on four drives is conservative; it also means a double failure doesn’t eat the pool, and on NVMe the rebuild is fast enough that I don’t lose sleep.</li> ZFS module:</strong> DKMS against the running kernel. Rebuilds automatically on kernel upgrades. Has worked without manual intervention across three kernel bumps.</li> ARC tuning:</strong> Capped at 2 GB. This leaves headroom on an 8 GB system.</li> </ul> Throughput is bottlenecked by 2.5 GbE for network I/O (~280 MB/s sustained) long before ZFS or the NVMe drives break a sweat. Local operations on the pool hit around 2 GB/s aggregate sequential read.</p> Services</h2> Kept deliberately simple:</p> Samba</strong> for SMB shares to the Macs and Windows box on the LAN.</li> rsync + cron</strong> for nightly backups from three other machines.</li> ZFS snapshots</strong> every hour, retained for a week. zfs send</code> pipes the dataset weekly to an off-site B2 bucket via zfs-autobackup</code> + rclone.</li> Tailscale</strong> for off-LAN access. No port-forwarding, no dyndns, no VPN concentrator. SSH and Samba both ride the Tailscale interface when I’m away.</li> Cockpit</strong> for the occasional “why is the fan loud” dashboard moment.</li> </ul> That’s it. No Docker swarm, no Kubernetes, no dozen sidecar containers. The board does one job — serve files on the LAN and let me pull backups off-site — and it does it quietly.</p> Power and noise</h2> Idle</strong> (all four NVMe spun up, no traffic): ~10 W</strong> at the wall.</li> Busy</strong> (NVMe read saturating 2.5 GbE, ZFS ARC warm): ~18–20 W</strong>.</li> Peak</strong> (scrub across the whole pool, all cores hot): ~25 W</strong>.</li> </ul> Compared to the 70–80 W tower it replaced, the ROI on electricity alone is about 500 kWh/year</strong>, or roughly 1,500 kr/year</strong> at Danish residential rates. The board paid for itself in about a year.</p> Noise: effectively inaudible from more than a metre away. The fan is small and 80% of the time it’s barely spinning.</p> What didn’t work, or took effort</h2> Vendor kernel.</strong> The FriendlyElec-shipped kernel is FriendlyElec’s fork of 6.1 with RK-specific patches. It works for their turnkey NAS image, but DKMS ZFS builds are painful against it. Moving to mainline fixed this.</li> HDMI capture.</strong> The RK3588 has a hardware HDMI input block. In mainline it’s still experimental. I have a rough use case for it (pulling a signal from an old device for archival) but haven’t made it work end-to-end. Parked for now.</li> NPU.</strong> The 6 TOPS NPU is underused. Mainline has basic RKNPU support but for anything practical you still need FriendlyElec’s rknn-toolkit2</code>. Not a blocker for a NAS.</li> </ul> FAQ</h2> Why not x86?</h3> An x86 mini-PC with 4× NVMe is ~2× the idle power and ~2× the purchase price (once you include the case, PSU, and CPU). For a home NAS where the workload is “serve files” rather than “run 40 containers”, ARM wins.</p> Why not Raspberry Pi 5?</h3> The Pi 5 has one PCIe 2.0 x1 lane exposed via an HAT — you can bolt on an NVMe, but only one, and at ~500 MB/s ceiling. The CM3588 has four lanes at PCIe 3.0 wired directly. Different class of board.</p> Why not OpenMediaVault or TrueNAS?</h3> Both would work. I prefer plain Debian + Samba + ZFS because the upgrade path for Debian is well-known to me, and OMV/TrueNAS are a layer I’d have to re-learn. Your mileage will vary.</p> Why raidz2</code> on four drives and not mirror + mirror</code>?</h3> I considered it. mirror + mirror</code> gives you faster writes and easier expansion but only 4 TB usable from 4× 2 TB, same as raidz2</code>. With raidz2</code> any two drives can fail; with striped mirrors you can lose two drives, but only if they’re in different mirror pairs. On four drives the capacity is identical and raidz2</code> has the stronger failure tolerance.</p> Can it run Plex / Jellyfin?</h3> Yes, and the RK3588’s hardware H.265/VP9/AV1 decode block does the heavy lifting. Jellyfin with rkmpp</code> accelerated decoding handles 4K HEVC transcodes at about 3× realtime. I don’t run either on this box — my Plex lives elsewhere — but it’s viable.</p> Does it suspend?</h3> Not reliably. Leave it on; idle is 10 W anyway.</p> What about noise and heat in summer?</h3> Passive heatsink plus one small fan. In a Danish summer (20–25 °C ambient) it tops out around 55 °C die temp under a ZFS scrub. No throttling I’ve measured.</p> Verdict</h2> If you want a quiet, low-power, all-NVMe home NAS with enough PCIe to matter</strong> and you’re willing to spend an evening on Debian + ZFS, the CM3588 NAS Kit is the best option I’ve found. It’s not the cheapest — a second-hand Optiplex is cheaper upfront — but on three-year TCO including electricity it pays back clearly.</p> The RK3588 itself is a surprisingly capable SoC for homelab workloads. Once mainline kernel support landed, I stopped treating it as “an ARM curiosity” and started treating it as a default answer for small always-on servers.</p> Two years in, mine has been rebooted twice (once for a kernel upgrade, once because I moved the shelf). I’d buy it again.</p> fcrackzip — recover lost zip passwords on Linux, macOS, and Windows (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> fcrackzip</code></strong> is a free, open-source command-line tool for recovering the password of an encrypted .zip</code> file. It supports brute-force</strong> (over a user-defined charset and length) and dictionary</strong> attacks, works on Linux/macOS/WSL, and is the right first tool when you need to recover a forgotten password on a zip you legitimately own. It is only fast against classic ZipCrypto</strong> encryption; for the newer AES-256</strong> zip profile, fcrackzip</code> will not work — you want zip2john</code> + hashcat</code> instead. Install with apt install fcrackzip</code> (Debian/Ubuntu), brew install fcrackzip</code> (macOS), or build from source.</p> This post walks through the practical cases. It assumes you have authorisation to recover the password</strong> — your own files, a client’s, a CTF. Don’t use it against zips you don’t own.</p> Install</h2> # Debian / Ubuntu / Mint / Kali sudo apt install fcrackzip # macOS (Homebrew) brew install fcrackzip # Arch / Manjaro sudo pacman -S fcrackzip # Windows # Use WSL2 + Ubuntu and `apt install fcrackzip`. # A native .exe exists but is old — WSL is simpler. # From source git clone https://github.com/hyc/fcrackzip.git cd fcrackzip && ./configure && make sudo cp fcrackzip /usr/local/bin/ </code></pre> Check what kind of encryption your zip uses first</h2> fcrackzip</code> only handles classic ZipCrypto</strong> (the original, weak PKZIP encryption). For modern AES-128 / AES-256</strong> zips (introduced by WinZip 9 in 2003, now default in some tools), fcrackzip</code> will silently fail to find the password no matter how long you run it.</p> Quickest check with zipinfo</code>:</p> $ zipinfo -v archive.zip | head -40 </code></pre> Look for WinZip AES encryption, strength 3</code> (= AES-256). If you see that, skip to the hashcat section.</p> Or with 7z</code>:</p> $ 7z l -slt archive.zip | grep -i 'method\|encrypted' Method = ZipCrypto Store ← fcrackzip works Method = AES-256 Deflate ← fcrackzip will NOT work </code></pre> Basic brute-force</h2> fcrackzip -v -b -c 'a1' -p aaaa -u archive.zip </code></pre> -v</code></strong> — verbose.</li> -b</code></strong> — brute-force mode.</li> -c 'a1'</code></strong> — charset. a</code> = lowercase a–z</code>, A</code> = uppercase, 1</code> = digits, !</code> = printable symbols. Combine: 'aA1!'</code> = all printable ASCII (94 chars).</li> -p aaaa</code></strong> — starting password (defines minimum length = 4 here).</li> -u</code></strong> — only report if the decrypted file “unzips” cleanly (filters false positives — ZipCrypto has a small CRC that many random passwords pass).</li> </ul> Length: -p aaaaa</code> starts at 5 characters. fcrackzip</code> doesn’t have a --max-length</code> flag; it increments the starting password through the charset forever, so letting it run to “completion” at length 8 on the full printable ASCII charset is about 94⁸ ≈ 6×10¹⁵ candidates</strong> — not realistic. You bound the attack by picking a reasonable max charset + length, or by using a dictionary.</p> Dictionary attack</h2> fcrackzip -v -D -u -p /usr/share/wordlists/rockyou.txt archive.zip </code></pre> -D</code></strong> — dictionary mode.</li> -p <file></code></strong> — wordlist file, one candidate per line.</li> -u</code></strong> — verify via unzip, as before.</li> </ul> rockyou.txt</code> is the standard 14 M-entry wordlist shipped with Kali and available everywhere. If you have context about the password (it’s someone’s name + year, it’s a project codename), assemble a smaller targeted wordlist — hit rates are usually much higher than any generic list.</p> Speed and what to expect</h2> fcrackzip</code> is single-threaded and CPU-bound. On a modern laptop you’ll see roughly:</p> 10–30 million ZipCrypto attempts per second per core</strong> for a dictionary attack against a typical zip.</li> Brute-force slightly faster because less string I/O.</li> </ul> That makes it fine for:</p> Dictionary attacks</strong> against any reasonable wordlist.</li> Short brute-force</strong> (4–6 chars alphanumeric).</li> </ul> It makes it not fine for:</p> Length 8+ with symbols</strong> — you’ll never finish.</li> AES-256 zips</strong> — wrong tool.</li> </ul> When to reach for hashcat instead</h2> If fcrackzip</code> is too slow, or the zip is AES-encrypted, migrate to hashcat</code>. It’s the general-purpose password-cracking tool, GPU-accelerated, and handles both ZipCrypto and AES WinZip hashes.</p> Step 1: extract the hash with zip2john</code></h3> zip2john</code> is part of John the Ripper. Ubuntu: apt install john</code>.</p> $ zip2john archive.zip > hash.txt $ cat hash.txt archive.zip:$zip2$*0*3*0*...*$/zip2$::archive.zip:secret.pdf:/path/to/archive.zip </code></pre> Step 2: feed it to hashcat</h3> # ZipCrypto (mode 17200, 17210, 17220, 17225 depending on compression) hashcat -m 17200 hash.txt /path/to/wordlist.txt # AES-encrypted WinZip (mode 13600) hashcat -m 13600 hash.txt /path/to/wordlist.txt </code></pre> On a single modern discrete GPU (e.g. RTX 4090) you’ll see:</p> ZipCrypto: ~5–10 billion H/s</strong></li> WinZip AES-256: ~10–50 million H/s</strong> (much slower because AES is expensive and PBKDF2 iterations are involved)</li> </ul> hashcat’s rule engine, mask attacks (-a 3</code>), and combinator mode (-a 1</code>) make it vastly more flexible than fcrackzip</code>. For anything non-trivial it is the right tool.</p> Common gotchas</h2> “PASSWORD FOUND!!!!: pw == abc” but unzip</code> still asks for a password</h3> You didn’t use -u</code>. fcrackzip’s CRC check has false positives. Re-run with -u</code> to verify candidates against a real decompression attempt.</p> Different files in the same zip have different passwords</h3> Classic PKZIP supports per-file passwords. fcrackzip</code> attacks one file at a time; pass -l <filename></code> (or let it pick the first encrypted one) if you need to be specific.</p> fcrackzip finds the password, but I still can’t unzip</h3> Character set / locale issue. If the password contains non-ASCII characters, the zip’s creator may have used a different encoding than your terminal. Try unzip -P "$(echo -n 'passwd' | iconv -t cp437)" archive.zip</code>.</p> AES-encrypted and dictionary doesn’t find it</h3> hashcat + rules + a targeted wordlist is the move. See the migration steps above.</p> Defensive takeaway</h2> If you’re generating zip files you want to stay encrypted: use AES-256</strong>, not ZipCrypto. Most modern tools (7z</code>, zip</code> from InfoZIP with -e</code>, WinZip, Keka) give you AES if you ask. The default on zip</code> unfortunately is still ZipCrypto on many systems. Check with 7z l -slt archive.zip</code> before shipping it.</p> And pick a password with length, not cleverness. hashcat</code> doesn’t care how weird your substitution pattern is; it only cares about entropy. A four-word passphrase (correct-horse-battery-staple</code>-style, ~44 bits) is fine against offline ZipCrypto attacks; a random 12-character mixed password (~78 bits) is fine against GPU AES attacks. Anything shorter is recoverable.</p> FAQ</h2> Is fcrackzip legal?</h3> Recovering passwords on files you own or are authorised to access is legal in every jurisdiction I’m aware of. Doing it on someone else’s file without authorisation is unauthorised access — the same law that applies to any other computer intrusion.</p> Is fcrackzip maintained?</h3> Barely. The codebase has been stable for fifteen-plus years. For modern work, the combination of zip2john</code> + hashcat</code> has eclipsed it.</p> Can fcrackzip use a GPU?</h3> No. fcrackzip</code> is CPU-only. If GPU is what you have, go straight to hashcat.</p> Does fcrackzip handle .7z, .rar, .gpg files?</h3> No — only classic PKZIP .zip</code>. For .7z</code>, use 7z2john</code> + hashcat (mode 11600). For .rar</code>, rar2john</code> + hashcat (mode 12500 / 13000). For .gpg</code>, gpg2john</code> + hashcat (mode 17010+).</p> How do I generate a targeted wordlist?</h3> hashcat</code>’s maskprocessor (mp64</code>), crunch</code>, and cewl</code> (crawls a site for candidate words) are all worth knowing. For recovering a specific forgotten password, writing down what you remember about it — length, likely words, likely numbers — and building a mask attack from that is the highest-yield approach.</p> Summary</h2> fcrackzip</code> + -D</code> + a wordlist is the right first try.</li> If that doesn’t work and it’s ZipCrypto: fcrackzip</code> + -b</code> with a narrow charset and short length.</li> If that doesn’t work or it’s AES: zip2john</code> + hashcat</code> on a GPU.</li> If that doesn’t work: your password was strong enough. That’s the system working as intended.</li> </ul> pdfcrack — recover lost PDF passwords on Linux and macOS (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> pdfcrack</code></strong> is a command-line tool that recovers the user password</strong> or owner password</strong> of an encrypted PDF by brute-force or dictionary attack. It’s small, written in C, runs on Linux/macOS/WSL, and handles every encryption profile PDF has shipped — 40-bit RC4, 128-bit RC4, 128-bit AES, 256-bit AES (PDF 1.7 + 2.0). It is single-threaded and CPU-only</strong>, so it is fast on the weak old RC4-40 encryption but increasingly slow as PDFs get modern. Install with apt install pdfcrack</code> (Debian/Ubuntu), brew install pdfcrack</code> (macOS), or build from source. When pdfcrack</code> is too slow, switch to pdf2john</code> + hashcat</code></strong> on a GPU.</p> This walkthrough assumes you have authorisation to recover the password</strong> on the PDF — your own document, a client’s, or a legally-acquired file. Don’t attack PDFs you don’t own.</p> User password vs owner password</h2> PDF has two passwords:</p> User password</strong> — required to open and read</strong> the document.</li> Owner password</strong> — required to remove restrictions</strong> (print, copy, modify) on a document that opens without a user password.</li> </ul> Many “protected” PDFs are only owner-password-restricted: they open fine, but printing and copying are disabled by the reader. Those are trivial to unlock — qpdf --decrypt</code> or any of the pdftk</code>-style tools strip owner-only restrictions without needing to guess anything. pdfcrack</code> is for the harder case: a user-password-protected PDF you can’t open at all</strong>.</p> Check which you’re dealing with:</p> $ qpdf --show-encryption document.pdf R = 6 P = -3904 User password = Supplied password is owner password extract for accessibility: allowed extract for any purpose: not allowed print low resolution: allowed print high resolution: not allowed modify document assembly: not allowed modify forms: not allowed modify annotations: not allowed modify other: not allowed stream encryption method: AESv3 string encryption method: AESv3 file encryption method: AESv3 </code></pre> R = ...</code></strong> tells you the revision / profile. R=2</code> = RC4-40, R=3</code> = RC4-128, R=4</code> = AES-128, R=5/6</code> = AES-256.</li> “Supplied password is owner password”</strong> + “User password = (empty)” means you can open it and just need to strip restrictions. Use qpdf --decrypt --password='' input.pdf output.pdf</code> and you’re done.</li> </ul> Install</h2> # Debian / Ubuntu / Mint / Kali sudo apt install pdfcrack # macOS (Homebrew) brew install pdfcrack # Arch / Manjaro sudo pacman -S pdfcrack # Fedora / RHEL sudo dnf install pdfcrack # From source wget https://sourceforge.net/projects/pdfcrack/files/latest/download -O pdfcrack.tar.gz tar xf pdfcrack.tar.gz && cd pdfcrack-* make sudo cp pdfcrack /usr/local/bin/ </code></pre> Benchmark</h2> $ pdfcrack -b Benchmark: Average Speed (calls / second): MD5: 1728972.6 MD5_50 (fast): 97879.3 MD5_50 (slow): 69167.0 RC4 (40, static): 606555.3 RC4 (40, no check): 598050.0 RC4 (128, no check): 590141.7 Benchmark: Average Speed (passwords / second): PDF (40, user): 453510.2 PDF (40, owner): 220250.0 PDF (40, owner, fast): 499995.0 PDF (128, user): 22000.0 PDF (128, owner): 10408.7 PDF (128, owner, fast): 22220.0 </code></pre> Translation:</p> RC4-40</strong> (PDF 1.3, very old) — ~450k passwords/sec. Brute-force of a full 8-character alphanumeric space: ~1 week on one core.</li> RC4-128 / AES-128</strong> — ~22k passwords/sec. Brute-force becomes unrealistic above length 6 with any charset.</li> AES-256 (R=5/6)</strong> — even slower; pdfcrack</code> does support it but effectively only for dictionary attacks against small wordlists.</li> </ul> If you need speed beyond this, you want hashcat</code> on a GPU. Numbers at the bottom.</p> Dictionary attack</h2> pdfcrack -f document.pdf -w /usr/share/wordlists/rockyou.txt </code></pre> -f</code></strong> — target file.</li> -w <file></code></strong> — wordlist, one candidate per line.</li> Optional -o</code></strong> — attack the owner password only (ignore user password). Default is to try user password first.</li> Optional -u</code></strong> — attack user password only.</li> </ul> If you have context — the password is probably a first name, a year, a project code — assemble a smaller targeted list. Generic lists are a long shot once you’re past the top ten thousand entries.</p> Brute-force attack</h2> pdfcrack -f document.pdf -c 'abcdefghijklmnopqrstuvwxyz0123456789' -n 4 -m 8 </code></pre> -c <charset></code></strong> — character set to try. Default includes a broad ASCII range.</li> -n <min></code></strong> — minimum length.</li> -m <max></code></strong> — maximum length.</li> </ul> Tune -c</code> aggressively. If you know the password is all lowercase, don’t give it uppercase. If you know it has a digit at the end, use a mask attack (hashcat territory, not pdfcrack).</p> Resume a long run</h2> pdfcrack -f document.pdf -w rockyou.txt -s /tmp/state.sav </code></pre> -s</code> writes periodic save files; if you kill pdfcrack and restart, pass -l /tmp/state.sav</code> to resume.</p> When to switch to hashcat</h2> For any modern PDF (R=4, 5, or 6 — i.e. AES-128 or AES-256), pdfcrack</code>’s single-core speed becomes the bottleneck. pdf2john</code> + hashcat</code> gets you two to three orders of magnitude more throughput on a GPU.</p> Step 1: extract the hash</h3> $ /usr/share/john/pdf2john.pl document.pdf > hash.txt </code></pre> (On Debian/Ubuntu: apt install john</code> provides pdf2john.pl</code>.)</p> Step 2: identify the hash mode</h3> $ head -1 hash.txt document.pdf:$pdf$5*6*256*-1028*1*16*... </code></pre> Map the first two numbers:</p> $pdf$1*2*...</code> → mode 10400</strong> (PDF 1.1–1.3, RC4-40, user)</li> $pdf$1*2*...</code> with owner salt → mode 10410 / 10420</strong></li> $pdf$2*3*...</code> → mode 10500</strong> (PDF 1.4–1.6, RC4-128 / AES-128)</li> $pdf$5*5*...</code> → mode 10600</strong> (PDF 1.7 r=5, AES-256)</li> $pdf$5*6*...</code> → mode 10700</strong> (PDF 1.7 r=6 / PDF 2.0, AES-256 with PBKDF2)</li> </ul> Step 3: run hashcat</h3> hashcat -m 10700 hash.txt /path/to/wordlist.txt </code></pre> On a single modern GPU (e.g. RTX 4090):</p> Mode 10400 (RC4-40):</strong> ~10 billion H/s — any practical password is recovered instantly.</li> Mode 10500 (RC4-128 / AES-128):</strong> ~100 million H/s.</li> Mode 10700 (AES-256, PBKDF2):</strong> ~50,000 H/s. This is by design — the PBKDF2 iterations make brute-force expensive.</li> </ul> For mode 10700, your attack strategy matters more than raw speed. Dictionary + rules + mask attacks targeted at likely password patterns are orders of magnitude more productive than exhaustive brute-force.</p> Common gotchas</h2> “File seems encrypted but I can still open it without a password”</h3> You’re looking at owner-only restrictions. Use qpdf --decrypt input.pdf output.pdf</code> — no cracking needed.</p> pdfcrack runs but never finds anything</h3> Three likely causes:</p> Password is longer / more complex than your charset × length covers.</strong> Increase -m</code> and/or expand -c</code>, or switch to a dictionary.</li> Password contains non-ASCII characters.</strong> pdfcrack’s charset is ASCII by default; non-ASCII user passwords in old PDFs used varying encodings (PDFDocEncoding, UTF-16). Try pdf2john</code> + hashcat, which handles the encoding properly.</li> It’s AES-256 (R=6) and you’re being patient.</strong> See speed notes above — realistic only with a dictionary.</li> </ol> “Only AES-256 is supported” error or similar</h3> Your pdfcrack</code> build is old. Ubuntu LTS sometimes ships a version that doesn’t fully handle R=6. Build from source or switch to pdf2john</code> + hashcat</code>.</p> PDF opens but printing/copying is blocked</h3> That’s owner-password-restricted only. qpdf --decrypt</code> without needing a password usually works:</p> qpdf --decrypt --password='' input.pdf output.pdf </code></pre> Defensive takeaway</h2> For anything you want to stay encrypted in 2026, use AES-256 with a PDF 2.0 (R=6) password</strong>. That’s the profile with PBKDF2 key derivation that makes offline attacks expensive on current hardware.</p> And, as always, the password’s length matters more than anything else. A 20-character random passphrase is brute-force-intractable against any current GPU. A 6-character “clever substitution” password is a coffee break on an RTX 4090.</p> FAQ</h2> Is pdfcrack still maintained?</h3> Updated slowly. The codebase handles all currently shipped PDF encryption profiles; it just isn’t where performance work is happening anymore (that’s hashcat).</p> Does pdfcrack use GPU?</h3> No. CPU-only, single-threaded. For GPU work, use pdf2john</code> + hashcat</code>.</p> Can pdfcrack recover the document if the creator cleared the user password but kept the owner password?</h3> Yes — use qpdf --decrypt</code> first; if that won’t fully decrypt, pdfcrack -o</code> attacks the owner password.</p> Does pdfcrack leak my PDF anywhere?</h3> No. It’s local. Anything online-only (“crack my PDF at cloud-service-X.com”) involves uploading the file, which you shouldn’t do for confidential material.</p> What if I only vaguely remember the password?</h3> Write down what you remember — likely words, likely digits, likely length — and build a targeted wordlist or hashcat</code> mask (-a 3 ?l?l?l?l?l?d?d?d?d</code>). That beats any generic list.</p> Can I recover text from an AES-256 PDF without the password?</h3> No. AES-256 with PBKDF2 (R=6) is, to the best of public cryptanalysis, not broken. If the password is strong and lost, the contents are lost.</p> Summary</h2> Owner-password-only?</strong> qpdf --decrypt</code>, no cracking needed.</li> User-password-protected, old (R=2/3)?</strong> pdfcrack</code> with a dictionary works fine.</li> Modern (R=4/5/6)?</strong> pdf2john</code> + hashcat</code> on a GPU, targeted attack.</li> Strong 20-character random?</strong> Accept the loss.</li> </ul> Hacking Wi-Fi across 25 years — 2002, 2007, 2012, 2017, 2022, 2027 2026-04-22T00:00:00+00:00 TL;DR —</strong> Wi-Fi security has gone through four generations — WEP</strong>, WPA</strong>, WPA2</strong>, WPA3</strong> — each introduced because its predecessor was broken. This post walks through six snapshots of the state of the art: 2002</strong> (WEP, trivial), 2007</strong> (WEP dead, WPA widespread, offline attacks emerging), 2012</strong> (WPA2 dominant, dictionary attacks on GPUs), 2017</strong> (KRACK breaks WPA2 under the right conditions, PMKID leak in 2018), 2022</strong> (WPA3 rolling out, downgrade attacks, cloud-scale cracking), 2027</strong> (today’s landscape: WPA3 nearly universal, 6 GHz opens new surface, attacks move up the stack). For each year I summarise the attack, the tool, and what a defender should have been doing. Authorised testing only — the defensive guidance at the bottom is the point.</p> At a glance</h2> Year</th> Dominant standard</th> Headline attack</th> Effort to compromise a typical network</th> Fastest dictionary / key-rate at the time</th></tr></thead> 2002</td> WEP (100%)</td> FMS statistical IV</td> ~4M packets / 2–10 h on a busy AP</td> N/A — key recovered from IVs</td></tr> 2007</td> WEP 35%, WPA 25%, WPA2 20%, open 20%</td> PTW + aircrack-ng</td> 40–85k packets / <5 min (WEP)</td> ~50–100 PSK/s (CPU, cowpatty)</td></tr> 2012</td> WPA2 ~70%</td> Reaver (WPS) + GPU PSK dictionary</td> 11,000 WPS PINs / 2–10 h</td> ~75,000 PSK/s (GTX 580)</td></tr> 2017</td> WPA2 ~85%</td> KRACK; then PMKID (2018)</td> 1 packet (PMKID) → offline dict</td> ~400,000 PSK/s (GTX 1080)</td></tr> 2022</td> WPA2 ~60%, WPA3 ~20%, mixed ~15%</td> Dragonblood downgrade</td> Force WPA2 fallback, then GPU/cloud</td> ~1.2M PSK/s (RTX 3090), ~10M (8× A100)</td></tr> 2027</td> WPA3 ~40%, mixed ~35%, WPA2 ~20%</td> Client-side + downgrade + chipset FW</td> SAE intact; legacy WPA2 on borrowed time</td> ~5–8M PSK/s (RTX 5090-era single GPU)</td></tr> </tbody></table> Approximate global deployment shares are from public Wi-Fi surveys (WiGLE aggregate trends + vendor reports); treat as ± 10 points.</p> 2002 — WEP everywhere, and trivially broken</h2> Standard:</strong> IEEE 802.11b with WEP</strong> (Wired Equivalent Privacy). 40-bit or 104-bit RC4 key, 24-bit IV, CRC-32 integrity.</p> What’s wrong with it:</strong> The IV is too small, keys are static, and RC4’s initial key schedule leaks bits of the key when certain IVs are used. These are the FMS attack</strong> (Fluhrer, Mantin, Shamir, 2001) and its descendants.</p> What an attacker did in 2002:</strong> captured traffic with a Prism-based USB adapter, collected a few million packets (hours on an active network), and extracted the key with AirSnort</strong> or WEPCrack</strong>. Attacks were so embarrassing that Wi-Fi Alliance pushed WPA as a temporary firmware-patchable fix in 2003.</p> By the numbers (2002):</strong></p> Global Wi-Fi deployment:</strong> ~100% WEP (WPA not ratified until March 2003).</li> Key length:</strong> 40-bit (export-grade) or 104-bit. Irrelevant — the attack is on the IV, not the key.</li> IV space:</strong> 24 bits → only ~16.7 M possible IVs. Birthday-paradox collision around ~5,000 packets.</li> FMS attack packet count:</strong> ~500 k–4 M “interesting” IV frames (a few hours of active traffic).</li> Typical crack wall-clock:</strong> 2–10 h on a busy SOHO network.</li> Consumer hardware required:</strong> one laptop + one Prism2/Prism2.5 USB dongle (~$40 used at the time).</li> Tools:</strong> AirSnort, WEPCrack, Kismet for capture.</li> CVEs:</strong> WEP itself isn’t a CVE, but the 2001 Borisov/Goldberg/Wagner paper and the 2001 FMS paper are the canonical breakage references.</li> </ul> What a defender should have done:</strong> realise WEP is not a security feature and treat the wireless LAN as untrusted. Use a VPN or IPSec at layer 3.</p> 2007 — WEP dead, WPA transitional, WPA2 arriving</h2> Standard:</strong> WPA (2003), a stopgap with per-packet keys (TKIP). WPA2 (2004) with AES-CCMP starting to appear in home routers.</p> What’s new for attackers:</strong> the PTW attack</strong> on WEP (2007) drops the packet count needed from ~1 million to ~40,000 — WEP now cracks in minutes. aircrack-ng</strong> becomes the canonical toolkit. Against WPA-Personal, offline dictionary attacks on the 4-way-handshake become practical on CPUs: capture a handshake, feed the PSK derivation through cowpatty</code> or aircrack-ng</code>, try dictionary entries one at a time.</p> What attackers didn’t have yet:</strong> meaningful GPU acceleration of WPA-PSK. Dictionary attacks were slow.</p> By the numbers (2007):</strong></p> Global deployment (WiGLE-style surveys):</strong> WEP ~35%, WPA ~25%, WPA2 ~20%, open ~20%.</li> PTW attack packet count:</strong> ~40,000–85,000 captured frames to recover a WEP key (down from millions).</li> Crack time with aircrack-ng + packet injection:</strong> <5 minutes, often under 60 seconds.</li> WPA-PSK dictionary rate (CPU, cowpatty/aircrack-ng):</strong> ~50–100 candidates/sec per core.</li> Rockyou wordlist</strong> (leaked Dec 2009): 14.3 M entries — became the de-facto English PSK wordlist.</li> WPA2 mandatory for Wi-Fi CERTIFIED:</strong> March 2006.</li> Aircrack-ng 1.0:</strong> released 2006, consolidating the ecosystem.</li> </ul> What a defender should have done:</strong> migrate to WPA2-AES-CCMP, pick a PSK longer than any dictionary. Drop WEP networks entirely.</p> 2012 — WPA2 dominant, GPU-cracking mature</h2> Standard:</strong> WPA2 is the default on essentially all consumer gear. WPA2-Enterprise (802.1X / EAP) in corporate networks.</p> What’s new for attackers:</strong> hashcat</strong> and oclHashcat</strong>, pyrit</strong>, and John the Ripper</strong> turn the WPA-PSK dictionary attack into a GPU problem</strong>. A handshake capture + a single modern GPU does tens of thousands of candidate PSKs per second; a small rented GPU farm handles hundreds of thousands. airodump-ng</strong> + Reaver</strong> (2011) exploit a WPS PIN</strong> implementation flaw to recover the WPA-PSK without a dictionary at all — a dealbreaker for home routers with WPS-on-by-default.</p> By the numbers (2012):</strong></p> Global deployment:</strong> WPA2 ~70%, WEP ~10%, open ~15%, WPA ~5%.</li> WPS PIN space on paper:</strong> 10⁸ = 100 million. Effective</strong> attack space after the Viehböck split: 10⁴ + 10³ = ~11,000 tries.</li> Reaver wall-clock to recover WPS PIN → PSK:</strong> 2–10 hours against an unpatched AP.</li> hashcat WPA-PSK throughput on GTX 580 (reference 2012 GPU):</strong> ~75,000 candidates/sec.</li> hashcat WPA-PSK on a small 4-GPU rig of the era:</strong> ~300,000 candidates/sec, i.e. rockyou.txt</code> (14.3 M) in ~50 seconds.</li> Real-world PSK recovery rate with rockyou + common rules:</strong> ~20–25% on captured handshakes in academic studies.</li> WPA2-PEAP/MSCHAPv2 hash rate (a Wi-Fi-adjacent Enterprise pain point):</strong> tens of millions/sec on a single GPU, full 2²⁸ keyspace within a day.</li> </ul> What defenders should have done:</strong></p> Turn off WPS.</strong> Most routers had it on by default.</li> Use long random PSKs</strong>, not dictionary words.</li> For enterprise: 802.1X + EAP-TLS with client certificates</strong>, not PEAP-MSCHAPv2 (which is itself a GPU problem).</li> </ul> 2017 — KRACK</h2> Standard:</strong> WPA2 still everywhere.</p> What’s new for attackers:</strong> KRACK</strong> (Vanhoef, Piessens, 2017) — Key Reinstallation Attack. It doesn’t crack the PSK. It exploits a subtle flaw in the 4-way handshake where, under certain conditions (specifically on Android 6+ and wpa_supplicant 2.4–2.6), replaying handshake message 3 causes the client to reinstall an all-zero session key</strong>. From there, the attacker can decrypt selected traffic and, depending on cipher suite, inject packets.</p> What made KRACK different from prior attacks:</strong> it hit the protocol, not the key</strong>. A strong PSK didn’t help. Every WPA2 implementation needed a patch. Most vendors shipped one within weeks; some took years.</p> Also in this era:</strong></p> PMKID hashcat attack</strong> (2018, Steube). Many APs leak the PMKID in a single message; one packet is enough to start an offline PSK attack. Lowered the capture bar further — no client association needed.</li> Evil twin / captive portal phishing.</strong> As device UIs got prettier, fake captive portals became alarmingly effective against humans.</li> </ul> By the numbers (2017–2018):</strong></p> Global deployment:</strong> WPA2 ~85%, WEP <3%, open ~10%, WPA3 not yet shipping.</li> KRACK CVEs:</strong> 10 in the coordinated disclosure (CVE-2017-13077 through CVE-2017-13088).</li> KRACK-affected devices:</strong> all WPA2 clients and APs — 10+ billion</strong> endpoints. Real patching took years for long-tail IoT.</li> Vendor patch latency:</strong> Microsoft / most Linux distros within 1 week of disclosure; Android 2 months+ depending on OEM; many embedded devices never patched.</li> PMKID attack packet count:</strong> 1 single frame</strong> vs. the 4-way handshake’s 4 frames — no client association or deauth needed.</li> hashcat on GTX 1080 (reference 2017 GPU):</strong> ~400,000 WPA-PSK candidates/sec — ~5× faster than 2012.</li> A rented 8× 1080 Ti instance (~$4/h in 2017):</strong> ~3M candidates/sec — rockyou.txt</code> in <5 seconds.</li> Coordinated disclosure lead time:</strong> 4 months from vendor notification to public release.</li> </ul> What a defender should have done:</strong> patch Android / wpa_supplicant immediately, enforce HTTPS everywhere so decrypted Wi-Fi traffic is less useful, start planning WPA3 migration.</p> 2022 — WPA3 rolling out, downgrade attacks</h2> Standard:</strong> WPA3 (2018) required for Wi-Fi CERTIFIED devices since 2020. Key upgrades:</p> SAE</strong> (Simultaneous Authentication of Equals) replaces the 4-way handshake PSK — offline dictionary attacks become infeasible.</li> 192-bit mode</strong> for Enterprise.</li> Forward secrecy</strong>.</li> PMF</strong> (Protected Management Frames) mandatory — neutralises deauth-based denial-of-service.</li> </ul> What’s new for attackers:</strong> WPA3 isn’t broken, but its deployment mostly isn’t WPA3-only</strong>. WPA2/3 transition mode</strong> — the default on most APs — means an attacker can force a downgrade and attack as WPA2. This is Dragonblood</strong> (Vanhoef, Ronen, 2019 + follow-ups): a family of side-channel and downgrade attacks against SAE. By 2022, patched SAE implementations mostly closed the timing side-channels; the downgrade attack still works on mixed-mode networks.</p> Also in this era:</strong></p> Cloud-scale cracking</strong>: renting 8× H100 or similar on an hourly basis makes PMK dictionary attacks practical at a scale no amateur had in 2012.</li> Chipset firmware vulnerabilities</strong> (FragAttacks, 2021): flaws in the Wi-Fi stack itself, below the WPA layer, let attackers inject frames without needing any handshake break at all.</li> </ul> By the numbers (2022):</strong></p> Global deployment:</strong> WPA2-only ~60%, WPA3 ~20%, WPA2/3 transition mode ~15%, WEP <1%.</li> New-router WPA3 support:</strong> ~60% of consumer APs shipped in 2022 supported WPA3 (vs. ~10% in 2020).</li> Dragonblood CVEs:</strong> 5 (CVE-2019-9494 through CVE-2019-9499).</li> FragAttacks CVEs:</strong> 12 in the 2021 bundle.</li> hashcat WPA-PSK on RTX 3090:</strong> ~1.2M candidates/sec.</li> 8× A100 cloud instance:</strong> ~10M candidates/sec aggregate. rockyou.txt</code> in ~1.5 seconds; a 10B-candidate mask attack in ~17 minutes.</li> Cost per billion PSK attempts on spot cloud GPUs:</strong> ~$3–5.</li> 12-character fully-random PSK entropy:</strong> 2⁷² ≈ 4.7 × 10²¹. At 10M H/s, exhaustive attack = ~15,000 years</strong>. Safe.</li> 8-character lowercase+digit PSK entropy:</strong> 2⁴¹ ≈ 2.2 × 10¹². At 10M H/s, ~2.5 days</strong>. Not safe.</li> </ul> What a defender should have done:</strong> WPA3-Personal only (no WPA2 transition) on networks where you can enforce it; PMF required; long random PSK even with SAE; keep AP firmware current.</p> 2027 — today’s landscape</h2> Standard:</strong> Wi-Fi 6E (6 GHz) and early Wi-Fi 7 deployments. WPA3 near-universal on new gear; legacy WPA2 still common in small businesses and long-lived home networks.</p> State of the art in attacks:</strong></p> SAE is holding up.</strong> No public, practical attack against a well-configured WPA3-Personal network in 2027. Dictionary attacks against the PSK are not feasible — that’s SAE’s point.</li> Downgrade attacks</strong> are the main thing. Any network still advertising WPA2/3 transition is attackable as WPA2. Adversaries look for mixed-mode SSIDs first.</li> 6 GHz opens new surface.</strong> The 6 GHz band requires WPA3 for new standards; but legacy client bridging, IoT devices without 6 GHz support, and misconfigured co-broadcast SSIDs create inconsistencies attackers exploit.</li> Client-side attacks.</strong> When the link layer is secure, attackers move up. Rogue captive portals that trick phones into trusting a bad certificate, QR-code joining with fake SSIDs, deauth-during-roaming attacks (harder now with PMF but not eliminated).</li> Supply chain.</strong> Firmware-embedded backdoors and vendor bugs in Wi-Fi chipsets (the FragAttacks legacy) remain a durable source of exploits.</li> Cloud cracking is commoditised.</strong> A weekend-long SAE-offline attack (for the cases where offline attack is possible, i.e. the target ran an unpatched SAE) costs roughly the price of a nice dinner. This mostly doesn’t matter because SAE isn’t reducible to offline dictionary attack — but it shifts economics on legacy WPA2 networks that people haven’t migrated.</li> </ul> Tools still in rotation in 2027:</strong> aircrack-ng (older, still canonical for captures and WPA2), hashcat (cracking), bettercap (Wi-Fi MITM / rogue AP), airgeddon (workflow glue), and a wave of ESP32-based pocket tools for opportunistic deauth and handshake capture.</p> By the numbers (2027):</strong></p> Global deployment:</strong> WPA3 ~40%, WPA2/3 transition ~35%, WPA2-only ~20%, WEP ~0.5% (long tail of ancient gear).</li> Enterprise share running WPA3-Enterprise 192-bit mode:</strong> still <10%. Most corporate networks remain WPA2-Enterprise with PEAP.</li> New-device WPA3 certification:</strong> mandatory for Wi-Fi 6 since 2020, Wi-Fi 6E (6 GHz) since 2022, Wi-Fi 7 at launch.</li> hashcat WPA-PSK on RTX 5090-class single GPU (2025+):</strong> ~5–8M candidates/sec.</li> 8× H100 cloud instance:</strong> ~50M candidates/sec aggregate. rockyou.txt</code> in ~0.3 seconds.</li> SAE (WPA3-Personal) offline attack:</strong> infeasible at any hash rate — the handshake does not release a crackable hash to an eavesdropper.</li> Cost to brute-force a weak 8-char WPA2 PSK in 2027:</strong> <$10 on spot cloud GPUs.</li> Cost to brute-force a 12-char random WPA2 PSK:</strong> still ~ $10⁹ (same math as 2022, GPUs 5× faster → still millennia).</li> ESP32-S3 “Wi-Fi Nugget” / Flipper Zero-class pocket tools</strong> in circulation in 2027: hundreds of thousands of units. Opportunistic handshake capture is trivial; PSK cracking is still offline on a beefy host.</li> Deauth-DoS effectiveness:</strong> near-zero on PMF-required networks; still works against the ~30% of deployed APs where PMF is “capable” but not “required”.</li> </ul> Bottom line: against WPA3-Personal with SAE, PMF required, and a random PSK</strong>, none of the 2027 toolkit gets you in via the link layer. Against a typical 2019-vintage home router still running WPA2 with a weak PSK and WPS optionally exposed</strong>, a weekend on a mid-range GPU is plenty.</p> Defensive guidance for 2027</h2> This is the part that matters more than any of the history.</p> WPA3-Personal SAE-only, or WPA3-Enterprise with EAP-TLS.</strong> No transition mode on any network you can control. Check explicitly — many APs default to transition.</li> PMF required, not optional.</strong> Protected Management Frames prevent deauth-driven handshake captures and basic denial-of-service.</li> PSK length: random, ≥ 20 characters.</strong> SAE makes short PSKs safer than they used to be, but no reason to gamble.</li> Disable WPS permanently.</strong> Even though the WPS-PIN attack is ancient, many routers still ship with it enabled for “convenience”.</li> Guest SSID isolated.</strong> Client-to-client isolation on and routed to a separate VLAN with no internal LAN access.</li> IoT SSID, separate and cloistered.</strong> Cheap Wi-Fi thermostats and toys are the weakest link on most home networks. They get their own SSID, their own VLAN, and no route to anything important.</li> Firmware updates on APs.</strong> Most of the interesting 2020s Wi-Fi vulnerabilities were chipset-level; the fix is always a firmware update. Buy APs from a vendor that ships them.</li> Assume the link layer will fail and defend above it.</strong> HTTPS everywhere, client certs on anything that matters, VPN or Tailscale for remote access. When (not if) someone breaks your Wi-Fi, layer 4+ should still hold.</li> </ul> What stayed the same across 25 years</h2> Three patterns repeat at every generation:</p> The cryptography is almost always stronger than the deployments.</strong> WEP was a design failure; WPA2 and WPA3 have been broken by implementation flaws, downgrade paths, and side channels — not by pure crypto weaknesses.</li> Defaults matter more than capabilities.</strong> WPS on by default, WPA2/3 transition mode on by default, guest networks without isolation by default — this is what attackers actually find, at scale.</li> The attacker always moves up the stack.</strong> When link-layer security improves, attacks shift to captive portals, rogue certs, client mis-configurations, and phishing. No amount of WPA3 fixes the user who clicks “Trust” on the evil twin’s fake certificate.</li> </ol> Coda</h2> If this post’s ancestor on this site, from 2010, was “How to Hack a Wireless Network” and focused on WEP with aircrack-ng</code>, the 2027 version is closer to “How to Think About Wi-Fi Security” and focuses on configuration, patching, and realistic threat modelling. The cryptography has done its job. The layers around it are the interesting frontier now.</p> Test your own networks — or networks you’re authorised to test — don’t test anyone else’s. The same law that applied in 2002 applies in 2027.</p> nemboks.dk — forward your Danish digital post (mit.dk, e-Boks) to your email inbox 2026-04-22T00:00:00+00:00 TL;DR —</strong> nemboks.dk</a> is a service that forwards Danish digital post</strong> (from mit.dk</a> and e-Boks</a>) straight to your email. The problem it solves: digital post is “push” in theory but pull in practice — you still have to log in with MitID, open an app, and click around to read a letter from SKAT or your kommune. Nemboks turns that into an email that lands in the inbox you already live in, attachments and all. Built for Danish SMBs where the same virksomhed</code> receives post for multiple companies or employees, and where accountants, bookkeepers, and property managers want digital post in the same place as every other email. Free beta; after beta, 39 kr/md on annual billing, 49 kr/md monthly.</p> The problem with Danish digital post</h2> Since 2014, communication from the Danish public sector is digital by default. That means if your kommune, SKAT, Udbetaling Danmark, or FerieKonto needs to reach you, they drop a letter into either mit.dk</a></strong> (the public portal) or e-Boks</a></strong> (historically the most used private portal, now share-gated with Digital Post).</p> In principle this is great: centralised, auditable, no paper. In practice it’s friction-heavy:</p> You need MitID to log in every time.</strong> Every tax letter, parking ticket, or vacation-pay notice is gated behind an MFA flow.</li> The apps notify you, but the notifications are thin.</strong> “You have new post” — not a subject line, not a sender, not enough to triage.</li> There’s no native forwarding.</strong> You can’t say “send everything from SKAT to my accountant at bogholder@firma.dk</code>.”</li> Businesses inherit the worst of both worlds.</strong> A CVR-registered company has its own mit.dk / e-Boks inbox. If the owner doesn’t check it, nobody does.</li> </ul> Email, by contrast, is the default inbox for small businesses: shared mailboxes, forwarding rules, archiving, filters, search. Nemboks bridges the two.</p> What Nemboks does</h2> Once set up, Nemboks authenticates against your mit.dk / e-Boks on your behalf, polls your inbox for new post, and forwards each new letter — as a real email with the PDF attached</strong> — to the address(es) you configure.</p> One email per letter.</strong> Subject = sender + subject. Body = plain-text preview. Attachment = the PDF.</li> Multiple companies per account.</strong> If you’re a revisor managing post for many CVRs, they all live under one Nemboks dashboard.</li> Multiple destinations per company.</strong> Forward everything from SKAT to the bogholder, everything else to the owner, for example.</li> Keeps the original in mit.dk / e-Boks.</strong> Nothing is deleted — Nemboks only reads.</li> Logs every forward.</strong> For audit and peace of mind.</li> </ul> The practical outcome: the accountant or bookkeeper who already lives in Outlook or Gmail stops context-switching into a portal once a week.</p> Who it’s for</h2> Nemboks is built for small- and medium-sized Danish businesses, especially:</p> Accountants and bookkeepers (revisorer</code>, bogholdere</code>).</strong> Clients give them Nemboks access once; from then on, every SKAT letter for every client turns into an email in the shared inbox.</li> Property managers (ejendomsadministratorer</code>).</strong> A single administrator might manage post for dozens of property-owning A/S and ApS.</li> Small-company owners.</strong> The enkeltmandsvirksomhed</code> or two-person ApS</code> whose owner would rather receive a letter from their municipality in the same place as their customer email.</li> </ul> The stack</h2> For the curious:</p> Rails 8</strong> on Ruby 3.4, using Hotwire (Turbo + Stimulus) and Tailwind for the dashboard.</li> PostgreSQL</strong> for persistence.</li> Auth0</a></strong> for authentication. Users sign in with Google, Microsoft, or email+password — no separate Nemboks password to forget.</li> Stripe</a></strong> for subscription management, including the hosted customer portal for self-service card updates and cancellations.</li> Postmark</a></strong> for transactional email — it’s the category leader for “email that must land in the inbox,” which is the entire point of a forwarding service.</li> Docker + Kamal</strong> for deployment. Zero-downtime rollouts on a small fleet; no Kubernetes to operate.</li> Cloudflare Pages</strong> for the static marketing site at nemboks.dk</a>.</li> </ul> The split — Rails app on Kamal, marketing site on Pages — is deliberate. The marketing site needs to be cheap, fast, and heavily cached; the Rails app needs a database and background jobs. Running them as two separate deployments keeps each one simple.</p> Pricing</h2> Free beta</strong> while the service is stabilising.</li> After beta: 39 kr/md</strong> on annual billing, 49 kr/md</strong> monthly — VAT not included. Flat per-company pricing; no per-letter fees.</li> 60-day free trial</strong> for new customers after beta ends.</li> </ul> FAQ</h2> Is Nemboks allowed to read my mit.dk / e-Boks?</h3> Yes — as the inbox owner, you authorise Nemboks to read on your behalf. Nemboks only reads; it does not delete, reply, or mark as read anything you didn’t configure.</p> Is this GDPR-compliant?</h3> Nemboks processes personal data on your behalf. As a customer you’re the data controller; Nemboks is the data processor, and there’s a standard databehandleraftale (DPA) to sign. All data is stored in the EU.</p> What happens to the original letter in mit.dk / e-Boks?</h3> It stays there. Nemboks is read-only.</p> Can I forward to multiple email addresses?</h3> Yes. Each company can have multiple forwarding destinations, and you can route different senders to different addresses (for example, everything from SKAT to the bookkeeper).</p> Does Nemboks work for private individuals?</h3> The current focus is Danish businesses (CVR). A private-individual plan may come later.</p> What if Nemboks goes down?</h3> Your post still arrives in mit.dk / e-Boks normally; Nemboks just won’t forward it until the service is back. Nothing is lost.</p> How do I cancel?</h3> Through the Stripe customer portal from inside the dashboard. No email, no phone call.</p> Why build it</h2> Digital post works. It’s secure, it’s auditable, and I’d rather trust a SKAT letter in mit.dk than a brown envelope. But the user interface is designed for a citizen reading a handful of letters a year, not for a business receiving dozens a week across several CVRs. Email solves the “dozens a week across several mailboxes” problem well — filters, rules, shared inboxes, search — so the smallest useful bridge is to get the letters out of the portal and into email, with the PDF attached, without anyone having to log in every time.</p> That’s Nemboks.</p> How to play Spotify on a Logitech Squeezebox in 2026 2026-04-22T00:00:00+00:00 TL;DR —</strong> The official Spotify plugin Logitech shipped with Squeezebox stopped working when Spotify retired the libspotify</code> API in 2022. In 2026 there are two working paths to get Spotify on a Squeezebox Classic, Touch, Boom, Radio, or Transporter</strong>: (1) Logitech Media Server + the Spotty plugin</a></strong> (now renamed Spotty</code> / sometimes Spotty-XL</code>), which uses the Spotify Web API plus librespot</code> under the hood, or (2) run spotifyd</a></strong> on the same host as LMS and point LMS at it as a generic audio source. Path 1 is the one you want unless you have a reason otherwise. This post walks through it.</p> What happened to the official plugin</h2> Squeezebox hardware went end-of-life at Logitech in 2012, but the software — Logitech Media Server (LMS)</strong>, the thing that actually streams music to the devices — has been community-maintained ever since. For years it shipped an official “Spotify” plugin that used Spotify’s now-discontinued libspotify</code> C library. When Spotify shut libspotify</code> down in 2022, that plugin stopped working, and Spotify has not shipped a replacement for third-party embedded devices.</p> The community filled the gap:</p> librespot</code></strong> — an open-source, Rust reimplementation of the Spotify Connect client protocol. It’s the basis of most modern third-party Spotify integrations.</li> Spotty plugin for LMS</strong> — wraps librespot</code> plus the Spotify Web API into an LMS plugin. Presents Spotify browsing, search, playlists, and playback inside the Squeezebox UI (both the device screen and the LMS web UI).</li> spotifyd</strong> — a standalone librespot</code>-based daemon that shows up as a Spotify Connect target. Your phone sees it as a speaker, you cast to it, and its audio output goes somewhere LMS can pick it up.</li> </ul> Path 1 (recommended): Spotty plugin on LMS</h2> This is the cleanest experience and the one that feels native on the Squeezebox. You search and browse from the Squeezebox remote or Touch screen, and it Just Works.</p> 1. Get LMS running</h3> If you’re not already running LMS, install it on whatever always-on machine you have — a Raspberry Pi, a NAS with a Docker runtime, or a small Linux box is ideal.</p> # Debian/Ubuntu — grab the latest .deb from the community repo wget https://downloads.slimdevices.com/LogitechMediaServer_v8.x/logitechmediaserver_<latest>_amd64.deb sudo apt install ./logitechmediaserver_<latest>_amd64.deb sudo systemctl enable --now logitechmediaserver </code></pre> Or via Docker — lmscommunity/logitechmediaserver</code> is a maintained image:</p> docker run -d --name lms \ --network host \ -v lms-config:/config \ -v /path/to/music:/music:ro \ lmscommunity/logitechmediaserver:latest </code></pre> Open http://<host>:9000/</code> and you should see the LMS web UI. Your Squeezebox devices on the same LAN should appear under Players</strong> automatically.</p> 2. Install Spotty</h3> In the LMS web UI: Settings → Plugins → Install new plugins</strong> and tick Spotty</strong> (author: Michael Herger). LMS downloads, installs, and restarts. On restart, you’ll have a Spotty</strong> entry in Settings → Advanced → Spotty</strong>.</p> 3. Authorise Spotty with your Spotify account</h3> In Settings → Advanced → Spotty</strong>, click Add account</strong>.</li> Spotty kicks off an OAuth flow via Spotify’s Web API — you log in once in a browser, approve the access, and the token is stored on the LMS server.</li> You need Spotify Premium</strong> for playback. (This is a Spotify-side limit: librespot</code> can authenticate with Free, but full-quality playback is Premium-only.)</li> </ul> 4. Play something</h3> On the Squeezebox device itself, Home → My Music → Spotty</strong> (or Home → Music Library → Spotty</strong>, depending on your LMS version) — browse playlists, search, start a track. On the Squeezebox Touch the on-screen artwork works. On the Classic the text UI works. On the Radio and Boom you drive it from the web UI or the Squeeze Commander</a> / Squeezer</a> apps.</p> Spotty also adds Squeezebox devices as Spotify Connect targets</strong> — meaning you can cast from your phone’s Spotify app to “Living Room Squeezebox” natively, the same way you’d cast to a Sonos or a Google Home.</p> Path 2: spotifyd as a Connect bridge</h2> Use this if Spotty won’t install (old LMS version, old Perl, weird OS) or you specifically want Spotify Connect behaviour without Spotty.</p> # Debian/Ubuntu sudo apt install spotifyd # or from source: cargo install spotifyd </code></pre> Configure /etc/spotifyd.conf</code> with your Spotify credentials, a backend (alsa</code>, pulseaudio</code>, or pipe</code>), and a device name. Start the daemon:</p> sudo systemctl enable --now spotifyd </code></pre> From your phone, cast to the spotifyd</code>-named device. Audio comes out of the host.</p> To get that audio into a Squeezebox, pipe spotifyd</code> to a FIFO and play the FIFO in LMS:</p> # spotifyd.conf backend = "pipe" device = "/var/run/spotifyd.pipe" </code></pre> Then in LMS: add the FIFO as a File system music folder</strong> and play it as a live stream.</p> This is clunkier and has ~1 s of latency vs. Spotty’s tight integration. Only use it if Path 1 doesn’t work for you.</p> Works on which Squeezebox?</h2> Spotty works on every Squeezebox device that talks to LMS:</p> Squeezebox Classic / Squeezebox v3</strong> (text display) — text-UI browsing and playback.</li> Squeezebox Touch</strong> — colour touchscreen, artwork, the whole UI.</li> Squeezebox Boom</strong> — text UI, same as Classic.</li> Squeezebox Radio</strong> — text UI, built-in speaker.</li> Squeezebox Duet / Controller</strong> — the controller’s UI works; playback goes to the Receiver.</li> Transporter</strong> — full support.</li> piCorePlayer / SqueezeLite on Pi</strong> — yes, these are software Squeezeboxes and Spotty streams to them fine.</li> </ul> As long as the device can connect to LMS, Spotty can feed it.</p> FAQ</h2> Do I need Spotify Premium?</h3> Yes, for playback. librespot</code> (and therefore Spotty) requires a Premium account to decode audio. Spotify Free accounts can authenticate but won’t play.</p> Does Spotify Connect “appear the Squeezebox as a speaker” work?</h3> Yes, with Spotty installed. Each Squeezebox player shows up in the Spotify app’s device picker as a Connect target.</p> Does hi-res / lossless work?</h3> Spotify itself doesn’t offer lossless on standard plans (Hi-Fi has been “coming soon” for years). Spotty plays whatever Spotify serves — Ogg Vorbis 320 kbps on Premium — and the Squeezebox handles it natively.</p> Gapless playback?</h3> Yes, Spotty supports gapless.</p> Does this break if Spotify’s Web API changes?</h3> Yes, occasionally — Spotify periodically rotates OAuth scopes or deprecates endpoints, and Spotty gets a patch release. Keep the plugin updated.</p> Can I run LMS on the same box as my NAS?</h3> Absolutely. LMS is lightweight (~200 MB RAM, minimal CPU except during library scans). Running it next to Samba or on a homelab SBC is the common setup.</p> Is this the same as “piCorePlayer”?</h3> piCorePlayer is a tiny Linux distribution that turns a Raspberry Pi into a Squeezebox-compatible player (via SqueezeLite). It does not replace LMS — you still need LMS as the server. piCorePlayer + LMS + Spotty is a very common 2026 stack for people whose original Squeezebox hardware finally died.</p> What to do if your Squeezebox won’t connect to LMS at all</h2> Two things to check first:</p> mDNS / multicast across your network.</strong> Modern Wi-Fi routers often block multicast between SSIDs or to wired hosts. Put the Squeezebox and LMS on the same subnet/VLAN with multicast allowed.</li> SlimProto port (3483/udp and 3483/tcp).</strong> That’s what the Squeezebox uses to find LMS. Not blocked by anything sensible, but worth checking if you run a strict firewall.</li> </ol> Beyond that, the Squeezebox community is still active — forums.slimdevices.com</a> and the LMS Community GitHub</a> are where problems get solved.</p> Squeezebox hardware was discontinued fifteen years ago. Thanks to LMS, Spotty, and librespot</code>, it still plays Spotify better than most “smart speakers” sold new in 2026.</p> elpriser.org — Danish hourly electricity prices 2026-04-20T00:00:00+00:00 TL;DR —</strong> elpriser.org</a> shows the real, all-in hourly price of electricity in Denmark</strong> — not just the spot price. It combines the Nord Pool spot price, your local grid tariff (netselskab</code>), Energinet’s system and transmission tariffs, the state electricity tax (elafgift</code>), and 25% VAT. Data comes from Energi Data Service</a> and updates daily after Nord Pool publishes the next 24 hours around 13:00. DK1 (Vestdanmark) and DK2 (Østdanmark). Danish-language, free, no login.</p> What does Danish electricity actually cost?</h2> The “spot price” you see on most energy dashboards is only one component. The price you actually pay per kWh is made up of six parts:</p> Spot price</strong> — set hourly on the Nord Pool wholesale market for the following day.</li> Grid tariff (nettarif)</strong> — paid to your local grid operator (netselskab</code>). Varies by company and by time-of-day (off-peak, shoulder, peak).</li> System tariff (systemtarif)</strong> — paid to Energinet, the Danish TSO.</li> Transmission tariff (transmissionstarif)</strong> — also paid to Energinet.</li> Electricity tax (elafgift)</strong> — a state tax on consumption.</li> VAT (moms)</strong> — 25% applied on top of everything else.</li> </ol> Most price sites show the first number. A few show one or two more. None that I could find showed all six, hour by hour, for both price zones, with the correct grid tariff automatically picked for the user’s netselskab</code>. That’s what elpriser.org does.</p> The two price zones: DK1 and DK2</h2> Denmark is split into two electricity price zones by geography — the Great Belt separates them — and they often have different prices at the same hour:</p> DK1 — Vestdanmark.</strong> Jylland and Fyn. More wind-dominated.</li> DK2 — Østdanmark.</strong> Sjælland, Lolland, Falster, Møn, Bornholm. More interconnected with Sweden (SE4) and Germany.</li> </ul> When the wind blows hard in Jylland, DK1 can be cheap while DK2 is pricey. When an interconnector is down, the gap widens further. elpriser.org shows both zones side by side.</p> Which netselskab are you on?</h2> You cannot choose your netselskab</code> — it depends on where you live — but the grid tariff they charge is a significant chunk of your bill, and it varies by 15–25 øre/kWh at peak</strong> between the cheapest and the most expensive, which works out to ~500–1,000 kr/year</strong> for a typical household.</p> Rough ranking of peak (spidslast) tariffs as of 2025:</p> Zone</th> Netselskab</th> Peak tariff (øre/kWh)</th></tr></thead> DK1</td> RAH Net</td> ~33</td></tr> DK1</td> Trefor</td> ~37</td></tr> DK1</td> N1</td> ~46</td></tr> DK2</td> Cerius</td> ~47</td></tr> DK2</td> Radius</td> ~65</td></tr> </tbody></table> Smaller operators (Konstant, Nord Energi, Vores Elnet, El-net Kongerslev, and others) each have their own tariffs. elpriser.org lets you pick yours; the all-in hourly price adjusts accordingly.</p> You can’t switch netselskab</code>, but you can</strong> shift consumption — laundry, dishwasher, EV charging, heat-pump heating — into the low-tariff hours. The hourly chart exists for exactly that.</p> Historical extremes</h2> Record high:</strong> 16.69 kr/kWh (spot price, excl. VAT) in DK2, at 19:00 on 5 September 2022, during the European energy crisis.</li> Record low:</strong> −2.76 kr/kWh in DK1, at 14:00 on 2 July 2023, when wind production overshot demand.</li> </ul> Negative prices are not a bug: when production is high and demand is low, producers pay consumers to absorb the surplus. Modern price-aware heat pumps and EV chargers can lean into this.</p> How elpriser.org is built</h2> Static HTML</strong>, regenerated once per day after Nord Pool’s next-day publication around 13:00 CET.</li> Data source</strong>: Energi Data Service</a>, the open-data service from Energinet. No API keys required.</li> Structured data</strong>: schema.org/WebApplication</code> and FAQPage</code> are emitted on every page so Google can surface the prices directly in search results and AI overviews.</li> Hosting</strong>: a small origin behind Cloudflare. Cacheable for the full day; purged on the daily rebuild.</li> Language</strong>: Danish only. The domain name should have been a hint.</li> </ul> The whole thing is a single-purpose tool: no tracking, no login, no newsletter popover, no “10 ways to save on your electricity bill” listicles.</p> FAQ</h2> How often does elpriser.org update?</h3> Once a day, after the Nord Pool day-ahead auction publishes next-day prices around 13:00 CET. Intraday adjustments are not shown; most consumers are billed against the day-ahead price anyway.</p> Is the price shown with or without VAT?</h3> With. The headline number on elpriser.org is the all-in price per kWh: spot + tariffs + tax + 25% VAT. You can toggle to see the breakdown.</p> Why are prices in DK1 and DK2 different?</h3> Denmark has two physically separated electricity areas joined by the Great Belt interconnector. When the interconnector is fully used or wind production differs sharply between east and west, the two zones clear at different Nord Pool prices.</p> Can I see the breakdown of each component?</h3> Yes. Every hourly cell can be expanded to show spot price, each tariff component, elafgift, and VAT.</p> Do I really pay negative prices when the wholesale price goes negative?</h3> It depends on your contract. Pure spot-price contracts pass the raw Nord Pool price through — tariffs and tax still apply, so the all-in price can go slightly negative or just very low. Fixed-price contracts don’t.</p> Why Danish only?</h3> The data, the regulatory rules, the netselskab</code> structure, and the target audience are all Danish. An English version would be translating context, not content.</p> Where does the data come from?</h3> Energi Data Service</a> (Nord Pool spot) and Energinet’s tariff data. Both are official public data sets from the Danish TSO.</p> Small, focused, no login, no tracking. The way consumer energy tools should look.</p> winniemethmann.com — from WordPress to Astro 2026-04-19T00:00:00+00:00 TL;DR —</strong> winniemethmann.com</a> is the portfolio of a Danish food photographer and recipe developer. It was a WordPress site for a decade. I rebuilt it on Astro</a>, using content collections</strong> (typed Markdown) instead of a CMS, Sharp + AVIF</strong> for the image pipeline, and Astro’s i18n routing</strong> (Danish default, English at /en/</code>). Build time: ~30 seconds. Output size: ~70% smaller. No more admin panel, no more plugin updates, no more bot-probed login endpoint.</p> Why move off WordPress</h2> For a portfolio that changes a few times a month, WordPress was doing too much work:</p> PHP runtime and MySQL</strong> for a site that is functionally static.</li> Dozens of plugins</strong> for image galleries, contact forms, SEO, caching — each with its own update cadence and security disclosures.</li> A half-forked theme</strong> that had accumulated patches nobody remembered why.</li> An admin login endpoint</strong> that was probed several thousand times a day by bots.</li> Regular caching headaches</strong> every time the CDN and the plugins disagreed.</li> </ul> Concretely, dropping WordPress meant:</p> No admin panel to keep patched.</strong> WordPress core releases, plugin updates, theme updates — gone.</li> No database.</strong> Content lives as Markdown in the repo.</li> No login surface for bots to probe.</strong> There’s no /wp-admin/</code> anymore.</li> ~10× faster page loads</strong> with no caching layer required.</li> ~70% smaller total build size</strong>, swapping hand-exported JPEGs for AVIF at sensible srcset</code> breakpoints.</li> </ul> The tradeoff is that non-technical editing goes away. In practice that did not matter: the site owner was happier editing Markdown than fighting the WordPress block editor.</p> Why Astro</h2> I considered Hugo, 11ty, Next.js static export, and SvelteKit. Astro won on three specific points:</p> Content collections.</strong> A typed, schema-checked way to describe a portfolio project as a directory of photos plus some front-matter. Build fails loudly if anything is malformed. No CMS required.</li> The <Image></code> component.</strong> Astro’s built-in image pipeline handles AVIF + JPEG fallback + srcset</code> + width</code>/height</code> attributes with a one-liner. Sharp is the engine under the hood.</li> Islands architecture, not relevant here.</strong> The site has no interactive components, so it ships basically zero JavaScript.</li> </ol> Content collections, not a CMS</h2> Each portfolio project is a directory under src/content/portfolio/</code> with a front-matter schema:</p> src/content/portfolio/ ├── 2024-cookbook-editorial/ │ ├── index.mdx │ ├── cover.jpg │ ├── 01.jpg, 02.jpg, … └── 2023-spring-catalogue/ ├── index.mdx ├── cover.jpg └── 01.jpg … </code></pre> index.mdx</code> front-matter declares the project title, category, year, and cover image. Astro enforces the schema at build time via defineCollection</code></a> with a Zod schema. If a project is missing a cover image or has a bad category, the build fails.</p> Categories used: food photography, recipe development, interior & garden styling, editorial, cookbooks, and fashion</strong>. Adding a new project is mkdir</code> + cp *.jpg</code> + a short YAML front-matter block. No admin UI, no database migration, no cache to invalidate.</p> Image pipeline: Sharp + AVIF</h2> Food photography lives or dies on image quality. Astro’s <Image></code> component, powered by Sharp</a>, generates:</p> AVIF</strong> as the primary format. Roughly all modern browsers support it now (see caniuse</a>).</li> JPEG</strong> fallback with matching srcset</code> breakpoints (320, 640, 960, 1280, 1920 px).</li> Explicit width</code> and height</code> attributes, so there is zero cumulative layout shift while images load.</li> loading="lazy"</code> for below-the-fold images and fetchpriority="high"</code> for the hero.</li> </ul> Numbers</strong>: a typical portfolio page went from ~4.8 MB of hand-exported JPEGs to ~1.4 MB of AVIF — about a 70% reduction — with no visible quality loss at typical display sizes.</p> i18n — Danish default, English at /en/</h2> Astro’s i18n routing sits in astro.config.mjs</code>:</p> export default defineConfig({ i18n: { defaultLocale: "da", locales: ["da", "en"], routing: { prefixDefaultLocale: false }, }, }); </code></pre> That gives:</p> /</code> for Danish (the default, no prefix).</li> /en/</code> for English.</li> Each content entry declares its language via its collection and filename.</li> <link rel="alternate" hreflang></code> and the sitemap are generated from the same source.</li> </ul> Posts and portfolio entries that lack a translation simply don’t appear in the other locale’s routing — they don’t 404 to a wrong-language page.</p> Deployment and build</h2> Output</strong>: fully static, deployed as plain files behind Cloudflare.</li> Build time</strong>: ~30 seconds on a cold cache, ~6 seconds incrementally.</li> No server, no database, no runtime cost.</strong></li> </ul> Measurable outcomes</h2> Metric</th> WordPress (before)</th> Astro (after)</th></tr></thead> Build / deploy time</td> n/a (instant publish)</td> ~30s cold, ~6s warm</td></tr> Typical page size (portfolio page)</td> ~4.8 MB</td> ~1.4 MB</td></tr> Largest Contentful Paint</td> ~2.8 s</td> ~0.9 s</td></tr> Time to Interactive</td> ~3.5 s</td> ~1.1 s</td></tr> JS shipped</td> ~220 KB</td> ~0 KB</td></tr> Plugins to keep patched</td> 14</td> 0</td></tr> </tbody></table> FAQ</h2> Can a non-technical owner still edit the site?</h3> Yes, for copy. Editing Markdown in a GitHub web editor is, in practice, easier than the WordPress block editor. For new portfolio projects, the workflow is: drag images into a folder, write a short front-matter block, commit. If that’s too technical, a one-page admin (Decap CMS / Sveltia CMS / Keystatic) can be bolted on.</p> What about SEO after the migration?</h3> URLs were kept as-is wherever possible. Missing old paths redirect via Cloudflare rules. The sitemap is regenerated on every build, and structured data (Person</code>, ImageGallery</code>, Article</code>) is emitted per page.</p> Why Astro and not Hugo?</h3> Hugo is faster and simpler for pure blogging, but Astro’s typed content collections and first-class <Image></code> component won this case. For x2q.net</a> itself, I later went with Zola — for a portfolio with a heavy image pipeline, Astro remained the better fit.</p> How do images stay organised?</h3> Each portfolio project owns its own folder. The Git repo is the CMS. git log</code> tells you when an image was added and why.</p> Is the build deterministic?</h3> Yes. Given the same inputs, the output is byte-for-byte identical. Sharp is pinned in package.json</code>; so is Astro. CI runs on Node LTS.</p> If you’re on a WordPress site that’s doing far less than its infrastructure suggests, Astro is worth the afternoon it takes to try.</p> apextowww.com — a free apex-to-www redirect service 2026-04-18T00:00:00+00:00 TL;DR —</strong> DNS does not allow CNAME</code> records at the zone apex (RFC 1034 §3.6.2</a>). That’s why hosts like Netlify, Vercel, Cloudflare Pages, Firebase, and Heroku ask you to configure www.example.com</code> with a CNAME</code> and leave example.com</code> (the apex) as a problem. apextowww.com</a> solves it: point two A</code> records and two AAAA</code> records at the service, and it issues a Let’s Encrypt certificate for your apex and 301</code>-redirects every request to https://www.yourdomain.tld/</code>, preserving path and query string. Free, no signup, no account.</p> Why you can’t put a CNAME on the apex</h2> The DNS spec is unambiguous: a zone apex (the “bare” domain like example.com</code>) must carry an SOA</code> record and usually NS</code> records. CNAME</code> is defined as an alias that must be the only record at a name, and it is forbidden to coexist with the SOA</code> and NS</code> records that the apex is required to have. That’s why you can CNAME www.example.com → mysite.netlify.app</code> but you cannot</strong> CNAME example.com → mysite.netlify.app</code>.</p> Workarounds exist, and all of them are a little awkward:</p> ALIAS / ANAME records.</strong> Proprietary to each DNS provider (Cloudflare, Route 53, DNSimple, NS1). They work by resolving the target behind the scenes and returning an A</code>/AAAA</code>. Fine if your DNS provider supports it; useless if it doesn’t.</li> Flattening at the provider level.</strong> Cloudflare’s “CNAME flattening” is this, done automatically for you.</li> Your own always-on VPS doing 301 → www</code>.</strong> This is what I was doing for multiple domains, and it’s both over-engineered and a small maintenance tax.</li> </ul> apextowww is the fourth option: somebody else’s always-on redirector, managed for you.</p> What apextowww does</h2> Exactly one thing: a 301 Moved Permanently</code> from https://yourdomain.tld/anything?x=y</code> to https://www.yourdomain.tld/anything?x=y</code>.</p> TLS</strong> is issued automatically on first request via the Let’s Encrypt HTTP-01 challenge. No ACME client to run yourself.</li> IPv4 + IPv6</strong> on dual-stack by design. Both apex records are required.</li> HTTP/1.1, HTTP/2, and HTTP/3</strong> are all served. The redirect itself is trivially small, so protocol version matters less, but it helps the first-paint story when the redirect is on the critical path.</li> Path and query string</strong> are preserved, so deep links keep working.</li> No signup, no login, no account.</strong> If your DNS is pointed correctly, it just works.</li> </ul> How to set it up</h2> Go to apextowww.com</a> and copy the current IP addresses (two IPv4, two IPv6).</li> In your DNS provider, set A</code> records on your apex pointing at the two IPv4 addresses. Remove any existing A</code> record at the apex.</li> Set AAAA</code> records on your apex pointing at the two IPv6 addresses.</li> Make sure www.yourdomain.tld</code> still points at your real host (CNAME to Netlify/Vercel/Pages/etc).</li> Wait for DNS to propagate. Visit http://yourdomain.tld/</code> — it should 301 to https://www.yourdomain.tld/</code>.</li> </ol> The apextowww site has per-platform walkthroughs at /netlify-apex-domain-redirect/</code>, /vercel-apex-domain-redirect/</code>, /cloudflare-pages-apex-redirect/</code>, /firebase-hosting-apex-redirect/</code>, and /heroku-apex-domain-redirect/</code>.</p> Stack</h2> Hetzner ARM64</strong> servers, for cheap, low-power compute. ARM64 is ~30% cheaper per vCPU at Hetzner than x86 and runs the redirector fine.</li> Caddy-style automatic TLS</strong> with Let’s Encrypt</strong> HTTP-01 challenges.</li> Dual-stack IPv4 + IPv6</strong>.</li> HTTP/1.1, HTTP/2, HTTP/3</strong>.</li> Public static marketing site</strong> on Cloudflare Pages, with per-platform guides in separate URL paths so they each rank independently on Google for “netlify apex redirect”, “vercel apex domain”, etc.</li> </ul> FAQ</h2> Can I use apextowww with Cloudflare DNS?</h3> Yes, but you’ll want Cloudflare’s proxy (orange cloud) off</strong> for the apex A</code>/AAAA</code> records. If the proxy is on, Cloudflare intercepts the request and Let’s Encrypt’s HTTP-01 challenge won’t reach apextowww. Once the certificate is issued and renewed, you don’t need to toggle anything manually; just keep it off.</p> Does apextowww support wildcards or redirecting subdomains other than www?</h3> No. The service only redirects the apex to www.</code>. Everything else stays on your real host.</p> What happens if the apextowww IPs change?</h3> You’ll need to update your DNS A</code>/AAAA</code> records. The operator publishes current IPs on the homepage and gives advance notice for changes. For a personal domain this is fine; for anything mission-critical, run your own redirector.</p> Is there a rate limit?</h3> There’s no published hard limit, but this is a free community service. If you’re serving millions of apex redirects a day, self-host.</p> Why not just use Cloudflare’s free plan?</h3> Cloudflare’s CNAME flattening at the apex is a perfectly reasonable alternative if your whole DNS is on Cloudflare. apextowww is useful when your DNS isn’t on Cloudflare, or when you want a host-agnostic redirector that works identically across domains.</p> Is it really free?</h3> Yes. The marginal cost per redirect on ARM64 is negligible. No ads, no tracking beyond basic logs, no upsell.</p> Why it exists</h2> Hosting platforms optimise for their own onboarding, not for the DNS truisms that trip up every new user. Sending people to a stranger’s VPS felt worse than running one myself. Now my own apex domains (including x2q.net</a>) point at apextowww, which means I could tear down the last little redirector VPS I still had running for historical reasons.</p> It’s the kind of project that isn’t interesting until you need it, and then it’s the only thing you need.</p>