OpenWrt 24.10.0 – First Stable Release

Original Article ↗ Hacker News Discussion ↗

Package management and new release features

  • Commenters note APK (Alpine’s package manager) migration is planned for a later release, not 24.10.
  • Some are already using 24.10 RCs; upgrades generally preserve configuration cleanly, though targets moving from swconfig to DSA require manual reconfiguration.
  • New features like better tunnel support (e.g., IPIP6) are appreciated by people on IPv6‑native / tunneled setups.

Hardware choices & recommended devices

  • Three broad approaches emerge:
    • All‑in‑one consumer routers: GL.iNet Flint 2/MT‑6000, OpenWrt One, various TP‑Link/Asus/Netgear/Dynalink boxes; NanoPi and Banana Pi boards for more DIY.
    • x86/mini‑PC routers (Lenovo Tiny, Protectli, Teklager boxes, custom rackmount builds) plus separate OpenWrt APs.
    • Full UniFi stacks, with some later reflashing UniFi APs to OpenWrt.
  • Mediatek Wi‑Fi chipsets and ath9k/ath10k/11k are repeatedly cited as well‑supported; Realtek 2.5G NIC support in this release is called out.
  • Some caution that new Wi‑Fi 7 / Qualcomm SoCs (e.g., IPQ53xx) will lag in OpenWrt/Linux support.

High‑speed links (1–10 Gbit)

  • Several users run 1–10 Gbit home connections; OpenWrt on modest x86 (Core i3, Xeon‑D, etc.) can route 10 Gbit at low CPU usage.
  • FreeBSD‑based pfSense/OPNsense is reported to hit 5–7 Gbit ceilings on identical hardware in at least one case.
  • Hardware offload in OpenWrt is still seen as immature; CPU can become the bottleneck at multi‑gig speeds on embedded SoCs.

Configuration management & complexity

  • One theme: OpenWrt is excellent for features and security vs stock firmware, but long‑lived configs become hard to reason about (defaults vs changes, auto‑generated cruft).
  • Suggested mitigations:
    • Use /rom/etc vs /etc diffs where available; keep “firstboot” backups for comparison.
    • Track /etc in git or compare downloaded backup archives.
    • Cron jobs to record installed packages and include that in backups.
  • Some prefer NixOS or similar “config as code” systems on router‑class hardware and relegate OpenWrt to dumb APs; others feel NixOS images are too large or not well‑supported on typical ARM router SoCs.

Security and package quality

  • One commenter criticizes non‑core packages as under‑audited, citing an SSTP client script disabling TLS validation by default.
  • Others argue that despite such flaws, OpenWrt remains far more secure and up‑to‑date than most vendor firmwares (e.g., ancient 2.6 kernels, infrequent updates).

Flashing, official hardware, and ease of use

  • Many note that most supported routers can be flashed via the stock web UI or TFTP, without hardware mods; Xiaomi is mentioned as a common exception.
  • OpenWrt One is praised as a “no‑screwdriver” device: decent specs, 2.5G WAN, hacker‑friendly design (JTAG header), and good stability on 24.10.
  • Some warn specific boards (e.g., Banana Pi R4) have rough edges: broken Wi‑Fi/SFP in current kernels and immature upstream support.

Mesh networking and fleet management

  • OpenWrt supports mesh; OpenWisp is suggested for centralized management, though perceived as overkill for small home setups.
  • An improved third‑party “Table of Hardware” frontend is highlighted for picking devices by detailed criteria.

Comparisons and alternatives (pfSense, OPNsense, OpenBSD, Merlin, UniFi)

  • pfSense/OPNsense are viewed as easier for some routing‑only use cases but weaker for Wi‑Fi/AP roles; a common pattern is OPNsense router + OpenWrt APs.
  • Some move to NixOS or OpenBSD routers for clearer, versioned configuration, or to Linux/Alpine on small PCs.
  • Asuswrt‑Merlin is described as “enhanced vendor firmware”; OpenWrt wins on longevity once vendors end support.
  • One person replaces a fragile DIY stack with UniFi gear for family reliability; another reports the opposite (aging UniFi abandoned, revived via OpenWrt).

Community and project direction

  • Enthusiastic praise is common: long‑term stability, painless upgrades, and powerful QoS/adblock setups on cheap hardware.
  • One contributor expresses disillusionment: small PRs were merged but larger, multi‑year efforts were ignored; they perceive maintainers focusing on “fun” targets (GPUs, Doom, custom hardware) over merging substantial improvements.