Gennaro Cimmino
021e53c8d3
Add the port_change_mtu and port_max_mtu operations, wire them into both the RTL83xx and RTL93xx dsa_switch_ops, and put in place what the per family support needs: the encoding of the MAC maximum length fields, the config entries naming the register a family limits its frames with, and the largest frame it switches. Nothing is enabled here. No config carries a largest frame yet, so port_max_mtu keeps returning the ether_setup() default the user netdevices already advertised, and port_change_mtu keeps returning the -EOPNOTSUPP the DSA core returns on its own while the operation is absent. The families are turned on one at a time in the commits that follow, each filling in nothing but its own config entries. The CPU port is skipped in the shared operation rather than in a family callback, though the reason differs. On RTL930x its row of that register is the one the ethernet driver programs from the conduit MTU, and the two values would not agree: the DSA core raises the conduit MTU by the tagger overhead but hands this operation the plain largest user MTU, and it does so afterwards, so the write here would land last and shorten the limit by exactly that overhead. On the other three families the CPU port has no row of its own. Skipping it in one place covers both cases. Families whose limit is one register for the whole switch are served by the same operation, programming it from the largest MTU of any user port; the first users of that path are in the last commit of the series. The DSA core takes a different route once the operations exist: instead of bailing out early it sets the conduit MTU and rolls it back, so the conduit change_mtu operation runs twice per user port at probe, and twice more on any MTU request this commit then refuses. It is only called at all because the ethernet driver has one, and at probe it touches no hardware, as the conduit is still down at that point and the operation returns before programming anything. Not tested on hardware in this shape. What was tested on an RTL9303 is what it reduces to while no config carries a largest frame, the two operations as bare stubs returning those same two values: the advertised maximum, the errors an MTU change returns, the conduit at 1504, the boot log and ordinary traffic were all indistinguishable from the tree without it. Assisted-by: Claude:claude-opus-5 Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net> Link: https://github.com/openwrt/openwrt/pull/24400 Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
OpenWrt Project is a Linux operating system targeting embedded devices. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. This frees you from the application selection and configuration provided by the vendor and allows you to customize the device through the use of packages to suit any application. For developers, OpenWrt is the framework to build an application without having to build a complete firmware around it; for users this means the ability for full customization, to use the device in ways never envisioned.
Sunshine!
Download
Built firmware images are available for many architectures and come with a package selection to be used as WiFi home router. To quickly find a factory image usable to migrate from a vendor stock firmware to OpenWrt, try the Firmware Selector.
If your device is supported, please follow the Info link to see install instructions or consult the support resources listed below.
An advanced user may require additional or specific package. (Toolchain, SDK, ...) For everything else than simple firmware download, try the wiki download page:
Development
To build your own firmware you need a GNU/Linux, BSD or macOS system (case sensitive filesystem required). Cygwin is unsupported because of the lack of a case sensitive file system.
Requirements
You need the following tools to compile OpenWrt, the package names vary between distributions. A complete list with distribution specific packages is found in the Build System Setup documentation.
binutils bzip2 diff find flex gawk gcc-6+ getopt grep install libc-dev libz-dev
make4.1+ perl python3.8+ rsync subversion unzip which
Quickstart
-
Run
./scripts/feeds update -ato obtain all the latest package definitions defined in feeds.conf / feeds.conf.default -
Run
./scripts/feeds install -ato install symlinks for all obtained packages into package/feeds/ -
Run
make menuconfigto select your preferred configuration for the toolchain, target system & firmware packages. -
Run
maketo build your firmware. This will download all sources, build the cross-compile toolchain and then cross-compile the GNU/Linux kernel & all chosen applications for your target system.
Related Repositories
The main repository uses multiple sub-repositories to manage packages of
different categories. All packages are installed via the OpenWrt package
manager called opkg. If you're looking to develop the web interface or port
packages to OpenWrt, please find the fitting repository below.
-
LuCI Web Interface: Modern and modular interface to control the device via a web browser.
-
OpenWrt Packages: Community repository of ported packages.
-
OpenWrt Routing: Packages specifically focused on (mesh) routing.
-
OpenWrt Video: Packages specifically focused on display servers and clients (Xorg and Wayland).
Support Information
For a list of supported devices see the OpenWrt Hardware Database
Documentation
Support Community
- Forum: For usage, projects, discussions and hardware advise.
- Support Chat: Channel
#openwrton oftc.net.
Developer Community
- Bug Reports: Report bugs in OpenWrt
- Dev Mailing List: Send patches
- Dev Chat: Channel
#openwrt-develon oftc.net.
License
OpenWrt is licensed under GPL-2.0