Networking

I run a QNAP TS-459 Pro+ as my homelab NAS, connected to several Linux machines across different distros. Fedora 44, NixOS, Solus, whatever. The problem: I had to remember different commands to check disk status, restart NFS, fix permissions, manage keepalive scripts, diagnose remote access issues. Instead of hunting through notes or SSH-ing and fumbling around, I wanted one tool. A menu. Same commands, same approach, any distro. Works local or remote. I can call it from my home bin folder and it just works. ...

Started with something dumb. Facebook wouldn’t load in Vivaldi or Firefox on the desktop. Worked fine on mobile. Figured it was a browser thing at first. Extension, cookies, the usual 💨 . Wasn’t that. why i thought i might need ipv6 Ran a curl test forcing each protocol separately, just to rule stuff in or out: curl -4 -I https://www.facebook.com curl -6 -I https://www.facebook.com IPv4 came back clean. HTTP/2 200, instant. IPv6 flat out refused to connect: ...

Fresh Ubuntu Server 26.04 install on the Folio. Nothing exotic … wired NIC (enp0s25) sitting there with no cable in it, wifi doing all the actual work like it always does on a laptop. Should be a non-issue. Boot time said otherwise. Over 2 minutes. On a server. For nothing. $ systemd-analyze blame 2min 151ms systemd-networkd-wait-online.service Yep. There it is. Confirmed with the critical chain too … network-online.target wasn’t hit until 2min 5.041s in. Two minutes just sitting there. ...

Why Tailscale, not a real VPN server I looked at running my own WireGuard setup by hand … port forwarding, managing keys myself, keeping track of which peer is which. Tailscale does all of that for you, on top of WireGuard, and the actual setup on each machine ends up being a handful of lines. Every device I own is on the same tailnet now: the T620 server, my NixOS desktop, and … the one that surprised me … a MacBook Air 6,2 from 2014 that has no business running anything modern smoothly, and does it fine anyway. ...

The problem this actually solves On a normal distro, if a network mount goes stale … the connection dropped, the server bounced, whatever … the fix is usually sudo umount then sudo mount -a, reading straight from /etc/fstab. Simple, because fstab is a plain text file you can just point tools at. NixOS doesn’t work that way. fileSystems entries in configuration.nix get compiled into individual systemd .mount units automatically at build time. There’s no /etc/fstab to edit or run mount -a against in the traditional sense … the mounts exist purely as generated systemd units with names like mnt-t620\x2drelationships.mount. ...

The same sysctl file, three different machines I run the same core network tuning across the NAS (Fedora Server), the desktop (NixOS), and a laptop or two … not because every machine has the same workload, but because the underlying kernel-level wins are the same regardless of what’s actually running on top. The differences show up in what else gets layered on, not in the base config. BBR + CAKE, together The single biggest win of the lot. tcp_congestion_control defaults to cubic on most distros, which is fine but not great, especially over Tailscale/WireGuard tunnels where the effective path characteristics don’t always match what cubic assumes. bbr measures actual bandwidth and round-trip time instead of just reacting to packet loss, and pairs specifically well with cake as the queuing discipline … cake handles bufferbloat and fair queuing far better than the kernel’s default fq or pfifo_fast. ...