Nevermind << Idiot here
Something should have happened at some point when updating my uboot while testing.
Probably typing error or a bad copy & paste.
The data stored after uboot was messed up:
4FC30 - 4FC35 MAC address
4FDC0 - 4FD37 Product ID/Version
4FDE0 - 4FE37 WPS default pin
Should be:
4FC00 - 4FC05 MAC address
4FD00 - 4FD07 Product ID/Version
4FE00 - 4FE07 WPS default pin
Sorry if I caused anyone losing time on this!
Awesome! 
Looking forward WDR4900v1getting 22.03.2 officially.
Final iperf3 tests
This will be a little slower for normal WDR4900 @ 800MHz, but performance difference between versions is there.
Openwrt client, Windows server at LAN
Made no less than 10 runs on each version, rebooting the main router and Openwrt after initial setup to ensure clean results.
All versions achieve ~1.4Gbit/s running both iperf server & client on Openwrt
Slower, results are constant
[ ID] Interval Transfer Bitrate Retr
[ 4] 0.00-10.02 sec 430 MBytes 360 Mbits/sec 0 sender
[ 4] 0.00-10.02 sec 430 MBytes 360 Mbits/sec receiver
Slow, results are constant
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 386 MBytes 323 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 386 MBytes 323 Mbits/sec receiver
Slowest of all, results are constant
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 348 MBytes 292 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 348 MBytes 292 Mbits/sec receiver
Best performance, but has some strange slow downs and speed ups
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 83.2 MBytes 698 Mbits/sec 0 221 KBytes
[ 5] 1.00-2.00 sec 85.9 MBytes 721 Mbits/sec 0 221 KBytes
[ 5] 2.00-3.00 sec 88.8 MBytes 744 Mbits/sec 0 221 KBytes
[ 5] 3.00-4.00 sec 89.7 MBytes 753 Mbits/sec 0 221 KBytes
[ 5] 4.00-5.00 sec 89.9 MBytes 753 Mbits/sec 0 221 KBytes
[ 5] 5.00-6.00 sec 89.2 MBytes 748 Mbits/sec 0 221 KBytes
[ 5] 6.00-7.00 sec 88.9 MBytes 746 Mbits/sec 0 221 KBytes
[ 5] 7.00-8.00 sec 88.6 MBytes 743 Mbits/sec 0 221 KBytes
[ 5] 8.00-9.00 sec 89.5 MBytes 750 Mbits/sec 0 221 KBytes
[ 5] 9.00-10.00 sec 89.8 MBytes 754 Mbits/sec 0 221 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 883 MBytes 741 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 883 MBytes 740 Mbits/sec receiver
[ 5] local 192.168.0.5 port 56026 connected to 192.168.0.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.01 sec 82.5 MBytes 682 Mbits/sec 0 219 KBytes
[ 5] 1.01-2.01 sec 81.2 MBytes 683 Mbits/sec 0 219 KBytes
[ 5] 2.01-3.00 sec 83.0 MBytes 705 Mbits/sec 0 219 KBytes
[ 5] 3.00-4.00 sec 81.2 MBytes 680 Mbits/sec 0 219 KBytes
[ 5] 4.00-5.00 sec 81.2 MBytes 682 Mbits/sec 0 219 KBytes
[ 5] 5.00-6.01 sec 81.9 MBytes 682 Mbits/sec 0 219 KBytes
[ 5] 6.01-7.01 sec 81.2 MBytes 682 Mbits/sec 0 219 KBytes
[ 5] 7.01-8.01 sec 81.2 MBytes 681 Mbits/sec 0 219 KBytes
[ 5] 8.01-9.01 sec 81.2 MBytes 684 Mbits/sec 0 219 KBytes
[ 5] 9.01-10.01 sec 81.2 MBytes 681 Mbits/sec 0 219 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 816 MBytes 684 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 816 MBytes 684 Mbits/sec receiver
Slower than 21.02, results are constant
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 729 MBytes 610 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 729 MBytes 610 Mbits/sec receiver
Definitely the CPU speed makes some difference:
600MHz 453 Mbits/sec
1GHz 547 Mbits/sec
1.4GHz 610 Mbits/sec
However when routing traffic through the wan interface (Computer connected at LAN), it peaks at 300Mbit, hogging the CPU with IRQs:
Mem: 52680K used, 68416K free, 1228K shrd, 0K buff, 27784K cached
CPU: 0% usr 0% sys 0% nic 5% idle 0% io 0% irq 93% sirq
Load average: 0.73 0.87 0.48 2/58 5050
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
8 2 root RW 0 0% 82% [ksoftirqd/0]
3 2 root IW 0 0% 1% [kworker/0:0-eve]
2652 2644 network S 5484 5% 0% /usr/sbin/wpa_supplicant -n -s -g /var/run/wpa_supplicant/global
2657 2643 network S 5484 5% 0% /usr/sbin/hostapd -s -g /var/run/hostapd/global
21.02 achieves 100% usage and peaks at 320Mbit
Mem: 38872K used, 83776K free, 296K shrd, 3312K buff, 13936K cached
CPU: 0% usr 0% sys 0% nic 0% idle 0% io 0% irq 100% sirq
Load average: 0.60 0.25 0.09 2/47 4341
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
7 2 root RW 0 0% 93% [ksoftirqd/0]
4238 4100 root R 1380 1% 1% top -d1
4 2 root IW< 0 0% 1% [kworker/0:0H-ev]
2640 1 root S 4940 4% 0% /usr/sbin/wpa_supplicant -n -s -g /var/run/wpa_supplicant/global
2639 1 root S 4940 4% 0% /usr/sbin/hostapd -s -g /var/run/hostapd/global
I guess it's due the hardware NAT not being used?
OpenWrt 22.03.2 has been released.
The release notes state: mpc85xx: p1010: make TP-Link WDR4900 v1 build again
Is this the structural solution we are waiting for or is this some sort of workaround?
It prepends a chainloader (okli-loader) in front of the kernel, which would be one of the options to decouple kernel size from the bootloader's abilities.
I guess I'm with @urkelbundy, does this mean there is an installable image somewhere and any sort of method for 22.03.2 on this. Or are we not quite there yet?
In the OpenWRT firmware selector (https://firmware-selector.openwrt.org/?version=22.03.2&target=mpc85xx%2Fp1010&id=tplink_tl-wdr4900-v1) an image is available for the WDR4900v1
Have you tried it? Does it just install (sysupgrade) or are there steps to perform before this?
I'm on holiday and nowhere near a WDR4900v1.
In the release notes this is stated:
Upgrading to 22.03.2
Sysupgrade can be used to upgrade a device from OpenWrt 21.02 or 22.03 to 22.03.2 and configuration will be preserved in most cases.
Sysupgrade from 19.07 to 22.03 is not supported.
Image version mismatch. image 1.1 device 1.0 Please wipe config during upgrade (force required) or reinstall. Config cannot be migrated from swconfig to DSA Image check failed
If I understand it correctly a sysupgrade from a recent OpenWRT version should work.
I was thinking about starting with a clean config, so I was planning to try a
sysupgrade -nv openwrt-22.03.2-mpc85xx-p1010-tplink_tl-wdr4900-v1-squashfs-sysupgrade.bin
from an existing 21.02.3 installed device
Should this work with no commands before this i.e. is no pre-upgrade work required?
Anyone tried a device already?
Hi. I just did a sysupgrade over luci from 21.02.3 without any issues.
Thank You all for this Update!
Same here: did sysupgrade incl keeping config from 21.02.4 to 22.03.2 without issues. Great!
At least is 22.03.3 with kernel 5.10.146 (vs 5.4.215 with 21.02.4) running on WDR4900v1 without changing anything (like the uboot patch) - you can just sysupgrade from 21.02 to (now) 22.03.3 and preserve your config.
Neoraiders patch (okli-chain-loader) enabled a bigger kernel size - otherwise it would have been stuck at 21.02.x which would be EOL soon.
With CHKDSK88's patch even openwrt 23.xx with kernel 5.15.xx (including switch to DSA) is possible and WDR4900v1 still has a future. Which is great imho.
I would like to know whether @CHKDSK88 uboot patch would apply to current situation (with okli-loader) as well and would improve overall situation?
Although I am very happy that the WDR4900v1 can be used with 22.03.3 I am still a bit confused.
Is the solution currently used with the okli loader a structural solution or do we need another, more permanent solution, for future OpenWRT builds?
So as per @urkelbundy confusion (which I share). Are we saying the DSA switch wasn't needed for 22.03.3 but will be needed for 23.xx with it's much bigger kernel?
In 22.03 libmbedtls is currently broken. However, it is fixed by:
Okli-loader fix all problems with kernel size. Uboot patch will only make boot process slower.
Returned from holiday and did a sysupgrade of 22.03.2 over 21.02.3 using Luci.
No issue. Glad to see 22.03 running on one of my WDR4900 units.
Many many thanks to all who contributed.
I'd like to echo that, I sysupgraded (built new configs which is my method with a new major release) and have spent the last week porting my iptables scripts to nftables.
Seems to be all working well, a big thanks to everyone for the large effort taken to keep this router alive and helping reduce ewaste.
I appreciate your tests. But to check true routing/NAT performance, testing should be done with two computers, one connected to the WAN interface (running as server) and one to the LAN interface (client). In different subnets and with Masquerading in the WAN zone of the firewall. This test will give real/accurate results to those that will be obtained using it as a router in production.
Launching iperf3 on the router itself (as client or server) is a huge bottleneck, due to the extra processing that the CPU must do for iperf3. Also, routing/NAT capability is not taken into account. The computer running the opposite role (server or client), is on the same network that is running iperf on the router (so no NAT is involved).