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).
The release is done, please check it out. I've documented one of the stronges features of this v1.15.oc version, which you can read here:
Also, I've implemented 2 important features:
The hotfixes, which is a backup-compatible file to fix small annoyances that I forgot to implement in the main image, or that failed my tests once the packages and images were ready.
A better error and crash reporting mechanics, when the device stores their dying breath in a reserved section of RAM that it's available once the device reboots. Along with it, an automatic script to recollect the data from RAM.
If your device crashes for any reason, or you think you have a problem, contact me directly on GitHub issues with a copy of all the files in /sys/fs/pstore and /rom/bootfs/pstore. If your logs contains any private, sensible or otherwise important information, send them to my email, but always open a GitHub issue.
Blockquote
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.
Hi @NoTengoBattery, been running 0.15.oc+patch for a day now, appears to be stable. Wireguard performance seems unchanged, but i did observe something interesting. I expect the wireless throughput to be slightly lower compared to wired, but not by 17Mbps..
over 5Ghz, speedtest results yeild:
EA6350v3 running WG client, speedtest on macbook
ping 12ms, 30Mbps down, 18Mbps up (average of 3 runs)
over hardwired ethernet:
EA6350v3 running WG client, speedtest on macbook
ping 11ms, 47Mbps down, 19Mbps up (average of 3 runs)
Well, wireless is a big problem with this device! 2.4GHz is technically unusable and 5 GHz works but it's far from perfect.
I don't know when you downloaded the hotfixes file, but I've changed it right now to include a script to disable ANI. ANI is the "Adaptative Noise Immunity" for the wireless, and I think it's problematic. If you can download, and try again, and do an iperf3 it would be amazing.
I swear I've tried anything I can think to make wireless usable but it's such a pain in the ass, it just don't want to work!
Keep me updated
For me, these are the results of iperf3, they are pretty good, but maybe my home is small and I'm kind of near the AP (like 7 meters with a solid concrete wall in between, tho):
Since the hotfix is not versioned, can you post SHA/MD hash of one of the files that has changed? Just want to ensure i am testing against right thing.
Good thing i asked, i had whatever hotfix was d274c473e2dfab41bdb1188e990d3955f5b0f87f2e7ebebba51b028a9db4f599, but that also means that you can now see results of both hotfixes.. Looks like 5f9d makes it worse..
mine is ~2 meters away, line of sight to macbook...transfer rates do not look too good..but i suppose explain the difference between wifi and ethernet performance related to speedtest.. i guess the question now, is why..
server was started as iperf3 -s
using patch with sha256 d274c473e2dfab41bdb1188e990d3955f5b0f87f2e7ebebba51b028a9db4f599
Ok, before trying again with any enabled, can you test the alternative calibrations? testcalibration alternative alternative, just to isolate the issue a bit more
Ran the tests with alternate configs for 5Ghz band only and latest patch, the results are mostly negligible, particularly in reverse test.. I think i will roll back to using .15 and original patch for now, unless you have anything else you want me to try.
No, actually nothing to test... I think I'm giving up, I tried anything but nothing works... Leaving the defaults, just enabling the firmware kick-out feature to (not surprisingly) kick out clients from the 2.4 GHz which kinda works but can keep clients connected when it's performing awful, so it's better to give up these connections...
Hi @NoTengoBattery,
To provide an update, i reverted back to 1.15oc release with original patch (hash ending in 4f599) and the performance picked back up. On your point on running default configuration, that is what i am doing with one minor exception. I found that setting Beacon Interval on both radios from default 100 to 900 makes the connection "more stable". While I am sad to hear that your at the giving up point, i really appreciate all the work that you've put into this project! Please let me know if there is anything i can help with in seeing any additional progress could be made with this device.
Oh no no, don't get me wrong. I give up about the wireless, but about the device itself, I've already worked too hard and fixed too many annoyances to give up now...
Just leave the wireless as it is, enable the kick out feature and not much more than that maybe I'm buying an N600 access point since here in my country we have not too many options. I was actually really lucky to get this one.