Add support for Linksys EA6350 v3

I have noticed that when I connect to Internet through the 4G modem connected to the router USB port (instead of the WAN port) Instagram works perfectly. But on the other hand that traffic goes through another ISP so I'm not sure if it brings me any closer to why this happens.
A chrome debug also showed that it uses different hostnames in the Instagram image URLs for that ISP.

1 Like

What's the issue exactly?

I've been going through the commits for this device, comparing changes with other linksys devices and trying to clean up differences and remove some ambiguities. One thing I was wondering about was why /etc/init.d/linksys_recovery needs to reset a boot count in both u_env and s_env. Other devices only access s_env. Any ideas?

I believe s_env is mtd8, so there's this from my EA6350v3 w/snapshot:

# mtdinfo /dev/mtd8 -u
Name:                           s_env
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:16
Bad blocks are allowed:         false
Device is writable:             true
Default UBI VID header offset:  64
Default UBI data offset:        128
Default UBI LEB size:           65408 bytes, 63.8 KiB
Maximum UBI volumes count:      128

and this:

# hexdump -C /dev/mtd8ro
00000000  11 08 11 20 00 00 00 00  11 08 11 20 ff ff ff ff  |... ....... ....|
00000010  11 08 11 20 01 00 00 00  12 08 11 20 ff ff ff ff  |... ....... ....|
00000020  11 08 11 20 00 00 00 00  11 08 11 20 ff ff ff ff  |... ....... ....|
00000030  11 08 11 20 01 00 00 00  12 08 11 20 ff ff ff ff  |... ....... ....|
00000040  11 08 11 20 00 00 00 00  11 08 11 20 ff ff ff ff  |... ....... ....|
00000050  11 08 11 20 01 00 00 00  12 08 11 20 ff ff ff ff  |... ....... ....|
00000060  11 08 11 20 00 00 00 00  11 08 11 20 ff ff ff ff  |... ....... ....|
00000070  11 08 11 20 01 00 00 00  12 08 11 20 ff ff ff ff  |... ....... ....|
00000080  11 08 11 20 00 00 00 00  11 08 11 20 ff ff ff ff  |... ....... ....|
00000090  11 08 11 20 01 00 00 00  12 08 11 20 ff ff ff ff  |... ....... ....|
00000340  11 08 11 20 00 00 00 00  11 08 11 20 ff ff ff ff  |... ....... ....|
00000350  11 08 11 20 01 00 00 00  12 08 11 20 ff ff ff ff  |... ....... ....|
00000360  11 08 11 20 00 00 00 00  11 08 11 20 ff ff ff ff  |... ....... ....|
00000370  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Let me know if you need anything else (maybe PM if it's big). Any links to the above record format too?

Thanks, yes, that was was I was hoping/expecting to see.

The boot loader writes a new "record" on each boot consisting of

  • 11 08 11 20 -- "magic number" (marker)
  • 01 00 00 00 -- boot count
  • 12 08 11 20 -- checksum

From what I can tell on my EA8300, if the boot count is 3, the boot loader rewrites the environment and sets the next boot count to 1. I haven't confirmed it, but this should be what "flips" the partition on a boot-loop situation.

On "successful" boot, the OS is responsible to write a "0" record so that the boot loader knows boot went well.

The record is not overwritten, but appended. This reduces flash wear and is perhaps also the reason that boot_count from the environment is not used. (I've never seen anything but 0 in there and 3 in boot_part_ready). When the partition is "full", it gets erased and starts over -- only the last-written record has significant value.

The "challenge" is that NAND flash typically has a minimum write size, 2048 bytes, for example. So on a NAND-based Linksys device, these boot-count records are 2048 bytes long. When the Linksys device(s) was ported to the IPQ40xx platform, someone noticed that it was writing 16-byte records, not the 1-byte record that the MTD parameters show, and hard-coded 16 in for the platform in general. As a result, the "pure NAND" EA8300 had some pretty strange boot behavior because the code to reset the boot count was silently failing.

I've since rewritten package/system/mtd/src/linksys_bootcount.c to

  • Actually log success and failure
  • Auto-detect if the record size should be 16 or the MTD parameter (E6350v3 being the only exception I have found)
  • Return a meaningful error value (and update init scripts to ignore it, so as not to stop boot)

I'll make sure it's clean and put in a PR/patch as it impacts more than just the EA8300. If you have a chance to check it, that would be great!

If you like to amuse yourself, here's what I run from /etc/profile to "see" this in action. Yes, my s_env partition "rolls" one a week or so. Yes, it's an ugly script, but cut-and-paste for what was intended to be a diagnostic tool was the fastest as it evolved

rootfs: mtd13
89 bootcount entries. Last ten: 02 00 01 00 01 00 01 00 01 00 

printf "rootfs: mtd%i\n" $( cat /sys/devices/virtual/ubi/ubi0/mtd_num )
fw_printenv boot_part
fw_printenv boot_count
printf "%i bootcount entries. Last ten: " $( hexdump -C /dev/mtd8ro | sed -nEe 's/^[0-9a-f]+00  11 08 11 20 ([0-9a-f][0-9a-f]).*$/\1/p' | wc -l )
hexdump -C /dev/mtd8ro | sed -nEe 's/^[0-9a-f]+00  11 08 11 20 ([0-9a-f][0-9a-f]).*$/\1/p' \
    | tail -n 10 | tr '\n' ' '
printf "\n"

Thanks for the careful, detailed response around the boot count management. That's been helpful, and left me more puzzled about why boot_count from the environment is also reset for EA6350v3. I'll need to make some tests for my cleanup PR...

I'll certainly keep an eye open for your PR/patch, and look into testing using your scripts too. Thanks!

Well, looks like my RFC / RFT ended up on patchwork --

At least it hasn't gone down in flames yet!

Testing would be greatly appreciated!

  • ipq40xx
    • EA6350v3 (NOR boot)
  • ipq806x
    • EA8500
  • kirkwood
    • audi
    • viper
  • mvebu
    • armada-385-linksys-caiman
    • armada-385-linksys-cobra
    • armada-385-linksys-rango
    • armada-385-linksys-shelby
    • armada-385-linksys-venom
    • armada-xp-linksys-mamba
1 Like

Does this also apply to EA6350v3? I ask because this thread is for that device, however I do not see it in the list. Thanks!

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!