I've already updated the download link, so you can perform your tests if you want. The script is straight forward to use. You just run testcalibration in the terminal.
Windows 10 laptop with Intel Centrino 6300 3x3 802.11n wifi card. Wireless link speed report full rate on 2.4 and 5 GHz. eg. 300 Mbps on 5 GHz by Windows and LuCI. But speed tests are capped at 12-15 Mbps with recent builds on both 2.4 and 5 GHz. Intel haven't updated the windows driver since 2015 as the wifi card is discontinued.
The speed issue does not exist when I use very old 19.07 snapshots such as r10269 (circa July 2019). Identifying the commit which causes this issue would be time consuming. I don't have any snapshots between r10323 and 19.07.0-rc1 to help narrow down the search.
I reported the symptoms within this bug report at the time, but it became evident later it was not the same problem as the Hostapd 2.9 regulatory domain bug.
https://bugs.openwrt.org/index.php?do=details&task_id=2679
However, the biggest problem was I then discovered an old 2.4 GHz device, Roberts Stream 83i internet radio (Frontier Silicon), which uses 802.11g was suffering from severe audio buffering. I discovered it could only maintain a 2.4 Mbps downlink speed reported by LuCI even when the radio was only a foot away from the EA6350v3. My laptops and a newer 802.11bgn capable internet radio don't have speed issues on 2.4 GHz. (I haven't tried using a very old 802.11b/g only wifi card in a laptop to see if same issue exists)
This internet radio has no issues connecting to former Home Hub 5A (Qualcomm AR9287 bgn wifi) access point running LEDE or OpenWrt - at 54 Mbps. As I couldn't fix or replace the Roberts radio, I decided to return to Linksys OEM firmware to resolve this compatibility issue.
Off topic but thanks: My laptop is a thinkpad p50 running ubuntu 18.04. It doesn't want to connect to the AP faster than 300 mbps. I can't find any way to try and force it to go faster, but I think it is the laptop that is at fault here.
I also have a roberts radio, a stream 93i, but haven't noticed any issues with it (it supports 5GHz).
I use a BT business smart hub (with native FW) as my main router, so the EA6350v3 is only for bridging the wifi over to ethernet.
@NoTengoBattery Hi!
Sorry if it's not the appropriate thread to ask this question but since you are the one who ported EA6350v3 to openwrt I think you're the best person to ask.
I want to use the Openwrt official 19.07.1 build, not a custom build for easier maintenance.
I have a Linksys EA6350v3, my ISP uses optical fiber adapter that I plug to WAN port of the router. The ISP use VLAN 100 for WAN. Could you please help me to correct /etc/config/network so it works fine using the official build?
(I copied this one from another user with a wrt32x)
config interface 'wan'
option proto 'dhcp'
option ifname 'eth1.100'
option delegate '0'
option peerdns '0'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 5t'
option vid '1'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4t 6t'
option vid '100'
Hi.
There is a problem in the VLAN with this device, which I cannot help since I don't have VLAN to test, and by the fact that this build does contains the correct behavior, therefore I cannot directly help with the official build regarding to VLAN.
One thing is for sure: in the official build, VLAN 1 and 2 are reserved by the hardware and there is no way to use them. Your first step is probably moving your VLAN 1 to 3 and 2 to 4.
Hey I used vlan 100 vid 100 and ports 0t 5t and it worked fine, thanks!
@NoTengoBattery Thanks for the custom build with the VLAN patches! Works great.
Has anyone been able to get 6in4 working on this?
I believe the 6in4 package isn't installed, but it requires a kernel module (kmod-sit) which isn't available for this specific build.
That's right, 6in4 is not included. However, I can trivially include it in the next build if you need it.
That would be great.
Otherwise I can always attempt to make a custom build, although I'll have to some reading into building OpenWRT.
Is 6in4 the only extra thing that you need? I will be uploading a new build soon so if you need another software that requires kernel modules, it would be nice to know.
That's it for me 
I believe it's the only missing part to get 6in4 working with tunnelbroker.
All done, then. Link already updated
Thanks! Currently on holiday, but will definitely upgrade when back.
I can confirm that 6in4 is working fine, got it setup successfully with tunnel broker.
1 Like
I've been using this build (rebuilt to include 6rd and a few other packages but no other changes of any significance) as my default router for over a week now. This is with gigabit fiber internet and two routed local subnets. It's rock solid and the performance is excellent:
LAN, between two machines on separate routed subnets (no NAT, very few firewall rules):
Iperf/iperf3: 930-940 Mbps and stable.
WAN, NAT, nearly stock firewall rules:
Speed test, provided by my ISP CO: typically 800-850Mbps down, 600-700Mbps up.
Speed test, DSL reports: avg 85-90% of that.
(Previously when using an x86_64 build on a Sandy Bridge i5 with i340 NICs I was getting a solid 940Mpbs up/down on a fairly regular basis. But we may be comparing apples with oranges: Covid-19 stay-at-home behavior may be affecting area broadband performance generally, there are a lot of tech workers around here who'll be telecommuting now, and a lot of people staying at home watching Netflix)
(Edit: Finally dawned on me that I'm using a single LAN port from the router to a Gigabit switch for simultaneous tests, resulting in a bottleneck that would explain the ceiling observed; so maybe ignore the whole paragraph that used to be here. To do this right all the testing should be done on a bench with no links in common between simultaneous bandwidth tests.)
Anyway, tremendous work. I really like this router now.
1 Like
Thanks for the custom build, I have few questions,
-
if I install your openwrt custom build / or generic openwrt, and after sometimes there's an update to this, do I have to reboot to original linksys firmware first then install custom rom if I want to retain at least 1 original linksys firmware intact?
-
I'm interested in building your custom openwrt but with different modules built-in, currently I don't need 6in4 but I want to install basic build with usb 3.0 storage +extroot extension and wpad full (replacing wpad-mini), is there any tutorial on how to do it? thank you.
-
Is this build based on 19.07.2?
Hi, tnaks for your questions.
- Yes, that is right. However, my custom build does have a way to reverting back to the original firmware at any time, given that you have the firmware from the Linksys website.
- OpenWrt does have a nice "wiki" on how to do that, the main difference is that you will be using my copy of their repository instead of the original. You probably will need to perform several changes, because this custom build already uses the OEM partition as an extroot (yes, you can access the full 43 MB partition used by the Linksys firmware) and it's designed to defend itself against that kind of changes in the runtime. I can help you to understand my modifications if you really want your custom build.
- Yes and no. The current in my repository (not updated since a long time due to the virus thing, will update it soon) is based on 19.07 plus all the modifications made in master. This is based on the snapshot brach, to say it another way. So, by this date it will be based on the 20.xx. If you want a stable release, the downloadable file contains the patches that can be used on the top of any 19.xx and 20.xx branch.
It would be nice to have your results, anyway and if you can, it is valuable feedback to me; since I live in a country where 10MiB/s is a corporate luxury and can not test this kind of thing.
And thanks for using my build and your feedback, always welcome to know more about use cases!
I've done some significant changes and OpenWrt have done other more (like upgrading the kernel) so I would like to know if it still performing good now, I was a bit distracted from OpenWrt due to the virus thing, that's why I didn't updated my repo but if you can test it agan when I upload the new version, it will be a nice feedback to have!
The results above are accurate: the thing I disclaim in parentheses at the bottom of the post refers to something in an earlier version of the comment, which I edited out.
I've just reproduced them:
Iperf3 between routed LAN segments (e.g. between hosts 192.168.10.80 <-> 192.168.20.41, where the 10 and 20 nets pass through separate interfaces on the ea6350, without NAT and with only a few simple firewall rules:
[ 4] local 192.168.10.80 port 38268 connected to 192.168.20.41 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 119 MBytes 1.00 Gbits/sec 1 1.74 MBytes
[ 4] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 0 1.82 MBytes
[ 4] 2.00-3.00 sec 110 MBytes 923 Mbits/sec 1 1.38 MBytes
[ 4] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 0 1.46 MBytes
[ 4] 4.00-5.00 sec 110 MBytes 923 Mbits/sec 0 1.52 MBytes
[ 4] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 1.56 MBytes
[ 4] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 0 1.59 MBytes
[ 4] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 0 1.62 MBytes
[ 4] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 1.67 MBytes
[ 4] 9.00-10.00 sec 110 MBytes 923 Mbits/sec 0 1.72 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec 2 sender
[ 4] 0.00-10.00 sec 1.08 GBytes 929 Mbits/sec receiver
That's typical in both directions: sometimes more retransmits.
Centurylink speedtest: provided by the ISP and only 1 or 2 ms ping away, so only contending with nearest neighbors for FTTH bandwidth. Includes NAT, firewall rules mostly OpenWrt stock.
(Edit: earlier screenshot showed an unrepresentative 23ms jitter. Just did this one, a bit more typical. Note this is without disabling various other internet using devices such as chromecast, etc.)
Built from your v0.32 release, by git cloning the fork point from the mainline OpenWrt repo and then applying your .oc patches. My only .config modifications involved the addition of packages. Runtime changes, nothing relevant, though for now I've reverted to using dnsmasq (+stubby) rather than unbound, mostly because I need more comprehensive dhcp option support.
Looking forward to your next release, but I'm pretty happy now. The responsiveness is so much better than mainline!
1 Like
Hmm, I read that you compiled your own version. I have some notes to add:
- Instead of modifying the
.configdirectly, modify the configuarion seeds. Since thea2cf87-v1.00version (and for people that want to further customize my work), I added some "marks" in the configuration seeds that indicate that these settings should not be modified in any way. You can generate a.configfile by concatenating the seeds:cat global.seed modules.seed image.seed > .config - Same is true for the kernel seeds. You should concatenate your modified kernel seeds like this:
cat kernel.seed >> target/linux/ipq40xx/config-4.19andcat kernel.seed >> target/linux/ipq40xx/config-5.4. - The initial configuration for the device upon the first boot of a different version is in
files/bin/bootz, it's a shell script with UCI commands that run when a canary file is not found. You can customize there the IP, your users and many other things during the first boot. - There are several files that are not safe to modify or delete, like the preboot scripts which, on mistake, will soft-brick the device, rendering even the failsafe mode useless.
- There is an script in
files/etc/extrafiles.txtthat have to be run in the root of the source code to set the correct file permissions, since they are "inherited" to the image and some files with corrupted permissions can lead to security flaws; plus, some programs likesshwill refuse to use them. - The notes contains a line that says "Based on OpenWrt commit xxx". You probably want to checkout that commit before applying the patches.
I'm in the proccess of uploading the package to GitHub, so expect it to be there soon and thanks for using this custom build and will be nice to have your test to compare against the 11737-v0.32 version, as changing the kernel can have significant performace differences.
2 Likes