Yes, the router is connected with wired connection to desktop computer with http server loaded with a big file (4.6 GB). Then I connect with the phone to the router with WiFi 5 Ghz. The connection seems ok, the speed is good, but not as good as the stock. Seems like we need a piece to complete puzzle.
On the other hand, I have two questions, yet I haven't test so much..
Seems that block-mount don't work well, at least using LuCI. I can connect a usb drive and is detected well, but I can't setup a mount point, It don't save in LuCI for some reason.. maybe the file permissions for store that block-mount data? Idk.
The other question is, how I can do to update (if I want in the future) the current Openwrt without lossing the stock firmware I have in the other partition?
Edit: By the way, can you add iperf3 to your next build? If is possible. Edit2: Ups, I made a mistake in my first post. Is MB/s not Mbps.
I see that it sync at 866 Mbit/s, that's ok, but the download speed is fixed at 40 MB/s (around 320 Mbit/s)... BUT I got the same speed even with sync at 520 Mbit/s... that, for me, means that something else is blocking the max speed... not wifi itself... could be?
There are good chances that more fine-tunning is needed. The OEM firmware contains a worth of 1 or 2 MB (uncompressed) of shell scripts and sysctl configuratios that updates many values in the kernel and drivers. Most of the values and changes can't be "ported" because the open source drivers does not expose the same interface. This can be a problem of buffering, maybe the VLAN tagging is affecting since it's done in software, it can be a lot of things.
I'm aware of the problem, see: I use the OEM partition for packages, and that's not the default for OpenWrt. The partition is called syscfg, but OpenWrt is hardcoded to find the rootfs_data partition. It can't be renamed since it's an OEM partition, and patching a lot of code that relies on it will make things really hard. One of the workarounds that I implement is a pre-boot script that creates the nodes and a preconfigured /etc/config/fstbab, but the /overlay can't be modified anymore. To solve this, I use a symbolic link to the boot partition, but UCI seems to reject it with I/O error... you can temporary work arround it by moving the original file to the original location:
Boot to the OEM firmware and flash it again. Just to clarify: this ROM can revert back to OEM firmware at any time. Booting to OEM from OpenWrt, since I use the OEM partition, will make all of your settings to be reset anyway.
So for now I'm into solving the wireless performance, for sure, first and then eventually will make some "ports" of the OEM settings here. I've done already a couple of them but it looks like quite a lot of work is needed.
Have you tried enabling sotware offload in the firewall?
So seems this device is a bit complicated to make it working like stock does. I purchased this router for around 40€ in amazon uk (I am from Spain) but.. maybe there are better options for a similar price.
I have tried with software offload, but same results. Anyway, I am using the router like a dumb AP (no WAN, just connected to a random ethernet port and using a dhcp server from another router).
Anyway, thank you a lot for the work you are doing for this router. Keep it alive!
Hi NoTengoBattery,
Do you have any experience running WireGuard VPN client on this router? I've been playing around with it this past week, and while it seems to work great, there is a ~8 Mbps throughput drop when running the client on the router vs macbook. I wonder if there are some optimizations that could be had to get a performance boost.
Below are some speedtest result observations, the WG client config was the same between macbook and EA6350v3.
EA6350v3, speedtest on macbook (no WG control)
ping 12ms, 42Mbps down, 29Mbps up (average of 3 runs)
EA6350v3, speedtest on macbook running WG client
ping 12ms, 38Mbps down, 25Mbps up (average of 3 runs)
EA6350v3 running WG client, speedtest on macbook
ping 12ms, 30Mbps down, 18Mbps up (average of 3 runs)
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.
