If you run the script yourself, it will download stuff from downloads.openwrt.org.
The pre-built files (link below the box) are the result of doing exactly that using a Github Runner.
The result should be the same, however, people managed to brick their devices with self-baked images for reasons such as running the scripts inside Ubuntu on WSL2...
So: If you don't trust Microsoft/Github and you have some experience with UNIX/Linux and know what you are doing, go ahead and use the script to generate the images. Make sure the size of the resulting files matches the size of the pre-built files you can download on github! And be ready to connect at least the serial console or even JTAG in case things go wrong.
I started to document some Post Install Tips on the wiki based on what's been discussed in this thread. Hopefully that's acceptable and we can expand the tips.
Is it recommended to install the irqbalance package? What about enabling Packet Steering (in combination with irqbalance)?
Is it recommended to leave Routing/NAT Offloading settings as default? Or should we enable Software or Hardware flow offloading post install?
Thank you for keeping the wiki updated -- nobody should be going through 1400+ posts and cherry-pick the hints from there....
Regarding recommended offloading setting: if using nftables-based firewall4 instead of old-school iptables-based firewall really resolves that random crash with hardware-flow-offloading we saw before, for sure we should recommend users to enable hardware flow offloading for full 1GBit/s routing performance. For people with less bandwidth, it may be better to keep all that disabled to have packet scheduling carried out in software (and hence allow traffic shaping). Can't have it both (at least as long as we don't support qdisc-offloading on this hardware).
Post Install Tips for the Wiki (work in progress):
Enable Flow Offloading
Without enabling Flow Offloading the device won't reach gigabit speeds on the WAN port. The max up/download speed to expect is X Mbps. If you need full 1GBit/s routing performance and/or want to reduce CPU load, it's recommended to enable Flow Offloading. However, it comes with drawbacks. If you need traffic shaping (QoS, SQM), don't use any Flow Offloading.
Software Flow Offloading reduces CPU load. As packets belonging to established flows are going through a software fast-path, bypassing much the usual treatment. With Software Flow Offloading, the router is capable of 1GBit/s speeds. Belkin RT3200/Linksys E8450 WiFi AX discussion - #1392 by Mushoz You get high speeds, but also relatively high CPU usage. Especially if using high-speed WLAN clients, up to 70%. Belkin RT3200/Linksys E8450 WiFi AX discussion - #1470 by Gix Software Flow Offloading is not compatible with traffic shaping (QoS, SQM).
Hardware Flow Offloading reduces CPU load further. However this only works well when using nftables-based firewall4 instead of old-school iptables-based firewall. Hardware Flow Offloading is not compatible with traffic shaping (QoS, SQM). Can't have it both (at least as long as we don't support qdisc-offloading on this hardware).
Enable irqbalance
Recommended to install? Or not? In combination with Software Flow Offloading?
Enable Packet Steering
Recommended? Or does it hurt performance? Should it be combined with irqbalance and Software Flow Offloading?
The router is capable of 1Gb speeds with only software offload, but with relatively high CPU usage, especially if using high-speed WLAN clients, up to 70%. HW offloading including ethernet-wlan acceleration (there is work in progress here) will be very helpful, I've made such tests and CPU usage was down to 20% during downloads. If the WLAN part is not important, I suppose software offload is enough. But again, we need to be sure HW offload does not randomly crash the router before recommending this, so if you can test this configuration (firewall4 + hw offload) for stability during several days it will be very appreciated.
Thanks. Then I won't put the HW offload recommendation on the wiki yet. Unfortunately can't help testing at the moment. But I'd like to summarize all this stuff for the wiki.
I've edited my post and will update it based on your replies until it's ready for the wiki
Should be:
So if you need traffic shaping, don't use any Flow Offloading.
There is no CPU overhead of software flow offloading, in contrary. As packets belonging to established flows are going through a software fast-path, bypassing much the usual treatment, this reduces the CPU load. Hardware flow offloading reduces it even further.
I've just spent an hour trying to set up my RT3200 as a wireless router. Got wan ip fine, configured APs fine. Diagnostics showed the internet connection was working fine. Clients got IPs fine. But there seems to have been some routing issues. No client on the lan could connect to anything on the wan. Any idea what could be the issue?
Hello - I thought I would register and post that I had the same issue trying to upgrade to the 0.62 pre-release.
If you used the 0.6.2 snapshot linked above then here's what fixed the issue for me.
I reverted to 0.6.1 (I kept my settings and it didn't break anything but could have also restored them from backup). That restored internet access then I used the attended sys upgrade feature to flash a current snapshot.
Thanks a lot. What would you recommend aside from traffic shaping for just limiting a certain WiFi network's usable bandwidth? In some instances I have more than one configured on the same channel, and just want to restrict the bandwidth available to some users.
Have read about nft-qos-static but seems it's not the most commonly recommended solution.
Hmm. Looks like the firewall4 change might be the problem then. @daniel is the build from the 0.6.2 working properly for you in terms of routing lan clients to wan?
Gonna reply to myself here with some more information. I've now put the openwrt router with br-lan interface static ip set to 192.168.2.1 behind my regular router and connected one of the ethernet ports to the wan port of my rt3200. Now I get an "wan" ip in the range of 192.168.1.0/24 from it and routing to the outside world works fine. Hopefully this info is helpful
So I've managed to find the cause after some confusion. HW offloading with firewall4 is the thing that's completely broken. I didn't realize this initially since saving and applying doesn't actually apply the change until a reboot.
Thanks! I've updated my post. Still some more to clarify haha.
Does using the WiFi on this device hammer the CPU? Under all configurations (SW, HW, and no offloading)? And does that CPU overhead occur when communication with the internet (WAN)? Or when communicating with LAN clients (connected via ethernet)?
Has anyone tested the max speed on the WAN port when not using flow offloading?
Yes, if it is TTL level, that will work. RS-232 with D9 plug will not work and fry the device.
If you have TTL serial adapter, set it to 3.3V level (usually a jumper or switch which allows you to set 5V, 3.3V and sometimes also 1.8V). See the Wiki for pinout.
Lol, i installed recovery 0.62 to quick test fw4. It's complete broken!
"Status" > "Firewall" shows only "Collecting data..."
And why are there no more "Custom Rules" with fw4??
Seems nftables is a pre-alpha and should not by installed yet, even it is default now.
nftables Firewall status in LuCI has not been merged yet, PR for it is here
Custom rules feature depends on iptables command line parser and as such will never be compatible with nftables. No idea if there is a plan to replace it, e.g. by allowing JSON-formatted nft rules being added in a similar way.
nftables itself has been the default way of Linux to setup firewalls, all distributions have adapted by now and OpenWrt still using iptables (and even custom patches to allow modern features, such as flow offloading, to work despite that) is actually the exception. So what is "pre-alpha" is mostly the web interface, and rest assured, that will be fixed by the people who care for that.
Without some sort of custom "rules" it does no make sense to me. I use i to fix bugs of fw3 (eg The firewall3 assigns zone sometimes wrong when pppd is stopped) and for many things which are not possbile by (l)uci. Makeing fw4 default even it does not yet run well is a bad idea. Additional the lack of wildcards for interface names (eg wg+)
Additional it seems there are many fixes https://git.openwrt.org/?p=project/firewall4.git;a=shortlog
Beside that it does not matter if the rules in the kernel are filled by iptables or nft command
