Since Wireguard uses encryption, it's limited to the maximum throughout of the CPU. For OpenVPN it's around 30 MBPS (with the CPU overclocked such as in my build) and there is no way to overcome the issue beside from using a more powerful CPU to handover the job (for example, a Raspberry Pi).
Basically, you are pushing the CPU to it's limits and your results are consistent with the results observed for OpenVPN.
If you want more performance, handover the job to a 64 bit Raspberry or to an x86 mini laptop or a unused PC.
Ok, if I understand correctly, this does not fix the "forced" VLAN that OpenWrt uses, since it does not change the 02_network file, and changing that file is required to remove the implicit tagging and the forced usage of the VLAN1 and VLAN2.
I do not have idea how this will affect the patched VLAN since I haven't tested, but I think it will indeed fix the doble tagging that is one of the reasons for poor performance while routing:
And also why the firewall's flow offloading does not work while NATing:
And also why Wireguard looks capped even when it's performance should be superior to OpenVPN:
Since the 15 days are almost due now (so, new release should be prepared now), I'm gonna test the patched VLAN and report my findings here [before releasing it, since it will probably break something].
If everything works great, I would love to hear from you, @xxx, to know if it improved Wireguard and from you @Cjcr if it improved the routing perfomance.
The 2.4 GHz wireless performance (in paper) looks worst than even the 5.1 GHz performance which is actually pretty bad! If you have a dumb AP, maybe disabling the 2.4GHz radio and using the dumb AP or extender for 2.4 GHz will improve your experience.
At this point, it's a hardware issue and no software modifications will make it work better.
Ok, so I was testing today the new patches and it does break the switch.
If you use untagged WAN (like the majority of us) it can be solved by setting the default WAN VLAN, the 2, to untagged in the CPU and the port. I don't know if using a tagged WAN and changing it to it's respective VLAN will work [users with tagged internet service will have to test].
As the LAN side, I actually don't know what to do. The currently "running" solution ignored the LAN ports. However, I'm gonna test later if using the ports as untagged and the CPU as tagged works.
If it works, however, I don't know how to express that in the 02_network file. If there is no solution, I will remove the parts of the patch that assume the implicit tagging and will only use the part that actually disables the double tagging.
The other file, according to my limited understanding, should not affect the switch functionality and will allow double tagging in this particular situation (the patched switch) since it "marks" the CPU port as special.
If changing just that file does not work, we shall revert the whole commit but we need to test if only revering the changes to the edma_axi.c should fix the problem [and it's less code to maintain ;)].
I see, I'm gonna make a diff between the latest working and the current repository.
Kernel updates are not that significant since they are stable and such changes are not allowed in a stable Linux release, therefore we can safely ignore the changes in the kernel.
If you delete the patch, it will revert to OpenWrt default behavior, which is incorrect and annoying. If you don't use or need VLAN, then go ahead. I'm into fixing it but it does require some kernel debugging and I'm already working on it (I have a TIAO TUMPA for the JTAG, it's just matter of time to get both things working).
I removed the whole code for the default VLAN tagging (not just the current hack, a total removal) but it somehow makes the device to not rise up the wireless.
I just want to report that I've already solved the problem with the patched VLAN, it's working for me now. More testing needed, you can test it already, the commits are in my mastertrack branch already.
A working binary is in the process of testing, so my users can expect a new release soon.
If they do change the code layer because it looks like it breaks some other devices, the patches probably won't apply so it's a good time to grab the files and build.
Did someone suffered from random reboots when using the snapshots (including my snapshots)? Well, we can name Linux 5.4 (as the stable release of OpenWrt does use Linux 4.19 and it's free from the issue).
And while I can't fix the root cause, I can and have fixed the main critical problem. Now, you can expect to have a more reliable device, like in the old days when master used Linux 4.19 (they changed to Linux 5.4 some months ago).
I'm currently testing it but expect a release on GitHub soon (source code and packages are already online, just waiting to get pleased and upload the upgrade).
