Add support for Linksys EA6350 v3

My typo -- edited, thanks.

To be clear, the boot-counter reset works properly for the EA6350v3 without the patch!

1 Like

I don't want to be rude but you are plain wrong.

Not all my job is merged. Since I've gone from this thread I've received 50+ PMs (which I will not answer) agking me to help them to revert bact to stock.

I've made a script which safely and easily can do that. It does a full check of the image (version, integrity, size, etc) and is an one-liner, it literally can't be easier than copying the image to the router and calling the script with the path to the image. That is a big value which is not upstream because it does not belong there.

Not to mention that all of we have a good wireless performance because @anders and I used another script that I made (for easily and safely testing calibration boards, again with full check and all the available calibration files from stock crafted with love to the right format, as they are not usable as-is) to get the best performance possible.

Also they were built using Linaro GCC and stripped using binutils's strip instead of sstrip, resulting in a objectively faster yet smaller binary. Not to mention the convenience of a binary that just works as expected for a home/small business router (with web GUI and such).

Let me tell you that the script for reverting to stock by itself is a big deal.

Hi @NoTengoBattery thanks for the reply, however: care to explain which of all my posts is plain wrong? and care to help us solve the issue here? the problem we see is that the images form instagram and other social network sites do not load when using the wifi. Wifi speeds are OK, and if using the LAN cable, images load fine, but we do not know for sure where the issue lies.

Has anyone managed to get the DLNA server running on this? I have the service installed and its showing under Services in the fw and my devices are detecting it, but no media is detected. Is it just a matter of creating a folder hierarchy on the storage device or is it something more involved than that?

Moving discussion of this specific issue to

Hi i've just noticed something weird.
I've not been able to update my maps on here maps (android) for a while. But today i disabled the wan6 IP6 DHCP client in the interfaces section. and now i am able to update my maps, before the app would complain it was offline.
My ISP does not provide IP6 addresses, could someone please try this on their setup to see if it fixes the instagram problem
I am also using OpenDNS addresses

1 Like

Following the recomendations given to me in this community while seeking for a good cheap router with wifi ac support compatible with openwrt, I will buy this router.

I know I have to install the development snapshot.
Is there any drawback right now? Something that is not working or is working weird?
Something like wifi 5 GHz not working?

As long as I have read in this post it is working correctly.

If I have understood well, after installing the snapshot version provided in the router page, I will have openwrt with no luci web interface, and I will have to install luci afterwards.

If something goes wrong and the router bricks, is there an easy way to go back to stock firmware without soldering a serial interface?

I mean if there is a reset method that lets you upload the firmware via web or TFTP.

The documentation sends you the the generic debricking instructions, which does not help to know if you can debrick it without a serial interface (soldering in a new router will void warranty completly).

Thank you all for your work.

I will try to help in testing the router (I am not a low level developer, I cannot help in that).
Somebody told me therewas a pool for voting for inclusion of this router in the liist of compatibility hardware, but I don't find it.

Because such a pool does not exist.

1 Like

There is still the issue with that for certain ISP:s, Instagram and similar applications may not work properly from Wifi on this router. I have not checked for the latest month or so but I guess the bug is still there.

Regarding reverting back there is a good script for this but unfortunately the author decided to shut down the repo some months ago. But being a big fan of @NoTengoBattery's work I of course had a copy of the repo so I can probably dig the script up if it's needed.


Thanks a lot.

I am afraid of jumping in this router and having problems, as you say.

I am deciding between this and the AVM friztbox 4040.
May be I would better wait a bit to see if the problem you comment gets solved.

If my daughters don't get access to photos in Instagram they will hang me.

Reverting back to oem firmware in case of problems is important too, but it seems to be solved with the script you mention.

It is a pity it seems a wonderfull router. I will see if I can debrick my tp-link 1043N v1.3 and install openwrt in it in order to wait a bit before buying.

What's the status of this?

I flashed the OpenWRT snapshot [] as per and I'm struggling to configure the EA6350v3 like I configured my other OpenWRT devices, which is: Access point only, WAN as VLAN trunk, LAN 1 untagged to WAN VID n, LAN2/3 to WAN VID m, LAN4 untagged fallback port, SSIDs 1 to 4 to WAN VIDs a to d.

Does it not work b/c a) I don't understand how to do that properly for a eth0 + eth1 HW, b) it's not supported and a "VLAN on WAN port" not working marker is missing for the EA6350 (it's present for the FB4040), or c) the exact switch details aren't clear?

Is there a recommended way to configure such a scenario if eth1 is also available as a port of eth0?

At least as I understand the switch in the similar IPQ4019 and how it is configured in the DTS, one Ethernet interface is "hard-wired" to the "Internet" physical port, and the other to the other four ports. Packets that come in one of the hard-wired ports are sent only to the associated Ethernet interface. It is a challenge for some configurations (such as VLAN trunking over the Internet port).

I've poked at it quite a bit, but the qca8k / DSA code hasn't even settled down enough on mainline Linux (5.x) to convince me that it is worth trying to back port yet. Notably absent in the mainline code, last I checked, was being able to manage VLANs. within the virtual bridge.

Sounds like

  • all IPQ4018/4019 devices should have the "no VLAN on WAN port" remark which the FB4040 has,
  • I need to use one of the switch ports as the LAN trunks and then hopefully that'll work

Hi, I've just tried out your marvelous work, and generally it works like a charm.
But after a while I noticed that the space of my rootfs isn't as much as I expected:

As you can see the whole space of rootfs is only about 26MB, which is far less than the 128MB.
I'm wondering what's happening. And how can I make it use the whole 128MB instead of only a quarter of them?
Thanks in advance!

The 128 MB gets split into smaller parts, which include two complete sets of firmware, each of which is 40 MB for kernel and file system, combined, 37 MB for the file system (split between ROM and overlay).

No flash layout on

From the DTS

                partitions {
                        compatible = "fixed-partitions";
                        #address-cells = <1>;
                        #size-cells = <1>;

                        kernel@0 {
                                label = "kernel";
                                reg = <0x00000000 0x02800000>;
                        rootfs@300000 {
                                label = "rootfs";
                                reg = <0x00300000 0x02500000>;
                        alt_kernel@2800000 {
                                label = "alt_kernel";
                                reg = <0x02800000 0x02800000>;
                        alt_rootfs@2b00000 {
                                label = "alt_rootfs";
                                reg = <0x02b00000 0x02500000>;
                        sysdiag@5000000 {
                                label = "sysdiag";
                                reg = <0x05000000 0x00100000>;
                        syscfg@5100000 {
                                label = "syscfg";
                                reg = <0x05100000 0x02F00000>;
                        /* 0x00000000 - 0x08000000: 128 MiB */

The syscfg partition could conceivably be used (0x02F00000 = 47 MB), but not easily combined with the firmware partition.

1 Like

Thanks a lot! I later found this dts file and a more detailed flash layout of WRT1900ACS.
After about 20h's investigation, I finally made it to use the whole NAND and not recompiling the openwrt.

I'll enclose an instruction here for those who needed.
WARNING: these instruction are for expert users only. Serial connection is needed. Sysupgrade will be unusable. U-Boot could be destroyed, leading to bricked device if you operated on the wrong NAND device. Please don't follow the instruction unless you fully understand what's going on.

  1. First of all, backup everything(sysdiag and syscfg): use either use the mtd command manually or use the backup feature in LuCI, in case they are useful.
  2. To make our life easier, we also backup the ubi volumes here using the following commands
dd if=/dev/ubi0_0 of=/tmp/ubi0_0.img
dd if=/dev/ubi0_1 of=/tmp/ubi0_1.img
  1. If you had a look at the sysdiag volume you can see that there's nothing (all of 0xFF), so things become easy now as we can merge everything into a big rootfs
  2. Access the U-Boot console through TTL serial, and first of all we disable the auto_recovery feature
setenv auto_recovery no
  1. Then we'll execute the mtdparts to partition our flash
setenv mtdids
setenv mtdparts
setenv mtdids nand1=spi0.1
mtdparts add nand1 0x8000000 kernel
mtdparts add nand1 0x7d00000@0x300000 rootfs

(note the nand1 here is from the output of nand info)

  1. After partition we'll make the ubi volume and ubifs
ubi part rootfs
ubi create rootfs 0x26c000
ubi create rootfs_data

You can see the following output if successful:

(EA6350v3) # ubi create rootfs 0x26c000
Creating dynamic volume rootfs of size 2539520
(EA6350v3) # ubi create rootfs_data
No size specified -> Using max size (122658816)
Creating dynamic volume rootfs_data of size 122658816
(EA6350v3) # ubi info l
UBI: volume information dump:
UBI: vol_id          0
UBI: reserved_pebs   20
UBI: alignment       1
UBI: data_pad        0
UBI: vol_type        3
UBI: name_len        6
UBI: usable_leb_size 126976
UBI: used_ebs        20
UBI: used_bytes      2539520
UBI: last_eb_bytes   126976
UBI: corrupted       0
UBI: upd_marker      0
UBI: name            rootfs

UBI: volume information dump:
UBI: vol_id          1
UBI: reserved_pebs   966
UBI: alignment       1
UBI: data_pad        0
UBI: vol_type        3
UBI: name_len        11
UBI: usable_leb_size 126976
UBI: used_ebs        966
UBI: used_bytes      122658816
UBI: last_eb_bytes   126976
UBI: corrupted       0
UBI: upd_marker      0
UBI: name            rootfs_data

UBI: volume information dump:
UBI: vol_id          2147479551
UBI: reserved_pebs   2
UBI: alignment       1
UBI: data_pad        0
UBI: vol_type        3
UBI: name_len        13
UBI: usable_leb_size 126976
UBI: used_ebs        2
UBI: used_bytes      253952
UBI: last_eb_bytes   2
UBI: corrupted       0
UBI: upd_marker      0
UBI: name            layout volume
  1. Then we can recover our backup of ubifs
tftpboot 82000000 test_0_0.ubi
ubi write 82000000 rootfs 26c000
tftpboot 83000000 test_0_1.ubi
ubi write 83000000 rootfs_data 1e84000
  1. Then we need to setup the bootargs
# First we backup the old bootart
setenv partbootargs_old $partbootargs
# Then we overwrite with new one
setenv partbootargs_old "init=/sbin/init $mtdparts ubi.mtd=11,2048 ubi.block=0,0 root=/dev/ubiblock0_0 rootwait ro"
  1. Now we can try to boot again
run bootpart1
  1. As you can see, the ubi volume is resized, however the fs refused to resize, so I entered the failsafe mode and did a full copy
# In failsafe console
mkdir /tmp/ubi01
mount  -t ubifs /dev/ubi0_1 /tmp/ubi01
mkdir /tmp/ubi01_bak
cp -a /tmp/ubi01 /tmp/ubi01_bak
umount  /tmp/ubi01
ubiupdatevol /dev/ubi0_1 -t
mount  -t ubifs /dev/ubi0_1 /tmp/ubi01
cp -a /tmp/ubi01_bak/* /tmp
umount /tmp/ubi01

(I'm not that familiar with cp command and please adapt your command accordingly)

  1. Done!


Use of dd to copy to or from NAND flash can lead to disasters.

NAND has both "data" and "metadata" stored in its cells. Often there is a block of 2048 data bytes, then 64 or 128 metadata bytes, which include the error-correction (ECC) data and the bad block marks (BBM).

Using dd to copy from NAND means that the ECC may not be applied to the raw bits. It is common for at least a few bits of NAND to be "flipped" and the ECC is used to correct those, typically up to 8 bit errors per block.

Overwriting the metadata can easily result in the NAND and its driver considering the flash bad. Anything other than 0xff in either of the the BBM positions will mark the block as bad. Excessive errors perceived because of corruption of the ECC can result in the driver marking the block as bad.

NAND should only be manipulated with tooling that "understands" NAND, such as mtd and nand-utils.

Yes, the above appears to manipulate the UBI-layer devices, but even there, UBI manages its own set of metadata (including wear monitoring and bad-block marking and reservation), which is influenced by the underlying flash's state.

Second problem is that changing the partitioning through bootargs is dangerous, at best. Many OpenWrt kernels ignore some or all of the bootargs, or "mangle" them in very specific ways.

Thirdly, you've disabled the dual-firmware feature and automated fall back. If you look at the source, you'll see that sysupgrade flashes the "other" firmware version, autorecovery is set, and that the selected firmware is "flipped" as well. (See /lib/upgrade/

Also, at least on the similar EA8300, the U-Boot TFTP flash mechanism has limits on the size of and location of the images it flashes. This repartitioning would require further changes to the U-Boot system to be robust. It also likely makes it very difficult for anyone to "return to stock" without either a very complex process or serial access to U-Boot. U-Boot also expects the kernel and alternate kernel to be in specific locations for boot. Further, any corruption of the U-Boot environment will result in it being recreated from compiled-in defaults, likely leading to an unbootable device.

I don't have any serious qualms about properly repartitioning the device through the DTS for personal use, or someone working through all the issues of changing the partition sizes and submitting changes for review. Those issues include at least:

  • Booting, including when the U-Boot environment is recreated from defaults
  • Retaining dual-firmware behavior, including automated fail-over on failed boot series
  • sysupgrade
  • Flash from OEM
  • U-Boot flashing of images
  • Return to stock for non-expert users

Obviously you know there's UBI layer, so in fact everything about the NAND should be forgotten :wink:
To some extent I believe that you also mistook something: I didn't use dd on the NAND or raw UBI device. Instead I used it on a UBI Volume.
For reference:
The UBI layer is like a harddisk (or controller), the UBI volume is simply a logical volume on it. There's nothing related to the UBI volume metadata as it's an internal structure and is stored in 2 PEBs as a separate volume. Just like everyone uses dd to backup their file system on desktop computer, here we can also do so as UBI is an robust abstract layer above the fragile little NAND.

For the bootargs, I carefully reviewed the bootlog and the source code and patches of mtd partition parser in the OpenWRT source tree, which shows that the kernel is accepting cmdlineparts before the fixed-partitions, and that's why I can pass them through the bootargs.

As for the repartitioning, I've known it's quite dangerous, and considered that the sysupgrade will erase everything on the data partition, I won't needed to use this feature and will use U-Boot or mtd/ubiupdatevol instead. It's simply a trade-off. But it's really my fault not to mention it in my previous post (Sorry I forgot).

When it comes to U-Boot, there's nothing to worry. Command will fail immediately if we choose wrong nand (because the size of NAND is different). As long as we are not making too many mistakes, the U-Boot won't be affected as it's safely stored in another 2MiB NOR NAND.

When it comes to the return to stock, it is also a trade-off. In fact, if anyone can follow the instruction above, he must have a serial connection, which is a prerequisite, so that shouldn't be a problem at all.

As for the compiled default, I admit that the U-Boot hardcoded the location of kernel in its partition table, which can be seen from smeminfo. However I disabled the autorecovery. As long as we are not using the sysupgrade function, nothing dangerous will happen :slight_smile:

PS: I assumed that the instruction above is for expert user only, as it needs a serial connection. I'll change the post to add a warning.


Thanks, greatly appreciated.

Many readers here are not experts. Many blindly follow instructions, especially when it promises "more for free" to them, resulting in bricked devices or loss of unrecoverable data (such at ART and other cal data).

The subtle difference between raw NAND, UBI device, and file system volume is one that most would miss, especially if used in a different context. (Happens all the time, "But why doesn't it boot? I saw someone with a Model X do it, so I followed what they said for a Model Y.")

NAND is particularly sensitive as its metadata is exposed through its interface. In contrast, a hard drive or "real" SSD hides it all in the controller (both media-coding level and ECC on top of that), behind the SATA, USB, ... interface that the OS generally sees.


Haha the UBI can refer to UBI layer, UBI volume and UBIFS, which is quite confusing. I'm also quite grateful for your pointing out. I'll pay more attention and add warning and reference in my future post.:yum:
Talking with you also makes me have a more thorough understanding towards UBI and NAND :laughing:

1 Like