Add support for Linksys EA6350 v3

Your question is a bit off topic because this thread is related to the device support, as is. But if you are wondering: the device is pretty capable of running almost all OpenWrt features. OpenWrt itself is a powerful firmware, so if you can do what you want with an OEM firmware, it's very likely that you can do it or even more with OpenWrt. As all firmwares, it starts with a generic configuration and from there you can personalize your router.

Related to configuration and setup: read the OpenWrt's wiki.
Related to my custom build, I will answer questions and problems if you open a issue in my GitHub's fork.
Related to this hardware, this thread is the correct.

Better link to the documentation:

Hi @NoTengoBattery, that test_calibration script sounds very interesting (even though I'm very pleased with the Wifi on Release 9 as it is). And you are correct, if it's that easy to change it's not out of my league anymore :slight_smile:
I found the calibration board files at your github download page but I can't seem to find the scripts.
Or should I wait for release 10 of your firmware build?

All the thing I've done to get my custom build, and all the things you need to reproduce my work is on my GitHub fork of OpenWrt. For example, the script is here.
Those are a dedication to the public domain so feel free to do what you want without even noticing my existence. :wink:

You can, of course, use them in my custom build that I can guarantee that they work as expected, out of the box and as I documented them. But I will not send those files to upstream because they don't belong there, and I'm not searching to pass their quality control, but mine and the critical eye of people that know more than me.

P.D.: I will send the calibration board files to upstream and to infradead as soon as we feel confident of the results. Please: do not send the files yourself. Let's be really sure first.

Just created this account to say Release 9 is perfect so far for me. I started around release 4; at the time, 2.4G range was about 5 meters, and 5G wouldn't even authenticate. Now though it's flawless. Great range, great throughput.

Thank you for all your work @NoTengoBattery!

I have now tested all the calibration board files for both 2.4 and 5 GHz, thanks a lot for making this possible @NoTengoBattery.

For 2.4 I would say that: hw_1_DK01 and hw_1_Y9803 are the best ones and gives very similar results. Hard to tell which one is the best, they are both great and much better than the other ones.

For 5 GHz I would say that ah_Y9803 and ic_Y9803 are the best ones, very similar results but if I had to pick one I would say that ic_Y9803 is the winner for 5GHz.

These results are the best I have seen, if you need more speed than this connect a cable :slight_smile:

iperf3 -c
Connecting to host, port 5201
[  4] local port 65247 connected to port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  61.1 MBytes   512 Mbits/sec
[  4]   1.00-2.00   sec  73.3 MBytes   615 Mbits/sec
[  4]   2.00-3.00   sec  76.5 MBytes   641 Mbits/sec
[  4]   3.00-4.00   sec  78.5 MBytes   660 Mbits/sec
[  4]   4.00-5.00   sec  79.8 MBytes   669 Mbits/sec
[  4]   5.00-6.00   sec  74.2 MBytes   622 Mbits/sec
[  4]   6.00-7.00   sec  78.8 MBytes   661 Mbits/sec
[  4]   7.00-8.00   sec  78.9 MBytes   662 Mbits/sec
[  4]   8.00-9.00   sec  77.3 MBytes   648 Mbits/sec
[  4]   9.00-10.00  sec  79.4 MBytes   666 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   758 MBytes   636 Mbits/sec                  sender
[  4]   0.00-10.00  sec   758 MBytes   636 Mbits/sec                  receiver

iperf Done.

iperf3 -Rc
Connecting to host, port 5201
Reverse mode, remote host is sending
[  4] local port 65244 connected to port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  50.9 MBytes   427 Mbits/sec
[  4]   1.00-2.00   sec  56.9 MBytes   477 Mbits/sec
[  4]   2.00-3.00   sec  55.8 MBytes   468 Mbits/sec
[  4]   3.00-4.00   sec  60.2 MBytes   505 Mbits/sec
[  4]   4.00-5.00   sec  63.5 MBytes   533 Mbits/sec
[  4]   5.00-6.00   sec  65.1 MBytes   546 Mbits/sec
[  4]   6.00-7.00   sec  64.2 MBytes   538 Mbits/sec
[  4]   7.00-8.00   sec  64.9 MBytes   544 Mbits/sec
[  4]   8.00-9.00   sec  65.3 MBytes   548 Mbits/sec
[  4]   9.00-10.00  sec  66.0 MBytes   553 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   614 MBytes   515 Mbits/sec  128             sender
[  4]   0.00-10.00  sec   614 MBytes   515 Mbits/sec                  receiver

iperf Done.

Thank you for your testing!

I also did my testing and I can confirm that hw_1_Y9803 is better for me than hw_1_DK01. On the other side, I don't know for what calibration is the log you sent.

I think that with this confirmation I can safely update the files in upstream and send them to I think they are a safe bet and if someone is experiencing poor performance, they can test other calibration files.

For the sake of clarification, the files that will be sent to upstream will be:

  • 2.4 GHz: hw_1_Y9803
  • 5 GHz: ic_Y9803

I didn't tested ic_Y9803 until yesterday, so my prebuilt use hw_1_DK01 for 2.4GHz; ah_Y9803 for 5GHz, but yesterday I changed my mind.

Edit: not ah_Y9803, it's au_Y9803. My documentation was bugged. LOL.

P.D.: New prebuilt available: v0.01. That prebuilt comes with my custom scripts. It have a little bug in failsafe mode but, well, it's not that bad. I've fixed it and it will be available in the next week (v0.02).

Great! Yes that sounds like the winning combo!
Those logs I pasted above were for 5 GHz: ic_Y9803
For 2.4 GHz: hw_1_Y9803 i got the ones below:

iperf3 -c
Connecting to host, port 5201
[  4] local port 65207 connected to port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  11.6 MBytes  97.3 Mbits/sec
[  4]   1.00-2.00   sec  11.6 MBytes  97.3 Mbits/sec
[  4]   2.00-3.00   sec  13.5 MBytes   113 Mbits/sec
[  4]   3.00-4.00   sec  12.3 MBytes   103 Mbits/sec
[  4]   4.00-5.00   sec  12.6 MBytes   106 Mbits/sec
[  4]   5.00-6.01   sec  13.3 MBytes   111 Mbits/sec
[  4]   6.01-7.00   sec  12.3 MBytes   104 Mbits/sec
[  4]   7.00-8.00   sec  12.6 MBytes   106 Mbits/sec
[  4]   8.00-9.00   sec  12.5 MBytes   105 Mbits/sec
[  4]   9.00-10.00  sec  13.4 MBytes   113 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   126 MBytes   105 Mbits/sec                  sender
[  4]   0.00-10.00  sec   126 MBytes   105 Mbits/sec                  receiver

iperf Done.

iperf3 -Rc
Connecting to host, port 5201
Reverse mode, remote host is sending
[  4] local port 65209 connected to port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  8.52 MBytes  71.5 Mbits/sec
[  4]   1.00-2.00   sec  11.3 MBytes  94.4 Mbits/sec
[  4]   2.00-3.00   sec  11.5 MBytes  96.9 Mbits/sec
[  4]   3.00-4.00   sec  12.2 MBytes   102 Mbits/sec
[  4]   4.00-5.00   sec  11.4 MBytes  95.8 Mbits/sec
[  4]   5.00-6.00   sec  10.5 MBytes  87.7 Mbits/sec
[  4]   6.00-7.00   sec  11.4 MBytes  95.5 Mbits/sec
[  4]   7.00-8.00   sec  9.35 MBytes  78.5 Mbits/sec
[  4]   8.00-9.00   sec  10.9 MBytes  91.6 Mbits/sec
[  4]   9.00-10.00  sec  11.1 MBytes  92.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   109 MBytes  91.5 Mbits/sec  168             sender
[  4]   0.00-10.00  sec   109 MBytes  91.1 Mbits/sec                  receiver

iperf Done.

Can someone give me a summary of how stable is the current snapshot for this device?

When can a stable openwrt release be expected for this device?

Hi @martin8, the current snapshot from the official openwrt website is broken, the build by @NoTengoBattery is very usable and has a lot of applications already installed.

If you are still on the stock firmware, it quite easy to switch back if you use @NoTengoBattery build as it includes advance reboot. So you can reboot to stock if you want

Hopefully this device makes it into the next official release, which will only be possible if lots of people test the builds and give feedback of any bugs

Hi all
Just a quick note to anyone testing the builds for this device.
As this device has two partitions i always reboot with advance-reboot to the partition i want to keep before flashing any new build.
That way my first partition is the one i use daily and the alternate one is the test one.

You are right, @imi2003.
@martin8 First of all we cannot discuss about when OpenWrt itself will be stable. That's off topic. The device running OpenWrt (my prebuilts to be precise) is performing well and even if not bug free, it's pretty stable at this point (just some minor annoyances).

Answering to @imi2003 I just want to clarify that my build includes a script for reverting back to stick at any time. The only prerequisites are a shell with root access and an original Linksys firmware image (downloadable from the device's support page).
Edit: typo, change stick with stock

And a question for all of you: Shall we change the device name to Civic?

Also an announcement: I've sent the calibration files to upstream and infradead.

Hello, all.

I just published a new prebuilt. I did this instead of waiting the next week because this has an important change that you may want to have as soon as possible. Some changes are as follows:

  • New apps
    • RP PPPoE ([1] disabled by default)
    • Ntftables QoS ([1] disabled by default, useful for bandwidth limit if you need or want a WiFi guest network with limited throughput. Built-in because it requires two kernel modules and those are not easy to install as I don't have a server :wink: .)
  • Special thanks to @imi2003 and @anders in the release notes
  • Rebuilt from scratch using the latest released Linaro Toolchain
  • And the important change: synced with master, this commit: pq-wifi: update ipq-wifi for Linksys EA6350v3
  • [1] Fixed minor annoyances with Dropbear and OpenSSH in Safe Mode
  • Fixed uhttpd/OpenSSL (https works on Safari but not on Chrome and I don't know why)

Not a full changelog.

[1]: The files changed in the running firmware will not be updated with the versions in the image: the changes are only effective on Fail Safe mode and after the first boot.

1 Like


Linksys calls it EA6350, so we call it EA6350 too.

That is false. Linksys call this device Civic.

1 Like

There's some question as to what the internal at the board level should be called (such as DTS), but, from an end-user perspective, I'm of the opinion that they should be "human readable" for someone trying to find the right firmware to flash, as well as to configure in the build tools.

Linksys, as almost all OEMs, uses code names for their devices.
I'm not saying to change the commercial/user friendly name (which is EA6350v3) to "Civic". I'm telling about changing the internal name to Civic.

As an example, take a look at Linksys Cobra.

For sake of completeness: Advanced Reboot.

That is false. :slight_smile:





The download link point to

(similar for v1 + v2)

The Linksys userguide calls it EA6350


wikidevi calls it EA6350 too:

Why on earth should the EA6350 be called Civic? does not find anything for "Linksys Civic"
grafik dito:

You are not understanding.

I kindly ask you to understand my statement first. Thank you.

Sorry, but I really don't understand what you want to achieve by renaming the device that is widely known as EA6350 to "Civic".

Can you please explain more detailed?