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.
I am trying to update my old v1.13.oc to v1.15.oc without luck. It bricked seems.
What I am doing is: Go back to Stock firmware, upload the factory.bin file, and when it is going to boot, it reboots in loop.
I am doing this because I want to keep the origial stock firmware.
Could be because it doesn't reset the settings on openwrt and this cause the brick?
Hi!
I'm not aware of such issue, since you're the first one reporting it. It's quite possible that you're facing a configuration conflict. This is because my build is an snapshot and OpenWrt itself is evolving. The same will happen when OpenWrt changes from the current swconfig to DSA in the future.
It's weird because I'm aware of that change, for future snapshots, and LuCI will warn you, but I'm not aware of any recent change that breaks things.
I think you should try to update your device without keeping your settings, just to try. You can always download a backup before proceeding to update with factory reset, you don't need to lose everything.
And I'm pretty sure that it's not a firmware issue by itself because both v1.13.oc and v1.15.oc work as expected. Anyway, I'll upload the v1.16.oc in the following hours so if you can wait and try that, just because it can be a problem with the current one, it will be great.
Always backup and sorry to hear your device is broken, but my advice is to try a factory reset and apply the settings manually since both versions work.
The problem is that I want to update OpenWrt from stock-linksys partition (here don't have an option to don't keep the settings), but looks like that something don't work in this way and I dont have a way to go back to OpenWrt, at least using this optimized builds, becuse the process is done apparently right.
Ok, looks like I didn't write it clearly, that's my fault.
First of all, chances are that the patches that OpenWrt did to the switch and then I patched again break the upgrade, because it's known to break from stock OpenWrt to this.
My suggestion was to install the v.1.13.oc version and if it boots, do a backup and restore your configuration manually from it.
Hey guys, got this router couple days ago and was debating whether or not to flash it with openwrt. The hotfixes for 1.16oc aren't uploaded on GitHub, also I don't seem to get good results on 5ghz even on stock fw (around 122mbits/s). What can I expect on OpenWRT?
Hi fellows, I have used ddwrt on a few routers in past years, but never tried OpenWrt. Since my EA6350v3 is not supported by ddwrt, I found myself reading through the comments on this forum. My initial impression is that OpenWrt is more complex to implement and use than ddwrt, because of the need to add in hotfixes and also the selection of the proper wireless board calibration files in order to obtain adequate wireless performance. I would like to load one of No TengoBattery's recent version's on my router, but would appreciate some advice on which version seems most stable, at this point in time, for those of you who have some experience with the different loads.
Hotfixes is a mechanic invented by me. It has nothing to do with OpenWrt itself. And you don't need to apply them: my latest build doesn't need the hotfixes because it works as expected. You may ask why do we need hotfixes? Well, I'm the single developer working on this, me and my laptop. I cannot give myself the luxury of rebuilding images every hour that something fails. I often make mistakes, a typo in a script, a script renamed here but I forgot to rename it on other place, etc.
TL;DR: I'm not a soulless big corporation with a team of engineers and powerful buildbots. I only have limited resources.
You don't have to select a proper wireless calibration. The device comes with various of them and I provide the chances of testing them. Along this almost 2 years of development, the calibration that I provide is without doubt the best.
More to say: this build is stable, it's more stable than the official OpenWrt. If you run Samba on the latest snapshot of OpenWrt, the device will crash (reboot itself without explanation). I've fixed it myself and that won't happen anymore in my build. If you use the official OpenWrt in any version, the wireless is barely usable, don't expect to have connection more than 5 meters line of sight. Me and other users have already done the work for you, you don't need to do anything.
Also, the hotfixes mechanics are not even hard to do. You just use the WebUI, don't even mind about using SSH or something fancy.
The latest is the one that contains the latest fixes both from me and from OpenWrt developers, therefore is by definition the "most stable", it's rock solid compared to official OpenWrt snapshots at this point of time.
Don't get me wrong. Most of the ones that are here in this thread had worked hard, so you don't have to. Also, if you don't like it, you can revert to OEM firmware. That's an exclusive feature of mine. Expect some bugs, nothing actually fatal like the bugs I fixed from vanilla OpenWrt, just minor annoyances. Any feedback will make this build better, if you don't like something, don't hessitate to ask about it.
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.