Recent from talks
Nothing was collected or created yet.
OpenWrt
View on Wikipedia
| OpenWrt | |
|---|---|
OpenWrt 18.06.1 login screen | |
| Developer | OpenWrt Project |
| OS family | Linux (Unix-like) |
| Working state | Current |
| Source model | Open source |
| Initial release | January 2004 |
| Latest release | 24.10.4[1] |
| Latest preview | 24.10.0-rc7[2] / 29 January 2025 |
| Repository | |
| Available in | English, Chinese, Polish, Portuguese, Punjabi, Spanish, Welsh + 25 partially translated languages[3] |
| Update method | opkg (up to 24.10 release) apk (snapshot builds) |
| Package manager | Alpine Package Manager (APK) opkg (up to 24.10 release) |
| Supported platforms | 50 different platforms using the following Instruction sets: ARC, ARM, m68k, MIPS, PowerPC, SPARC, SuperH, x86, x86-64[4] |
| Kernel type | Monolithic (Linux) |
| Userland | BusyBox |
| Default user interface | CLI, WebUIs (LuCI) |
| License | Free software (GPL and other licenses) |
| Official website | openwrt |
OpenWrt (from open wireless router) is an open-source project for embedded operating systems based on Linux, primarily used on embedded devices to route network traffic. The main components are Linux, util-linux, musl,[5] and BusyBox. All components have been optimized to be small enough to fit into the limited storage and memory available in home routers.
OpenWrt is configured using a command-line interface (ash shell) or a web interface (LuCI). There are about 8000 optional software packages available for installation via the opkg package management system.
OpenWrt can run on various types of devices, including CPE routers, residential gateways, smartphones, pocket computers (e.g., Ben NanoNote). It is also possible to run OpenWrt on personal computers and laptops.
History
[edit]The OpenWrt project was started in 2004 after Linksys had built the firmware for their WRT54G series of wireless routers with code licensed under the GNU General Public License.[6] Under the terms of that license, Linksys was required to make the source code of its modified version available under the same license,[7][8] which enabled independent developers to create derivative versions. Support was originally limited to the WRT54G series, but has since been expanded to include many other routers and devices from many different manufacturers.
Using this code as a base and later as a reference, developers created a Linux distribution that offers many features not previously found in consumer-level routers. Early on some features required proprietary software. For example, prior to OpenWrt 8.09 (based on Linux 2.6.25 and the b43 kernel module) WLAN for many Broadcom-based routers could only be had via the proprietary wl.o module (and which required Linux 2.4.x).
OpenWrt releases were historically named after cocktails, such as White Russian, Kamikaze, Backfire, Attitude Adjustment, Barrier Breaker and Chaos Calmer, and their recipes were included in the message of the day (motd) displayed after logging in using the command-line interface.
In May 2016, OpenWrt was forked by a group of core OpenWrt contributors due to disagreements on internal process.[9] The fork was dubbed Linux Embedded Development Environment (LEDE). The schism was reconciled a year later.[10] Following the remerger, announced in January 2018,[11] the OpenWrt branding is preserved, with many of the LEDE processes and rules used. The LEDE project name was used for v17.01, with development versions of 18.01 branded OpenWrt, dropping the original cocktail based naming scheme.[12]
Releases
[edit]| Version (Code name)[13][14] | General availability | Kernel | Latest minor version | Latest release date | Projected EoL[15] | libc | Notes |
|---|---|---|---|---|---|---|---|
| "Stable Release" | 2004-01 | ? | — | uClibc | Based on Linksys GPL sources for WRT54G and a buildroot from the uClibc project | ||
| 0.9 (White Russian)[16][17] | 2007-02-05 | 2.4.30 | — | NVRAM-based, nas, wl. Supported platform: brcm-2.4.
| |||
| 7.06 (Kamikaze)[18] | 2007-06-02 | 2.6.19 | 7.09[19][20] | 2007-09-30 | Using opkg. Supported platforms: atheros-2.6, au1000-2.6, brcm-2.4, brcm47xx-2.6, ixp4xx-2.6, imagicbox-2.6, rb532-2.6 and x86-2.6.
| ||
| 8.09 (Kamikaze)[21] | 2009-02-19 | 2.6.26 | 8.09.2[22][23] | 2010-01-10 | New platform: ar71xx.
| ||
| 10.03 (Backfire)[24] | 2010-04-07 | 2.6.32 | 10.03.1[25] | 2011-12-21 | Supported platforms: adm5120_mips, adm5120_mipsel, ar7, ar71xx, atheros, au1000, avr32, brcm-2.4, brcm47xx, brcm63xx, cobalt, ep80579, ifxmips, ixp4xx, kirkwood, octeon, orion, ppc40x, ppc44x, rb532, rdc, x86 and xburst.
| ||
| 12.09 (Attitude Adjustment)[26] | 2013-04-25 | 3.3 | — | CoDel (network scheduler) backported from Linux 3.5 to 3.3. New platforms: ramips, bcm2708 (Raspberry Pi) and others.
| |||
| 14.07 (Barrier Breaker)[27] | 2014-10-02 | 3.10 | — | New platforms: i.MX23, i.MX6.[28]
| |||
| 15.05 (Chaos Calmer)[29] | 2015-09-11 | 3.18 | 15.05.1[30] | 2016-03-16 | 2016, March | nftables (available since Linux kernel 3.12); New platforms: TBA if any | |
| 17.01 (Reboot (OpenWrt/LEDE))[31] | 2017-02-22 | 4.4 | 17.01.7 | 2019-06-20 | 2018, September | musl[32] | There were only release notes for "OpenWrt/LEDE 17.01.7 - Seventh Service Release - June 2019" with a code revision "rTODO-2252731af4".[33] The official announcement of "OpenWrt/LEDE v17.01.7 service release" was never made in the OpenWrt Forum due to GPG signing certs issues.[34] |
| 18.06[35] | 2018-07-31 | 4.9 / 4.14 | 18.06.9 | 2020-12-09 | 2020, December | ||
| 19.07[36] | 2020-01-06 | 4.14 | 19.07.10 | 2022-04-20 | 2022, April | WPA3 support.[37] Flow offloading (beta).[38] | |
| 21.02[39] | 2021-09-04 | 5.4 | 21.02.7 | 2023-05-01 | 2023, May | WPA3, TLS and HTTPS support included by default, initial DSA support, LXC and ujail support [40] | |
| 22.03[41] | 2022-09-06 | 5.10 | 22.03.7 | 2024-07-25 | 2024, July | Firewall4 based on nftables, many new devices added, more targets converted to DSA, dark mode in LuCI, year 2038 problem handled, core components updated.[42] | |
| 23.05[43] | 2023-10-13 | 5.15 | 23.05.6 | 2025-08-20 | 2025, July | New devices added, ipq40xx target converted to DSA, default cryptographic library switched to mbedtls, core components updated.[44] | |
| 24.10[45] | 2025-02-06 | 6.6 | 24.10.4 | 2025-10-22 | 2026, February | New devices added, ipq806x target converted to DSA, improved support for WiFi6 (802.11ax) and initial support for WiFi7 (802.11be), core components updated.[46] | |
| Legend: Latest version Previous version, security maintenance End of Life versions | |||||||
LEDE
[edit]| LEDE | |
|---|---|
Login banner | |
| Developer | LEDE Project |
| OS family | Unix-like |
| Working state | Merged with OpenWrt |
| Source model | Open source |
| Initial release | May 2016 |
| Repository | |
| Available in | 26 languages[47] |
| Update method | opkg |
| Package manager | opkg |
| Supported platforms | 23 platforms using the following Instruction sets: AVR32, ARM, CRIS, m68k, MIPS, PowerPC, SPARC, SuperH, Ubicom32, x86, x86-64[48] |
| Kernel type | Monolithic (Linux) |
| Userland | BusyBox, GNU |
| Default user interface | CLI, WebUIs |
| License | Free software (GPL and other licenses) |
| Official website | lede-project |
The Linux Embedded Development Environment (LEDE) project was a fork of the OpenWrt project and shared many of the same goals.[49][50][51][52][53] It was created in May 2016 by a group of core OpenWrt contributors due to disagreements on OpenWrt internal processes.[50] The schism was nominally reconciled a year later in May 2017 pending approval of the LEDE developers.[54] The remerger preserves the OpenWrt branding, but uses many of the LEDE processes and rules. The remerge proposal vote was passed by LEDE developers in June 2017,[55] and formally announced in January 2018.[56] The merging process was completed before the OpenWrt 18.06 release.[57]
| Version[13] | Release date | Kernel | Notes |
|---|---|---|---|
| 17.01.0 | 2017-02-22 | 4.4.50 | first stable release[58] |
| 17.01.1 | 2017-04-19 | 4.4.61 | bug fixes and enhancements[59] |
| 17.01.2 | 2017-06-12 | 4.4.71 | security fixes[60] |
| 17.01.3 | 2017-10-03 | 4.4.89 | security fixes[61] |
| 17.01.4 | 2017-10-18 | 4.4.92 | security fixes (KRACK, as far as addressable by server side fixes)[62] |
| 17.01.5 | 2018-07-18 | 4.4.140 | security fixes [63] |
| 17.01.6 | 2018-09-03 | 4.4.153 | security fixes [64] |
Features
[edit]OpenWrt features a writeable root file system, enabling users to modify any file and easily install additional software. This is in contrast with other firmware based on read-only file systems which don't allow modifying installed software without rebuilding and flashing a complete firmware image. This is accomplished by overlaying a read-only compressed SquashFS file system with a writeable JFFS2 file system using overlayfs.[65][66] Additional software can be installed with the opkg package manager and the package repository contains approximately 8000 packages (by 2022).

OpenWrt can be configured through either a command-line interface or a web interface called LuCI. OpenWrt provides set of scripts called UCI (unified configuration interface) to unify and simplify configuration through the command-line interface.[67] Additional web interfaces, such as Gargoyle, are also available.
OpenWrt provides regular bug fixes and security updates even for devices that are no longer supported by their manufacturers.
OpenWrt provides exhaustive possibilities to configure common network-related features, like IPv4, IPv6, DNS, DHCP, routing, firewall, NAT, port forwarding and WPA.
Other features include:
- Extensible configuration of the entire hardware drivers, e.g. built-in network switches and their VLAN-capabilities, WNICs, DSL modems, FX, available hardware buttons, etc.
- Mesh networking through B.A.T.M.A.N., OLSR and IEEE 802.11s-capabilities of the WNIC drivers and other ad hoc mesh routing protocols that have been implemented within Linux.
- Wireless functionality, e.g. make the device act as a wireless repeater, a wireless access point, a wireless bridge, a captive portal, or a combination of these with e.g. ChilliSpot, WiFiDog Captive Portal, etc.
- Wireless security: Packet injection, e.g. Airpwn, lorcon, e.a.
- Dynamically configured port forwarding protocols PCP, NAT-PMP, and UPnP IGD
- Port knocking
- TR-069 (CWMP) client[68]
- IPS via Snort
- Active queue management (AQM) through the network scheduler of the Linux kernel, with many available queuing disciplines. CoDel has been backported to Kernel 3.3.[69] This encapsulates Traffic shaping to ensure fair distribution of bandwidth among multiple users and quality of service (QoS) for simultaneous use of applications such as VoIP, online gaming, and streaming media without experiencing the negative impacts of link saturation.
- Load balancing for use with multiple ISPs using source-specific routing
- IP tunneling (GRE, OpenVPN, pseudowire, WireGuard, etc.)
- Extensible realtime network monitoring and statistics through e.g. RRDtool, Collectd, Nagios, Munin lite, Zabbix, etc.
- Dynamic DNS services to maintain a fixed domain name with an ISP that does not provide a static IP address
- OpenWrt supports any hardware that has Linux support; devices that can be connected (e.g. over USB) include
- Notable software packages to use the hardware support are
- File sharing via SAMBA, (Windows-compatible), NFS, FTP, SFTP. Printer sharing over the print server CUPS (spooling) or p910nd (non-spooling)
- PulseAudio, Music Player Daemon, Audio/Video streaming via DLNA/UPnP AV standards, iTunes (DAAP) server
- Asterisk (PBX)
- MQ Telemetry Transport through Mosquitto
Development
[edit]OpenWrt's development environment and build system, known together as OpenWrt Buildroot, are based on a heavily modified Buildroot system. OpenWrt Buildroot is a set of Makefiles and patches that automates the process of building a complete Linux-based OpenWrt system for an embedded device, by building and using an appropriate cross-compilation toolchain.[70][71]
Embedded devices usually use a different processor than the one found in host computers used for building their OpenWrt system images, requiring a cross-compilation toolchain. Such a compilation toolchain runs on a host system but generates code for a targeted embedded device and its processor's instruction set architecture (ISA). For example, if a host system uses x86 and a target system uses MIPS32, the regular compilation toolchain of the host runs on x86 and generates code for x86 architecture, while the cross-compilation toolchain runs on x86 and generates code for the MIPS32 architecture. OpenWrt Buildroot automates this whole process to work on the instruction set architectures of most embedded devices and host systems.[70][72]
OpenWrt Buildroot provides the following features:[70][72]
- Makes it easy to port software across architectures
- Uses kconfig (Linux kernel menuconfig) for the configuration of all options
- Provides an integrated cross-compiler toolchain (gcc, ld, uClibc etc.)
- Provides an abstraction for autotools (automake, autoconf), CMake and SCons
- Handles standard OpenWrt image build workflow: downloading, patching, configuration, compilation and packaging
- Provides a number of common fixes for known badly behaving packages
Besides building system images, OpenWrt development environment also provides a mechanism for simplified cross-platform building of OpenWrt software packages. Source code for each software package is required to provide a Makefile-like set of building instructions, and an optional set of patches for bug fixes or footprint optimizations.[73]
Hardware compatibility
[edit]OpenWrt runs many different routers and includes a table of compatible hardware on its website.[74] In its buyer's guide,[75] it notes that users recommend devices equipped with wireless chips from either Qualcomm's Atheros, Ralink (now MediaTek) or any vendor with open source drivers and specifications. It specifically avoids Broadcom chipsets as the feature set is very limited due to having no open drivers. OpenWrt also recommends choosing a device with a minimum of 16 MB of flash and 128 MB of RAM, preferably higher amounts.[76]
Adoption
[edit]OpenWrt, especially its Buildroot build system, has been adopted as the structure for other efforts. For example
- AltiWi "one-time-fee-only" replacement for Cloudtrax.
- Bufferbloat.net (Cerowrt)
- Freifunk and other mesh network communities
- IETF IPv6 integration projects HIPnet and HomeNet are OpenWrt-based
- prplOS, carrier-grade framework designed to power ISPs routers and gateways made by Prpl Foundation
- SIMET Box, developed by NIC.br, is OpenWrt-based[77]
Derivative projects
[edit]- AREDN The Amateur Radio Emergency Data Network uses a firmware based on OpenWrt: GitHub Project
- CeroWrt – (2011—2014) project to resolve bufferbloat in home networking, support IPv6, integrate DNSSEC, for wired and wireless, to complement the debloat-testing kernel tree and provide a platform for real-world testing of bufferbloat fixes.[78] The CeroWRT project is completely by 2014, when the finalized fixes were merged into OpenWRT. The "Bufferbloat project" behind CeroWRT went on to research new methods such as CAKE.[79]
- Coova chilli – OpenWrt-based with focus on wireless hotspots, a fork of chillifire with focus on wireless hotspot management
- Flukso – Wireless sensor nodes using an Atheros AR2317 chipset running a patched OpenWrt OS for communication. Sources and hardware schematics available on GitHub.
- Fon – OpenWrt-based wireless routers acting as hotspots. Sources and toolchain available on fonosfera.org
- Gargoyle – a web interface for OpenWrt with a strong emphasis on usability that later forked into a separate distribution
- Gluon – Framework for building OpenWrt-based firmwares fitted for mesh network deployment: GitHub Project
- JUCIWRT – a modern distribution using the JUCI webgui that later became an OpenWrt feed instead. The source code for JUCI is available at mkschreder/juci and is still usable by installing openwrt feed found at mkschreder/juci-openwrt-feed
- libreCMC – OpenWrt-based distribution which excludes non-free software or binary blobs, endorsed by the Free Software Foundation[80]
- LibreMesh – Framework for creating OpenWrt-based firmwares for wireless mesh nodes. GitHub Project
- Linino – OpenWrt-based distribution for the MIPS-based Arduino Yùn: GitHub Project
- Midge Linux – an OpenWrt-based distribution for devices based on Infineon Technologies ADM-5120 SoCs, such as Edimax BR-6104K and BR-6104KP.
- OpenMPTCProuter – aggregation of multiple Internet connections using Multipath TCP
- OpenSAN – iSCSI target Storage Area Network realization.
- PacketProtector – OpenWrt-based security distribution that includes IDS, IPS, VPN, and web antivirus capabilities. Packages included Snort, Snort-inline, FreeRADIUS, OpenVPN, DansGuardian and ClamAV. These tools were accessible via the old web GUI management interface of OpenWrt, called X-Wrt or webif^2. Project ended on June 7, 2012.[81]
- Qualcomm's QCA Software Development Kit (QSDK) which is being used as a development basis by many OEMs is an OpenWrt derivative
- RutOS – an operating system for all Teltonika routers, based on OpenWrt. Source code found at GPL - Teltonika Networks Wiki.
- SmoothWAN – aggregation of multiple Internet connections and network conditioning using Speedify, Engarde and tinyfecvpn.
- Turris Omnia and Turris MOX routers run on an OpenWrt derivative
- Ubiquiti's wireless router firmwares are based on OpenWrt
- Diverse grassroots projects for wireless community networks, including Freifunk, Libre-Mesh and qMp
- Some TP-Link, Xiaomi, ZyXEL and D-Link router firmwares are derived from OpenWrt[82][83]
- FreeWRT was a Linux distribution that was used in embedded systems such as WLAN devices from Linksys and Asus. Not related to a project (with same name) based on Sveasoft firmware.[citation needed]
- Friendly Electronics manufactures the NanoPi series of SoC devices and makes available an OpenWRT derivative OS called FriendlyWRT.[84]
- Ansuel's Technicolor Custom GUI a modified management web interface developed on the basis of the official Technicolor for Homeware firmware, which runs a fork of OpenWrt, unlocking Technicolor Modem/Routers.[85]
See also
[edit]References
[edit]- ^ . October 21, 2025 https://openwrt.org/releases/24.10/notes-24.10.4.
{{cite web}}: Missing or empty|title=(help) - ^ The OpenWrt Community (January 29, 2025). "OpenWrt 24.10.0-rc7 - Seventh Release Candidate - 29. January 2025". openwrt.org. Retrieved January 29, 2025.
- ^ "LuCI Translation Portal on Weblate". January 22, 2021. Retrieved January 22, 2021.
- ^ "git.openwrt.org Git - openwrt/openwrt.git/blob - target/Config.in". git.openwrt.org. October 24, 2017. Archived from the original on November 4, 2019. Retrieved July 2, 2018.
- ^ Fietkau, Felix (June 16, 2015). "OpenWrt switches to musl by default". Archived from the original on June 17, 2015. Retrieved June 16, 2015.
- ^ Miklas, Andrew (June 7, 2003). "Linksys WRT54G and the GPL". Linux kernel mailing list (Mailing list). Retrieved July 5, 2018.
- ^ Weiss, Aaron (November 8, 2005). "The Open Source WRT54G Story". Wi-Fi Planet. Retrieved July 5, 2018.
- ^ "Linksys Releases GPLed Code for WRT54G". Slashdot. July 6, 2003. Retrieved July 5, 2018.
- ^ Willis, Nathan (May 11, 2016). "LEDE and OpenWrt". LWN.net. Retrieved August 31, 2017.
- ^ Sharwood, Simon (May 10, 2017). "OpenWRT and LEDE agree on Linux-for-routers peace plan". theregister.co.uk. Retrieved August 31, 2017.
- ^ Wich, Jo-Philipp (January 2, 2018). "Announcing the OpenWrt/LEDE merge". LEDE Project Forum. Retrieved January 10, 2018.
- ^ "Welcome to the OpenWrt Project (OpenWrt Project)". OpenWrt. January 2018. Retrieved February 16, 2018.
As of January 2018, the current Stable OpenWrt release [17.01.4] was built from the LEDE 17.01 source code, and branded with the LEDE project name. Development versions of OpenWrt are currently branded with the OpenWrt name, and have a version number of 18.01
" - ^ a b "OpenWrt version history". October 16, 2023.
- ^ "Release Builds". October 19, 2023.
- ^ "Security - Support status". December 28, 2015. Retrieved January 9, 2024.
- ^ "Whiterussian 0.9 / Kamikaze snapshots". February 5, 2007.
- ^ "WHITE RUSSIAN 0.9". February 5, 2007.
- ^ "Kamikaze 7.06". June 2, 2007.
- ^ "Kamikaze 7.07". July 26, 2007.
- ^ "Kamikaze 7.09". September 30, 2007.
- ^ "Kamikaze 8.09". February 19, 2009.
- ^ "Kamikaze 8.09.1". June 3, 2009.
- ^ "Kamikaze 8.09.2". January 10, 2010.
- ^ "Backfire 10.03". April 7, 2010.
- ^ "Backfire 10.03.1". December 21, 2011.
- ^ "Attitude Adjustment". April 25, 2013.
- ^ "Barrier Breaker". October 2, 2014.
- ^ "OpenWrt Project: Freescale i.MX". openwrt.org. July 16, 2013. Retrieved July 16, 2018.
- ^ "Chaos Calmer". September 11, 2015.
- ^ "OpenWrt 15.05.1 "Chaos Calmer"". March 16, 2016.
- ^ "LEDE 17.01 "Reboot"". June 29, 2019.
- ^ "[OpenWrt-Devel] OpenWrt switches to musl by default". June 16, 2015. Retrieved June 27, 2015.
- ^ "OpenWrt/LEDE 17.01.7 - Seventh Service Release - June 2019". June 20, 2019.
- ^ "OpenWrt 17.01.7 - date of release?". July 20, 2019. Retrieved January 11, 2024.
- ^ "OpenWrt 18.06". July 31, 2018.
- ^ "OpenWrt 19.07". January 6, 2020.
- ^ Mehrtens, Hauke (January 6, 2020). "OpenWrt 19.07.0 - First Stable Release - 6 January 2020". OpenWrt Wiki.
- ^ Man, Low Kah (February 1, 2020). "Speedtest OpenWRT with flow offloading". Leow Kah Man - Tech Blog.
- ^ "OpenWrt 21.02". September 4, 2021.
- ^ Mehrtens, Hauke (September 4, 2021). "OpenWrt 21.02.0 - First Stable Release - 4 September 2021". OpenWrt Wiki.
- ^ "OpenWrt 22.03". September 6, 2022.
- ^ "OpenWrt 21.03.0 - First Stable Release - 6 September 2022". OpenWrt Wiki. September 15, 2022.
- ^ "OpenWrt 23.05". October 13, 2023.
- ^ Mehrtens, Hauke (October 11, 2023). "OpenWrt 23.05.0 - First Stable Release - 13 October 2023". OpenWrt Wiki. Retrieved October 24, 2023.
- ^ "OpenWrt 24.10". February 6, 2025.
- ^ Mehrtens, Hauke (February 6, 2025). "OpenWrt 24.10.0 - First Stable Release - 6. February 2025". OpenWrt Wiki. Retrieved May 26, 2025.
- ^ "Lua Configuration Interface: /modules/luci-base/po". May 10, 2017. Archived from the original on September 26, 2017. Retrieved May 14, 2017.
- ^ "LEDE Source Repository: /target/Config.in". March 30, 2017. Archived from the original on September 26, 2017. Retrieved May 14, 2017.
- ^ Larabel, Michael (May 14, 2017). "OpenWRT Gets Forked By Some Of Its Own Developers As LEDE Project". Phoronix. Retrieved May 3, 2016.
- ^ a b Willis, Nathan (May 11, 2016). "LEDE and OpenWrt". LWN.net. Retrieved May 14, 2017.
- ^ Chirgwin, Richard (May 5, 2016). "Router hackers reach for the fork: LEDE splits from OpenWRT". The Register. Retrieved May 14, 2017.
- ^ Grüner, Sebastian (May 5, 2016). "OpenWRT-Kernentwickler starten eigenen Fork". golem.de (in German). Retrieved May 14, 2017.
- ^ Ahlers, Ernst (May 4, 2016). "Router-Firmware: LEDE als offenere OpenWRT-Alternative" (in German). Heise Online. Retrieved May 14, 2017.
- ^ Sharwood, Simon (May 10, 2017). "OpenWRT and LEDE agree on Linux-for-routers peace plan". theregister.co.uk. Retrieved August 31, 2017.
- ^ Mehrtens, Hauke (June 26, 2017). "LEDE call for vote on remerge proposal V3". LEDE-DEV mailing list. Archived from the original on September 1, 2017. Retrieved August 31, 2017.
- ^ Wich, Jo-Philipp (January 2, 2018). "Announcing the OpenWrt/LEDE merge". LEDE Project Forum. Retrieved January 10, 2018.
- ^ "OpenWrt Project: OpenWrt 18.06". openwrt.org. May 18, 2018. Retrieved November 2, 2018.
- ^ "LEDE Project: LEDE 17.01.0 - First Stable Release - February 2017". Lede-project.org. February 22, 2017. Archived from the original on October 20, 2017. Retrieved October 20, 2017.
- ^ "LEDE Project: LEDE 17.01.1 - First Service Release - April 2017". Lede-project.org. April 19, 2017. Archived from the original on October 20, 2017. Retrieved October 20, 2017.
- ^ "LEDE Project: LEDE 17.01.2 - Second Service Release - June 2017". Lede-project.org. June 12, 2017. Archived from the original on October 20, 2017. Retrieved October 20, 2017.
- ^ "LEDE Project: LEDE 17.01.3 - Third Service Release - October 2017". Lede-project.org. October 3, 2017. Archived from the original on December 4, 2017. Retrieved October 20, 2017.
- ^ "LEDE Project: LEDE 17.01.4 - Fourth Service Release - October 2017". Lede-project.org. October 18, 2017. Archived from the original on December 22, 2017. Retrieved October 20, 2017.
- ^ "OpenWrt/LEDE 17.01.5 - Fifth Service Release - July 2018". Lede-project.org. July 15, 2018. Retrieved July 20, 2018.
- ^ "OpenWrt/LEDE 17.01.6 - Sixth Service Release - September 2018". Lede-project.org. September 2, 2018. Retrieved November 2, 2018.
- ^ "The OpenWrt Flash Layout". OpenWrt Project. January 18, 2010. Retrieved July 7, 2018.
- ^ Corbet, Jonathan (June 15, 2011). "Debating overlayfs". LWN.net. Retrieved July 7, 2018.
- ^ "The UCI System". OpenWrt Project. September 16, 2009. Retrieved July 8, 2018.
- ^ "29C3: ISP's black box". events.ccc.de. January 19, 2013.
- ^ "kernel: add codel and fq_codel to generic 3.3 patch set". dev.archive.openwrt.org. May 16, 2012. Retrieved July 2, 2018.
- ^ a b c "OpenWrt Buildroot – About". openwrt.org. Retrieved October 21, 2013.
- ^ "OpenWrt Buildroot - Usage and documentation". openwrt.org. January 8, 2006. Archived from the original on October 21, 2013. Retrieved October 21, 2013.
- ^ a b Tao Jin (February 13, 2012). "OpenWrt Development Guide" (PDF). Wireless Networks Lab, CCIS, NEU. Retrieved October 21, 2013.
- ^ "Creating packages". openwrt.org. Retrieved October 21, 2013.
- ^ "OpenWrt Project: Table of Hardware". openwrt.org. January 19, 2016. Retrieved July 2, 2018.
- ^ "OpenWrt Project: Buyers' Guide". openwrt.org. December 29, 2010. Retrieved July 2, 2018.
- ^ "8/64 warning". OpenWrt. May 17, 2025.
- ^ "Simet Box". Retrieved September 14, 2017.
- ^ "ANNOUNCE: debloat-testing kernel git tree". LWN.net. Retrieved February 13, 2014.
- ^ "Cerowrt Wiki - Bufferbloat.net". www.bufferbloat.net.
- ^ "Free Software Foundation adds libreCMC to its list of endorsed distributions". FSF.org. September 4, 2014. Retrieved December 21, 2014.
- ^ ""closing time" message from author on PacketProtector forum". Archived from the original on April 21, 2013.
- ^ "GPL Code Center | TP-Link". www.tp-link.com.
- ^ "GPL Source Code Support; D-Link". tsd.dlink.com.tw.
- ^ "FriendlyElec Downloads".
- ^ "Ansuel GUI". Ansuel Github. August 16, 2017. Retrieved April 16, 2022.
External links
[edit]OpenWrt
View on GrokipediaHistory
Origins and early development
OpenWrt originated in January 2004 as an open-source initiative sparked by Linksys's release of GPL-licensed source code for the firmware of its popular WRT54G wireless router. This disclosure, compelled in part by GPL enforcement efforts, enabled developers outside Linksys to dissect and modify the firmware, replacing proprietary components with fully open alternatives to achieve enhanced customization and control over router functionality. The project emerged from a community of tinkerers and coders motivated by the desire to unlock the full potential of embedded networking hardware, transforming static router firmware into a dynamic, user-extensible platform.[6][7] The foundational objectives centered on developing a lightweight, embeddable Linux distribution tailored for wireless routers and similar devices, prioritizing modularity, efficiency, and strict adherence to open-source principles. Early efforts focused on creating a minimal yet robust system using the Linksys GPL sources combined with a buildroot derived from the uClibc project, which facilitated the re-implementation of closed-source elements through freely available tools. This approach ensured the firmware remained compact for resource-constrained embedded environments while allowing seamless integration of additional features.[6] The inaugural public release in 2004 delivered a stripped-down Linux kernel paired with BusyBox for essential utilities and basic networking tools, establishing a solid base for routing and wireless operations on the WRT54G. Community engagement surged rapidly via online forums and collaborative contributions, accelerating innovation; by early 2005, new developers had joined, leading to the publication of experimental builds based on a customized buildroot2 system after initial closed development phases. Key early contributors included Felix Fietkau, whose work on core systems and wireless integration proved instrumental, alongside the founding team drawn from the broader developer ecosystem responding to the Linksys GPL availability.[6][8] Between 2004 and 2006, OpenWrt broadened its compatibility to encompass additional Broadcom-based devices, extending beyond the original WRT54G to support a wider array of routers sharing similar chipsets like the BCM47xx series. This period also saw the introduction of the first image builder—initially known as the image generator—a pre-configured tool that simplified the creation of tailored firmware images without requiring full recompilation from source, thereby democratizing custom builds for users and developers. These advancements laid the groundwork for OpenWrt's growth, evolving briefly into more structured release cycles with the debut of the Kamikaze branch in late 2006.[6][9]Major releases and version history
OpenWrt's version history began with early experimental builds in 2004, evolving into stable releases characterized by cocktail-themed codenames until 2016, after which numerical year-month (YY.MM) versioning was adopted for major stable branches. The project transitioned from Subversion to Git for version control in 2010, facilitating more efficient collaborative development during the Backfire era.[6] Initial releases like White Russian (version 0.9, released January 2007) were based on Linux kernel 2.4.30 and focused on basic firmware customization for devices such as the Linksys WRT54G, using a uClibc-based buildroot without a formal package manager.[10] This was followed by the Kamikaze series (versions 7.06 to 8.09.2, released June 2007 to January 2010), which introduced the opkg package manager in 2007 for lightweight software installation and upgraded to Linux kernel 2.6.x (e.g., 2.6.21.5 in 7.09), enabling better support for diverse hardware platforms while maintaining a compact footprint.[11][6] Subsequent milestone releases built on these foundations with incremental improvements in stability and features. Backfire (10.03 to 10.03.1, April 2010 to December 2011) adopted Linux kernel 2.6.32, a long-term support version, and enhanced wireless driver support via mac80211, including ath9k and b43 modules, alongside refinements to the build system for easier customization.[12] Attitude Adjustment (12.09, April 2013) introduced the Unified Configuration Interface (UCI) for streamlined network and system configuration, running on Linux kernel 3.3.x, which improved modularity for advanced routing setups.[13] Barrier Breaker (14.07, October 2014) focused on overall stability enhancements and updated to Linux kernel 3.10, while Chaos Calmer (15.05 to 15.05.1, September 2015 to March 2016) marked the shift to YY.MM numbering, upgraded to Linux kernel 3.18 for better USB and storage handling, and added improved IPv6 support, establishing a pattern of annual major releases with ongoing snapshot builds for testing.[14][6] The LEDE fork from 2016 to 2018 briefly disrupted the timeline but was reintegrated, leading to continued numerical versioning. Post-reintegration releases emphasized security and hardware compatibility: 18.06 (July 2018 to December 2020) used Linux kernel 4.9/4.14 with end-of-support in December 2020; 19.07 (January 2020 to April 2022) on kernel 4.14 with stability improvements and hardware compatibility enhancements; 21.02 (September 2021 to May 2023) transitioned to kernel 5.4 for enhanced performance; 22.03 (September 2022 to April 2024) on kernel 5.10; and 23.05 (October 2023 to August 2025, now end-of-life) based on Linux kernel 5.15, introduced enhanced Wi-Fi 6 support via updated hostapd and cfg80211 components, along with security hardening, and reached end-of-support in August 2025 after six service releases.[6][15][16] As of November 2025, the current stable series is 24.10 (initial stable release February 2025, incorporating over 5,400 commits from the prior branch), utilizing Linux kernel 6.6 for improved efficiency and new device support, with service releases up to v24.10.4 on October 22, 2025, addressing kernel updates to 6.6.110 and wireless fixes.[17][18] OpenWrt maintains a release cadence of roughly annual major versions, supplemented by daily snapshot builds, and a support policy of 2-3 years per stable branch, including backported security patches to ensure longevity for embedded deployments.[6][19]| Series | Initial Release | Kernel Version | Key Highlights | Support End |
|---|---|---|---|---|
| White Russian (0.9) | January 2007 | 2.4.30 | Basic buildroot foundation | Unsupported |
| Kamikaze (7.06–8.09.2) | June 2007 | 2.6.x | opkg introduction | Unsupported |
| Backfire (10.03) | April 2010 | 2.6.32 | mac80211 wireless, Git migration | Unsupported |
| Attitude Adjustment (12.09) | April 2013 | 3.3.x | UCI configuration | Unsupported |
| Barrier Breaker (14.07) | October 2014 | 3.10 | Stability enhancements, procd init | Unsupported |
| Chaos Calmer (15.05) | September 2015 | 3.18 | YY.MM numbering, IPv6/USB improvements | Unsupported |
| 18.06 | July 2018 | 4.9/4.14 | Post-merger stability, improved IPv6 | December 2020 |
| 19.07 | January 2020 | 4.14 | Hardware compatibility, ath79 support | April 2022 |
| 21.02 | September 2021 | 5.4 | Transition to kernel 5.x, DSA networking | May 2023 |
| 22.03 | September 2022 | 5.10 | Enhanced device support, security updates | April 2024 |
| 23.05 | October 2023 | 5.15 | Wi-Fi 6 enhancements | End of Life (August 2025) |
| 24.10 | February 2025 | 6.6 | 5,400+ commits, TLS 1.3 | Ongoing |
LEDE fork and project reintegration
In 2016, dissatisfaction within the OpenWrt community grew over issues including a declining number of active core developers, lack of processes for onboarding new contributors, unreliable infrastructure, insufficient transparency in decision-making, inadequate automated testing, and delays in stable releases.[20][21] These concerns, compounded by internal disagreements and single points of failure in project management, prompted a group of prominent developers—including Jo-Philipp Wich, John Crispin, Daniel Golle, Felix Fietkau, Hauke Mehrtens, Matthias Schiffer, and Steven Barth—to announce the LEDE (Linux Embedded Development Environment) project on May 3, 2016, as a spin-off fork aimed at rebooting the community's collaborative efforts.[20][21] The fork effectively saw nearly all active OpenWrt core developers migrate to LEDE, halting significant progress on the original project and shifting over 100 commits worth of development activity to the new initiative within weeks.[1][22] LEDE differentiated itself by emphasizing automated testing frameworks, a more modular and simplified build system with enhancements to the Image Builder for easier customization, transparent public communication channels, project-wide voting for decisions, a single class of committers with a liberal merge policy, and a focus on regular, predictable release cycles to improve stability and documentation.[1][20] This approach enabled LEDE to deliver its first stable release, version 17.01 "Reboot," in February 2017—based on the earlier OpenWrt 15.05 codebase but incorporating thousands of updates over nine months, including Linux kernel 4.4.50, updated packages like dnsmasq 2.76 and OpenSSL 1.0.2k, enhanced security features such as SHA256 source validation, and support for new hardware targets like ipq806x and layerscape.[23][24] In contrast to OpenWrt's stalled development, LEDE's faster pace addressed long-standing release delays, with infrastructure managed by multiple operators to ensure redundancy.[21] Reunification efforts began in late 2016 through discussions between the projects, culminating in a formal proposal in May 2017 that outlined merging under the OpenWrt name while adopting LEDE's codebase, governance model, and infrastructure.[25][26] The LEDE community voted in favor of the proposal by early June 2017, with unanimous support for the remerge and OpenWrt branding among participants.[25] The process involved integrating OpenWrt patches into LEDE (provided they met quality standards), migrating resources like the Git repository to git.openwrt.org (with GitHub mirroring), transferring domains to Software in the Public Interest for legal oversight, and phasing out separate forums and mailing lists over several months.[24][27] The merger was formally announced on January 3, 2018, marking the unification of both projects under OpenWrt and establishing LEDE's rules—such as small, frequent releases and emphasis on maintenance—as the foundation for future development.[24][26] Post-remerge outcomes included improved project health through decentralized management and automated processes, extended support for the LEDE 17.01 series (with service releases continuing into 2019 for security fixes), and the archival of pre-15.05 OpenWrt releases while limiting updates to 15.05.[1][24] This reintegration, facilitated by a collaborative summit in 2017, resolved the schism and fostered greater community participation, with the unified repository reflecting contributions from both sides.[25][26]Technical features
Core architecture and components
OpenWrt serves as an embedded Linux distribution characterized by a minimal root filesystem that incorporates BusyBox to deliver compact implementations of essential POSIX utilities, enabling efficient operation on resource-constrained hardware.[28] The system is built around the Linux kernel, with the 24.10 stable release utilizing version 6.6, which is optimized for embedded devices through targeted configurations and modules.[17] This base structure ensures a lightweight foundation, typically occupying just a few megabytes, while supporting extensibility without compromising core stability. Central to OpenWrt's architecture are several key components that facilitate configuration and management. The LuCI web interface provides a user-friendly graphical frontend for system administration, allowing modifications via a browser-based dashboard.[29] Complementing this is the Unified Configuration Interface (UCI), a centralized utility that standardizes settings management across diverse applications by storing configurations in plain-text files under/etc/config/, accessible through command-line tools, Lua bindings, or C libraries.[30] For process supervision and initialization, OpenWrt employs procd, a lightweight daemon written in C that handles init scripts, hotplug events, and service restarts via the ubus inter-process communication system, replacing older mechanisms like hotplug2.[31]
Modularity is a core principle of OpenWrt's design, achieved through a layered filesystem approach. The immutable base resides in a read-only SquashFS image mounted at /rom, which compresses the core system for efficient storage on flash memory.[32] Writable changes are managed via OverlayFS, which unions a persistent /overlay partition—typically formatted as JFFS2 on NOR flash or UBIFS on NAND—with the read-only layer, allowing users to modify files and install software without altering the original image.[32] Additionally, support for initramfs enables temporary, RAM-based boots for recovery or testing scenarios, loading a minimal environment directly into memory.[32]
The architecture is tailored for devices with limited resources, targeting systems with 8 to 128 MB of RAM and 4 to 32 MB of flash storage, where modern builds warn against using below 8 MB flash or 64 MB RAM due to constraints on package installations.[33] Administration emphasizes command-line tools via ash shell (from BusyBox) and the LuCI web interface, eschewing resource-intensive graphical desktops to prioritize efficiency and security on embedded platforms.
Over time, OpenWrt has evolved its standard library implementation, transitioning from uClibc to musl libc starting with the Chaos Calmer (15.05) release in 2015 to enhance POSIX compliance, reduce size, and improve security without increasing footprint.[34] This shift, now standard in releases like 24.10 with musl 1.2.5, better supports modern software while maintaining compatibility with embedded constraints.[17]
Package management and extensibility
OpenWrt employs opkg as its lightweight package manager, a fork of the earlier ipkg system originally developed for embedded devices like the NSLU2's Optware.[35] Opkg handles the installation, removal, and management of software packages in the .ipk format, allowing users to extend the base firmware without rebuilding the entire image.[35] This system overlays packages onto the read-only squashfs base filesystem using a writable overlay, such as JFFS2 or UBIFS, to conserve limited flash storage while enabling persistent changes.[35] The primary repositories for opkg are hosted on downloads.openwrt.org, offering over 9,000 packages as of 2025 across various architectures in the latest stable release.[36][37] These include stable branches for long-term support releases, snapshot feeds for the development trunk with cutting-edge updates, and third-party feeds for specialized content such as proprietary drivers.[38][35] Package indexes are configured via files like /etc/opkg/distfeeds.conf, and security is enhanced by signature verification using the usign tool with ed25519 keys, a feature integrated since the Chaos Calmer 15.05 release in 2015.[35] Installation and management occur primarily through command-line operations. Users first runopkg update to refresh the package lists from repositories, followed by opkg install <package> to download and install software along with its dependencies, or opkg remove <package> to uninstall it.[35] Opkg automatically resolves dependencies, ensuring required libraries and components are pulled in, though users can override with flags like --force-depends if needed.[35] For pre-configured setups, the Image Builder tool integrates opkg by allowing users to generate custom firmware images with selected packages baked in, avoiding runtime installation on resource-constrained devices.[9]
This extensibility enables diverse customizations, such as adding VPN support via OpenVPN or WireGuard clients, setting up media sharing with Samba or MiniDLNA servers, or deploying monitoring with tools like Collectd, all resolved through opkg's dependency handling.[38] OpenWrt supports multiple plugins for internet behavior monitoring, including traffic statistics, app/website filtering, time controls, access logs, and app identification, which can be installed via opkg or third-party feeds with varying compatibility by version and hardware.[38] Common options include OpenAppFilter (OAF) for DPI-based app filtering and auditing of over 100 applications;[39] FROS for app filtering of over 400 applications, audit reports with visualized records, and time controls for parental management;[40] luci-app-accesscontrol for MAC-based time restrictions;[38] Squid + Sarg for HTTP/HTTPS access logs and reports;[41] ntopng for traffic monitoring and analysis;[38] luci-app-statistics for flow charts;[38] and firewall rules combined with dnsmasq for domain logging.[42] The overlay mechanism ensures efficient storage by writing changes only to the upper layer, minimizing footprint on flash-limited hardware.[35]
Despite its flexibility, opkg has constraints tied to embedded environments. Package sizes are limited by available flash storage, often capping installations on devices with 8 MiB or less, potentially requiring extroot configurations for external storage.[35] Additionally, the base system lacks automatic updates, necessitating manual opkg upgrade commands or full sysupgrades, as mass updates can risk instability or soft-bricking if not handled carefully.[35]
Networking and security functionalities
OpenWrt's networking core is built around a stateful firewall that provides comprehensive traffic control and protection. Starting with version 22.03, the firewall backend shifted from iptables (used in firewall3) to nftables via firewall4, enabling more efficient rule processing and native support for modern netfilter features like connection tracking and NAT. This system uses zone-based policies to define traffic flows between interfaces, such as allowing LAN-to-WAN forwarding while rejecting unsolicited inbound WAN traffic by default, thereby securing the router against external threats. For VLAN-based WiFi isolation, such as for guest or IoT networks, users can create separate firewall zones for these interfaces, enable forwarding from these zones to the WAN only, and prohibit forwarding to the main LAN zone; optionally, plugins like banIP for dynamic IP banning or AdGuard for ad-blocking and DNS-based filtering can be installed to impose additional restrictions.[42] VLAN support adheres to IEEE 802.1Q and 802.1ad standards, allowing users to configure virtual LANs on switch-equipped devices for network segmentation without additional hardware. Quality of Service (QoS) is implemented using the Linux traffic control (tc) subsystem, with the integrated Smart Queue Management (SQM) tool applying algorithms like cake or fq_codel to prioritize traffic and mitigate bufferbloat, ensuring low latency for real-time applications even on congested links. Dynamic routing protocols are handled by the BIRD daemon, supporting BGP, OSPF, and RIP for advanced route propagation in complex topologies. OpenWrt supports internet behavior monitoring through various plugins that enable traffic statistics, app/website filtering, time controls, access logs, and app identification, enhancing traffic management and security. Common options include OpenAppFilter (OAF) for deep packet inspection (DPI)-based app filtering and auditing of over 100 applications[39]; FROS for app filtering covering more than 400 applications, audit reports with visualized records, and time controls, particularly for parental management[40]; luci-app-accesscontrol for MAC-based time restrictions; Squid combined with Sarg for HTTP/HTTPS access logs and reports; ntopng for comprehensive traffic monitoring and analysis; luci-app-statistics for flow chart visualizations; and firewall rules integrated with dnsmasq for domain logging. These plugins are installed via the opkg package manager or third-party feeds, with compatibility varying by OpenWrt version and hardware. Additionally, OpenWrt natively enables IPv4/IPv6 dual-stack operation, including DHCPv6 client and server modes for prefix delegation and address assignment, facilitating seamless transition to IPv6 environments. Wireless functionalities in OpenWrt emphasize flexibility and performance for router deployments. The hostapd daemon manages access point configurations, supporting WPA2/WPA3 encryption, multiple SSIDs, and client isolation to enhance privacy. For mesh networking, the batman-adv kernel module enables layer-2 routing over Wi-Fi links, allowing seamless extension of networks across multiple nodes with features like VLAN bridging for isolated client groups. Additionally, OpenWrt supports the IEEE 802.11s standard for wireless mesh networking, which provides standardized mesh backhaul between nodes using Wi-Fi protocols and works reliably in recent versions with compatible hardware and drivers.[2] For seamless client roaming across access points sharing the same SSID, OpenWrt implements IEEE 802.11r Fast BSS Transition (also known as Fast Transition), which reduces authentication time during handovers.[3] These two standards are distinct from each other and from batman-adv but can be effectively combined, with 802.11s handling mesh backhaul infrastructure and 802.11r enabling fast client mobility in the same deployment; official documentation and community configurations from 2024-2025 confirm reliable operation in current OpenWrt releases. Recent OpenWrt releases, leveraging Linux kernel 5.15 and later, provide support for Wi-Fi 6 (802.11ax) and preliminary Wi-Fi 7 (802.11be) through drivers such as ath10k/ath11k for Atheros/Qualcomm chipsets and mt76/mediatek for MediaTek hardware, delivering improved throughput, MU-MIMO, and OFDMA for dense environments. Security is a foundational aspect of OpenWrt, with built-in tools promoting hardening from installation. The Dropbear SSH server offers lightweight, secure remote access, configurable for public-key authentication and restricted to LAN interfaces to prevent WAN exposure. The uhttpd web server powers the LuCI interface with HTTPS support via Let's Encrypt integration or self-signed certificates, and can be tunneled over SSH for added protection against interception. To counter brute-force attacks, fail2ban can be installed and configured to scan logs from Dropbear and uhttpd, dynamically banning offending IPs through firewall rules. The opkg package manager facilitates automatic security updates, with the project maintaining a vulnerability disclosure process that tracks CVEs—such as those affecting kernel components or packages—dating back to 2010, ensuring timely patches via advisories and repository feeds. For advanced secure tunneling, WireGuard has been the preferred VPN protocol since OpenWrt 21.02, offering high-speed, kernel-level encryption with minimal configuration overhead compared to legacy options like OpenVPN. Unique to OpenWrt's design is its hotplug event system, powered by procd, which dynamically detects and configures network interfaces in response to hardware changes, such as plugging in a USB Ethernet adapter or modem, without manual intervention. To enforce secure initial setup, OpenWrt installations ship with no default root password, prompting users to set one via the firstboot process or LuCI interface, thereby avoiding common vulnerabilities from factory credentials. While core networking and security tools are pre-installed, further customization—such as additional VPN clients or intrusion detection—is achievable through the opkg package system.Development
Governance and community structure
Following the reintegration of the LEDE fork in January 2018, OpenWrt operates under a governance model derived from the LEDE project's rules, where decisions are made by simple majority vote among committers, with an emphasis on broad consensus achieved through public discussions on mailing lists and IRC channels.[1][43] The project distinguishes between committers, who have repository access and voting rights, and non-committers, fostering an open process that balances input from developers and power users.[43] The community structure revolves around key hubs, including the official forum at forum.openwrt.org for user support and discussions, the GitHub repository at github.com/openwrt/openwrt for issue tracking and code contributions, and periodic in-person developer meetings such as the annual OpenWrt Summit.[1][44][45] These gatherings, like the 2025 event in Sundhausen, Germany, facilitate collaboration on project priorities and technical advancements.[46] OpenWrt maintains a code of conduct centered on Rule 11: "Be nice to each other," established in 2016, which promotes respectful interactions and prohibits harassment to ensure an inclusive environment for all participants.[43] Funding supports the volunteer-driven project through donations managed by the Software Freedom Conservancy, its fiscal sponsor since September 2020 as a 501(c)(3) non-profit organization, alongside sponsorships from hardware vendors such as Banana Pi, which collaborates on device testing and development like the OpenWrt One router.[47][48] Maintainer responsibilities are divided among target-specific maintainers who oversee hardware ports and architectures, release managers who coordinate version updates and stability, and a broader base of active contributors exceeding 1,000 individuals who handle package maintenance, testing, and documentation as of 2025.[1][49]Build system and contribution processes
The OpenWrt build system is based on Buildroot, which automates the compilation of a cross-compilation toolchain, kernel, and root filesystem for embedded devices. It relies on a set of Makefiles to define build rules, dependencies, and targets, enabling the generation of firmware images tailored to specific hardware. Patches are managed using Quilt, a tool integrated into the system for applying, refreshing, and organizing modifications to upstream sources during the build process. This setup supports cross-compilation across multiple target architectures, such as MIPS, ARM, and x86, by producing a complete toolchain including compilers like GCC, binutils, and libraries such as musl libc on the host system.[50] Developers contribute to OpenWrt primarily through its Git repositories hosted on GitHub mirrors, where changes are submitted as pull requests (PRs) after forking the relevant repository. The workflow involves creating a dedicated Git branch for each set of changes, writing commit messages in imperative form with a Signed-off-by line per Linux kernel contribution standards, and ensuring patches are tested locally before submission. Code review is conducted by maintainers, who verify formatting, functionality, and adherence to guidelines using tools like the checkpatch.pl script; approved PRs are merged via staging trees into the primary Git repository at git.openwrt.org. Continuous integration and continuous deployment (CI/CD) processes utilize GitHub Actions to automate testing and builds on pull requests, a practice adopted across OpenWrt repositories to catch issues early.[51][49] Several tools facilitate development without requiring a full source build. The Image Builder provides a pre-compiled environment for end-users and developers to customize firmware images by adding packages, modifying configurations, or generating sysupgrade-compatible files, bypassing the need for complete recompilation. The Software Development Kit (SDK) allows isolated compilation of individual packages against a pre-built toolchain, streamlining package development and testing. The feeds system enables integration of external package repositories by defining them in the feeds.conf file and updating via scripts, allowing modular extension of the core build with community or third-party contributions.[9][52] Quality assurance in OpenWrt emphasizes automated builds and selective testing. Nightly snapshots are generated daily from the latest source code, providing experimental firmware with associated build logs and failure reports available for debugging build issues across targets. Some packages leverage autotools for configuration and include unit tests during compilation to validate functionality, though core system components rely more on integration testing via the build process. Security fixes from upstream projects are actively monitored and backported to stable release branches, ensuring long-term support for verified releases while snapshots receive the latest changes.[53][54][55] To lower barriers to entry, OpenWrt maintains extensive documentation on its wiki, covering build setup, package creation, and patching workflows to guide new contributors. While formal mentorship programs have been explored through initiatives like Google Summer of Code in related projects, the community encourages participation via forums and IRC for direct support.[50][56]Hardware support
Compatible device categories
OpenWrt primarily supports consumer-grade wireless routers, wireless access points, and embedded single-board computers, enabling users to customize networking hardware for advanced functionality.[57] These categories encompass a wide range of devices from mainstream vendors, with compatibility determined by factors such as processor architecture, storage capacity, and bootloader presence.[58] Wireless routers form the largest supported category, including popular models like the Linksys WRT series (e.g., WRT54G) and TP-Link Archer series (e.g., Archer C7), which are favored for their robust community support and ease of flashing.[57] Wireless access points, such as those from Ubiquiti and Engenius, provide focused Wi-Fi coverage without full routing capabilities, often integrated into larger networks.[57] Embedded single-board computers, like the Raspberry Pi models with custom OpenWrt builds, extend support to non-traditional networking hardware for applications in IoT and custom gateways.[57] Installation on compatible devices typically involves web-based firmware upgrades through the original equipment manufacturer (OEM) interface, which allows direct flashing of OpenWrt images without specialized tools.[59] For recovery or initial setup on Broadcom-based chips, TFTP (Trivial File Transfer Protocol) methods are common, requiring a network connection and specific button combinations to enter bootloader mode.[59] Advanced users may employ serial console access via a USB-to-TTL cable for troubleshooting or debricking, particularly on devices with locked bootloaders.[59] These processes carry risks, including permanent bricking if power is interrupted or incorrect images are applied, and often necessitate bootloader compatibility with tools like U-Boot or CFE (Common Firmware Environment).[59] The official Table of Hardware (ToH) database on the OpenWrt website lists approximately 2,000 supported models as of 2025, providing detailed installation guides, recovery button sequences, and warnings about potential risks like reduced usable flash space.[57][17] Vendor support varies, with official OpenWrt images available for brands such as Netgear (e.g., R series), Asus (e.g., RT-AC series), and TP-Link, while community-maintained ports cover older or niche hardware from manufacturers like D-Link and Buffalo.[57] All compatible devices must meet minimum hardware prerequisites of 8 MB flash storage and 64 MB RAM, though 16 MB flash and 128 MB RAM are recommended for full feature support and security updates in recent versions.[58] Bootloader compatibility is essential, as OpenWrt relies on unmodified or unlockable boot environments like U-Boot for reliable installation.[59]| Category | Examples | Key Considerations |
|---|---|---|
| Wireless Routers | Linksys WRT54G, TP-Link Archer C7 | High community support; web/TFTP install |
| Wireless Access Points | Ubiquiti UniFi AP, Engenius EAP | Focused on Wi-Fi; serial recovery common |
| Embedded SBCs | Raspberry Pi 4 (custom build) | Versatile for IoT; requires manual configuration |
