Wily raconteur

Why btop Detaches My Onboard Ethernet Card The Intel I225-V at PCI 0a:00.0 had been blacklisted in /etc/modprobe.d/ for two years. A short comment above the blacklist line read: "The NIC is broken on Linux". I had bought a USB 2.5G dongle and forgotten about the onboard NIC, the way you do when there are other problems. This is the story of what was actually wrong with it. The hardware in question is a rev 03 die, the B3 stepping Intel shipped specifically to fix the well-known I225-V 2.5G connectivity bug from earlier revisions. That earlier bug shows up as link drops, renegotiations, and noisy dmesg around link state. The signature in this post is different: config space alive, MMIO dead, no link retraining, no AER. If you saw "I225-V" and "2.5G" in the title and assumed the famous one, this is a different defect. The trigger Thirty-six hours into uptime, dmesg printed this. The Modules linked in line, the register dump, and the ? -marked speculat...

A firmware update broke my fiber WAN. The device that broke it reported itself perfectly healthy on every check I could think of. Here is how I found the fault, the seven wrong turns I took first, and how far the evidence actually goes. The setup The uplink is an HSGQ/ODI M110 GPON SFP stick , a Realtek RTL9602C SoC inside a transceiver. Firmware V1.0-220923 works. Firmware V1.1.8-240408 reproducibly kills WAN. Same fiber, same OLT, same hardware. Only the firmware string differs. The HSGQ/ODI M110 GPON SFP stick. The cruel part is that the broken firmware looks fine. The ONU reaches O5, the GPON operational state (G.984.3): registered with the OLT, ranged, all alarm flags clear, GEM port mappings present. Every surface check is green. No service traffic reaches the host. One symptom sent me the wrong way early. Link-local control frames, LLDP (multicast) and MNDP (broadcast), still showed up in the router's traffic sniffer while service unicast did not. I read that as a host-...

hardware review CTAP2.0 SKU: do check the note below April 2026  ·  Arch Linux 6.18.21-1-lts  ·  libfido2 1.16.0  ·  systemd-cryptenroll  ·  Security & authentication The ATKey.Pro from AuthenTrend is a FIDO2 hardware security key with an onboard capacitive fingerprint sensor. This review tests the device thoroughly on Linux and is quite explicit about what was verified by direct command output, what was confirmed by manufacturer documentation, and what remains genuinely unknown. Important: two distinct SKUs share the ATKey.Pro name The device tested here reports AAGUID e1a96183-5016-4f24-b55b-e3ae23614cc6 , which the FIDO passkey developer registry identifies as ATKey.Pro CTAP2.0 . A separate, newer product (AAGUID e416201b-afeb-41ca-a03d-2281c28322aa ) is the ATKey.Pro CTAP2.1 , which AuthenTrend now sells and markets as "CTAP2.1 compliant." These are distinct devices with distinct firmware beh...

  On Linux, the hard part of building a per-session firewall is not the firewall. It's deciding what "session" means in a way the kernel can match against later, without trusting anything in userspace to have told the truth. pam_authnft is the smallest concrete experiment I could build to poke at that question. It's a PAM session module that binds nftables rules to an authenticated session using the session's cgroupv2 inode as the identity. SSH in, your firewall rules appear; log out, they're gone. No setuid helper, no dedicated shell, no kernel patches. The framing I keep coming back to has four verbs. To give a session, a workload, or any other unit of activity a kernel-visible identity, you have to create it somewhere store it in something durable transport it through whatever subsystem boundaries the packets cross and verify it where the policy decision lives Most of the interesting failure modes come from one of those four steps be...