For v0.32 I got good results by simply checking out OpenWrt commit 1173719, applying the .oc patches and then using "make menuconfig" to add all the additional packages (not just build-dependent ones like 6rd but pretty much everything I'm ever likely to want, since it's not wise to rely on the snapshot repository.) But it does have to be repeated for new builds if you do it that way, so I'll look at your recommendation for the next one.
As I mentioned over in the switch development thread, I'm becoming convinced that this device cannot route more than 1 Gpbs total (i.e. 500mbps symmetric, for example), and I'm wondering if that's just how Linksys wired up the board or if there's additional internal bandwidth that the firmware doesn't exploit. There's every indication that there's a physical 2gbps link between the SoC and the QCA8075 but it seems like we only get the use of half of it for whatever reason.
If true (and my bench testing suggests it is) then this is in effect a one-armed router plugged into a 5 port managed switch. Not terrible for something you can get for $30 on eBay, but still below its potential.
Normally it wouldn't matter that much; in real life I'm never trying to do a full gig bidirectionally over the lan (and it's unlikely any peer in the real world will give me that), but it does mean that this isn't suitable for simultaneous use as an edge and core router between internal subnets if you move significant amounts data between them.
Hi @NoTengoBattery, thank you for all your hard work on build; have been running it for few weeks without issues. Few items:
- Any chance in adding vpnbypass and luci-app-vpnbypass packages as part of build/release cycle? These two compliment openvpn capabilities of the releases nicely.
- I am running
NoTengoBattery v0.32.sc ff331 (started at this version), looking at system messages i am seeing spamming related to
Wed Apr 29 23:05:03 2020 daemon.err unbound: [4703:1] error: outgoing tcp: connect: Permission denied for 2606:4700:4700::1111 port 853. I see there is github issue #6 referencing this, but outlines its only relevant in .20 or below. Any idea?
- The default build comes with two running SSH servers
dropbear running on 2022 and
openssh on 22. Any though to standardizing to a single server? My vote would be disabling
openssh and configuring
dropbear only on 22 (its lighter/saves a cpu cycle).
If I understand correctly the issues with the device, it is as you think: only one gigabit port goes to the CPU, which mean that the gigabit bandwidth is shared between LAN and WAN in the switch.
Hi, thanks for your interest, let me answer your points:
- Yeah, sounds like a nice addition. However,
vpnbypass can be installed from the Software section in LuCI. Try to install it and if it does not work, I think it's worth to add it to the firmware image.
- Yes, the issue is relevant always. The
v0.20 part is that when using the default settings it will not happen. The thing is that you are using Cloudfare instead of the default Quad9. The issue is that your network is not capable of IPv6. You can solve the problem by deleting the IPv6 addresses in the Zones tab of the Recursive DNS service. I updated the issue to reflect your situation.
- Yes, I understand the SSH thing.
3.1. OpenSSH is used because Dropbear does not work with FileZilla. FileZilla is important because it's part of the official method for reverting to the original firmware (which is in the OpenWrt page for the device, so it's really, really important). And as the build is intended to be used as a NAS, it is important to allow the users to use the SFTP service.
3.2. Dropbear is needed because it is the only SSH server available during the Failsafe mode. Without it, you will not be able to use the Failsafe Shell over SSH, you will need to use a physical terminal (i.e. a UART cable).
3.3. Don't worry about the CPU cycles, the
dropbear process does not consume CPU time, and because of that I intentionally let it running. Also, it have a higher priority and some magic resource handling to try to keep it running, even if the device (that means, the other services like OpenSSH or LuCI) is not responding.
Nice to see this wonderful device got an extraOpenWRT option.
The official build works quite good here, the only problem i have is poor 2.4ghz signal strength (comparing to other old 2.4ghz routers on same location with same client).
5ghz signal strength is better than the 2.4ghz one (and good comparing to old router).
Does this build have any improvements on this subject ? (since i dont see its mentioned here)
Or do you know any ways to tweak the 2.4ghz radio ?
Let me tell you a bit of what happened time ago: at the beginning of the development, the 5 GHz radio was totally useless, bad signal strength and poor connectivity.
With the time, my investigation on the subject gave some good news to the device: 5GHz was useful, comparable to the OEM performance and sometimes better.
What did I do? Well, I tested what's called "calibration board files". The driver load those files to the wireless chip in order to overcome the physical differences that may degrade the wireless performance or make the device irradiate more power than allowed by law.
Linksys provide several of those files because it looks like there are some hardware variants for the design.
Answering your question: my build does contain the same calibration as the OpenWrt original (as I sent the files myself to the Linux Wireless developers), however, my build also contains a script that allows users to change the files in order to test all of the ones provided by Linksys. You should have to test them manually, one by one, as I have no way to know what should be correct for a particular device (I sent the file that best fit the majority).
You can install this build, run the script to test a particular calibration, perform some benchmarks, and proceed to do the same with the rest of the calibrations till you find the one that performs the best.
More details about the calibration testing script, of course, in my GitHub repository. The script is pretty straightforward to use, you call it once to list the options and then you call it with the file you want to test as the only required argument to the program. The device will reboot upon successful change operation and will load the new file to the chip during boot.
P.S.: I just checked my OP and it does say about the script in question.
Thanks for you thorough reply.
I tried changing the calibration board files and didn't notice any major changes, maybe i did it wrong ? or there should not be any big difference between them ?
My unit 5ghz reception is the best i have seen , but 2.4ghz reception is quite bad (about 10-15 less dbm than my old archer c2) , and worse than 5ghz on same spot from same unit (about 5 dbm less).
I see the 2.4ghz uses 20dbm (lowering it does lower reception) transmit power and 5ghz uses 23dbm , maybe there is a way to set 2.4ghz tx power to higher value (although i know it generally not recommended).
Is my reception experience matches yours or any one else ?
Well, I'm aware of the problem. I've tested some more calibration files (not present in the firmware, I have the only copy) and I want you to test one in particular.
Yes, there should be a noticeable difference between some files, other files perform almost the same. If you tested all files right, then when the device booted after performing the command
testcalibration art, your 5.8 GHz wireless radio will stop working.
Please, download the attached file and copy it to the device, replace the existing file in the
/lib/firmware/ath10k/QCA4019/hw1.0 path with the providen here, reboot the device and tell me about your performance.
Also: try to go to LuCI and in the Wireless page try to set up (manually) the wireless power to 30dBm.
I think that the problem here is that the calibration files does contain wrong data about the antenna gain. However, I have no idea of what the format of the files is, how the data is stored and it looks like there are no tools to inspect or modify the files. The only thing we can do is test the files that Linksys included with their firmware.
Firefox Send files do expire after a number of downloads or when the time is due. This link is, therefore, short-lived.
With that file (modified to improve the 5GHz, your 5 GHz will not perform well), I'm getting those results: -33 for 2.4 GHz and -56 for 5 GHz.
Well dude , you did it.
Replaced the original file with the file you supplied and 2.4ghz reception is up to the roof...
Got about 25dbm boost on all my devices and 2.4ghz reception is now much better than 5ghz (as it should).
Also i dont experince worse 5ghz signal like you described , from try to set 40mhz on 5ghz and not 80mhz and you should get better signal.
I will countinue to check for a few days that there is no side effects , but it really seems promising.
Just to update.
The wifi is working just fine for the past 3 days , 2.4ghz is great here and also 5ghz doesn't seems to suffer.
Did a test with official image and changed the file , same results so far, so if any one got a bad 2.4ghz reception with official image, they can give it a try...
I have also tried it. It brings new life to 2.4ghz, but i did notice the laptop wifi signal drops a few bars and then back up again on 5ghz
So if I understand correctly this file does improve the wireless performance, am I right?
As a side note: during the process of finding the file, I did tested all the remaining calibrations and this is the best of all (for 2.4 GHz). If this file does not improve the 2.4 GHz quality, there is nothing more that can be tested now.
Thank you for your work on porting wrt to this device. If i have to choose which calibration board file, then I would use your latest. The one in 'firefox send'
I see. So in the sake of the reviews for the file, I'll be including it with my next prebuilt. If I don't see any problem with the time, I will send the files to the Linux kernel developers so they can update the OpenWrt's version.
Note that OpenWrt does not manage the ath10k calibration files, is the Linux people that does that directly. Therefore, changes will take some time to reach the official build.
I just wanted to know how is the new 2.4 GHz calibration file performing for you. I've changed the original file and included a
default option for
testcalibration in my prebuilt wich I'm in the process of uploading right now, in a brave effort of testing the new file widely.
In the mean time, I would love to hear about your findings.
Here its working perfectly , great signal on 2.4ghz good on 5ghz.
I second that. Please use the latest blob. It's the best for 2.4ghz
Wonderful! That sounds like a problem solved.
Since I've uploaded the latest build in my repository, more people can test it directly from there. People who doesn't use my build can find the file in my source code. Eventually, it will reach OpenWrt but don't expect it to be anytime soon.
Instructions for the "installation" are available several post above this one. Basically, it's just a file replacement. Any feedback and reviews are welcome.
I just want to inform that I totally forgot to publish the latest "Release" on GitHub and I lost it. It doesn't matter, anyway, but it means that people that want to test the new wireless performance will have to wait for the next one (I've already built it, it's under testing to see if it have any major bug). I will skip the planned one entirely.
I'm close to trying the calibration file that improves 2.4GHz, and can probably do this by "trial and error," but rather than land on the side of "error" instead of "trial," I'm going to ask first just to be sure
This is what I have on my router:
The openwrt-1.02.oc-23c228.tar.gz source tar ball has a file called "board-linksys_ea6350v3.bin" in each of these sub-directories under the "calibration" directory:
ah_Y9803 default fcc_Y9803.au_Y9803 hw_1_Y9803
art eu_Y9803 hw_1_DK01 hw_1_Y9803.ic_Y9803
au_Y9803 fcc_Y9803 hw_1_DK01.au_Y9803 ic_Y9803
And now for the dumb questions....
Is "board-2.bin" the 2.4 GHz calibration file on my router?
Do I just replace "board-2.bin" with "board-linksys_ea6350v3.bin" (renaming it to "board-2.bin") and reboot to try out a new calibration file?
Finally, which calibration folder has the "board-linksys_ea6350v3.bin" file most likely to improve 2.4GHz?