Add support for Linksys EA6350 v3


@NoTengoBattery builds are gone for good. His work has been merged into official OpenWRT devel snapshots starting Feb 21 2019, and you can get nice 2.4 and 5GHz speeds. Support is still not perfect though: you have to install luci manually, and when you do that, the switch configuration does not display the WAN port, so you can't add VLANs to it and have to configure things using the command line, but it does seem to work.


I have the snapshot factory build installed and everything configured the way I like it. Everything absolutely rock steady atm. Just one question - should I install the snapshot update now or leave well enough alone?


If it's not broken, don't fix it.

1 Like

One of the drawbacks of using a snapshot release is that the kernel module repos are removed after a while so unless you have made an own copy it may be problematic to install new modules later unless you upgrade to a later snapshot.
I noticed on the 18.06 roadmap that the plan is to start preparations for an 18.06.3 release in March which I guess will include the EA6350v3.


As reminder for those lamenting the disappearance of pre-builds, recent commits to OpenWRT master have made it straigtforward to create customs images with a more "standard" set of packages: luci, sqm, adblocking, vpn, etc.

The two simplest options are:

  1. Use the latest imagebuilder snapshot and follow the OpenWRT wiki directions.
  2. Use the online image builder created by @aparcar. Simply select the "OpenWRT" distribution, "snapshots" version, "EA6350v3" device, and flavour "OpenWrt with web interface". Then click "Create Image" and wait for you links to be created. Here's a link to a standard luci-included image I created just today.

The EA6350v3 support in `master` is now great, with solid wifi and stability as far as I've seen. There are still a few minor issues to be addressed however.

I've noticed the switch and VLAN problems as well. The default network setup works, but it doesn't appear to match the internal switch configuration:

# swconfig dev switch0 show
        vid: 1
        ports: 0 1 2 3 4
        vid: 2
        ports: 0t 5

Although the current network setup puts "lan" as eth0 and "wan" as eth1, based on the switch both appear to be VLANs routed between a single CPU port 0, which traditionally would be a lan/wan of eth0.1/eth0.2 (but that causes problems).

Starting to fix things, I think CPU port 0 needs to be tagged on VLAN 1. After testing this, the VLAN page looks as expected:

However, the board setup code still needs updating to fix this during a "clean" install, or perhaps a custom /etc/board.json could be used. @gapf2010 What changes did you make? Does your luci page look similar to mine above?

1 Like
IPQ40xx Switch Config "Strangeness"

I see the same thing on the EA8300 -- might be a common IPQ40xx problem. I haven't played around with it much, but I want to check to see if eth1 is connected to the switch, or perhaps to a port directly. That the device I'm working on supports bonding in the OEM firmware might mean that it bypasses the switch fabric. Or not.

	vid: 1
	ports: 0 1 2 3 4 
	vid: 2
	ports: 0t 5 
config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 0'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '5 6'

From 02_network (at least in my envorinment)

                ucidef_set_interfaces_lan_wan "eth0" "eth1"
                ucidef_add_switch "switch0" \
                        "0u@eth0" "1:lan" "2:lan" "3:lan" "4:lan"
                ucidef_set_interfaces_lan_wan "eth0" "eth1"
                ucidef_add_switch "switch0" \
                        "0u@eth0" "1:lan" "2:lan" "3:lan" "4:lan" \
                        "6u@eth1" "5:wan"
Linksys EA8300

@jeff Yeah, I'm also trying to find online documentation on the system switch configuration, but without luck beyond the ipq4018 product brief and the qca8075 phy. From the PHY docs I could see there might be a direct WAN port connection (i.e. GEPHY4).

Something strange I noticed in your setup: swconfig seems to show a single CPU connection (port 0), while your board config is showing two. To clarify, could you post the output of the two commands:

swconfig dev switch0 help|head -5


swconfig dev switch0 show|tail -10

Maybe there's a detection problem which has be overridden? I'd be interested to also see your /etc/board.json too. Does you Luci switch configuration page look OK currently?

Any thoughts @chunkeey?


EA8300 WIP:

root@OpenWrt:~# swconfig dev switch0 help
switch0: 90000.mdio(QCA AR40xx), ports: 6 (cpu @ 0), vlans: 128
	Attribute 1 (int): enable_vlan (Enable VLAN mode)
	Attribute 2 (none): reset_mibs (Reset all MIB counters)
	Attribute 3 (int): enable_mirror_rx (Enable mirroring of RX packets)
	Attribute 4 (int): enable_mirror_tx (Enable mirroring of TX packets)
	Attribute 5 (int): mirror_monitor_port (Mirror monitor port)
	Attribute 6 (int): mirror_source_port (Mirror source port)
	Attribute 7 (int): linkdown (Link down all the PHYs)
	Attribute 8 (none): apply (Activate changes in the hardware)
	Attribute 9 (none): reset (Reset the switch)
	Attribute 1 (int): vid (VLAN ID (0-4094))
	Attribute 2 (ports): ports (VLAN port mapping)
	Attribute 1 (none): reset_mib (Reset single port MIB counters)
	Attribute 2 (string): mib (Get port's MIB counters)
	Attribute 3 (int): pvid (Primary VLAN ID)
	Attribute 4 (unknown): link (Get port link information)
Global attributes:
        enable_vlan: 1
        enable_mirror_rx: 0
        enable_mirror_tx: 0
        mirror_monitor_port: 0
        mirror_source_port: 0
        linkdown: ???
Port 0:
        pvid: 1
        link: port:0 link:up speed:1000baseT full-duplex txflow rxflow 
Port 1:
        pvid: 1
        link: port:1 link:up speed:1000baseT full-duplex txflow rxflow auto
Port 2:
Port 5:
        pvid: 2
        link: port:5 link:down
        vid: 1
        ports: 0 1 2 3 4 
        vid: 2
        ports: 0t 5 
root@OpenWrt:~# cat /etc/board.json 
	"model": {
		"id": "linksys,ea8300",
		"name": "Linksys EA8300 (Dallas)"
	"network": {
		"lan": {
			"ifname": "eth0",
			"protocol": "static"
		"wan": {
			"ifname": "eth1",
			"protocol": "dhcp"
	"switch": {
		"switch0": {
			"enable": true,
			"reset": true,
			"ports": [
					"num": 0,
					"device": "eth0",
					"need_tag": false,
					"want_untag": true
					"num": 1,
					"role": "lan"
					"num": 2,
					"role": "lan"
					"num": 3,
					"role": "lan"
					"num": 4,
					"role": "lan"
					"num": 6,
					"device": "eth1",
					"need_tag": false,
					"want_untag": true
					"num": 5,
					"role": "wan"
			"roles": [
					"role": "lan",
					"ports": "1 2 3 4 0",
					"device": "eth0"
					"role": "wan",
					"ports": "5 6",
					"device": "eth1"

If I move my only "live" Ethernet cable to the "Internet" port, I get

[43445.205962] ess_edma c080000.edma: eth1: GMAC Link is up with phy_speed=1000
[43445.206395] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

If I reboot in that configuration (cable live on "Internet" port only) and look at the counters, port:5 is up, and the traffic counters seems to be increasing on port:0. Not examined in great detail, such as checking the numbers (as I've only got serial connectivity).


Thanks for the additional details; this does match up with what I've been thinking too. I also see the ess_edma driver line for eth1, with a corresponding port link state change from swconfig. And given the QCA8075 block diagram, it does seem likely the WAN port is connected to both switch port 5 and eth1 on the CPU, but isolated from the LAN on the switch by vid 2.

The fact that on EA6350v3 the Luci VLAN config "hides" the WAN port connection on vid 2 is dangerous, since someone could enable tagging on CPU(eth0) and then try to place a former LAN port into a new VLAN with vid 2 (same as hidden WAN), causing all sorts of problems.

I think the "fake" port 6 I see on your EA8300 as "CPU(eth1)" is a kludge made for safety's sake, as a placeholder for VLAN/vid 2 to help avoid the problem I described above.

Honestly, I would like to see this also for EA6350v3, but would first still like more insight into the internal "wiring" of switch/ethernet ports on the SoC. However, I did test it on my EA6350v3 just fine.


No “kluge”, just how I would have configured the switch for a typical dual-Ethernet board. That’s the only reason it’s configured that way at the moment.


Hi, currently I have not done any changes to the router config. i tried to add the WAN port to the Luci interface by modifying the /etc/board.json file, but I messed it completely, so I had to restore the original one. I just tagged the CPU port as you suggested, but my Luci still does not display the WAN port, how did you manage to display it? does it survive a reboot? Thanks!

Edit: Here's the "ip add" command on my router. Notice that eth0 has a differente MAC address from eth1, that leads me to believe they are in fact different interfaces:

root@wl:~# ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 60:38:e0:70:9b:78 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 1000
    link/ether 60:38:e0:70:9b:77 brd ff:ff:ff:ff:ff:ff
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 60:38:e0:70:9b:78 brd ff:ff:ff:ff:ff:ff
    inet brd scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fe80::6238:e0ff:fe70:9b78/64 scope link 
       valid_lft forever preferred_lft forever
7: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 60:38:e0:70:9b:79 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6238:e0ff:fe70:9b79/64 scope link 
       valid_lft forever preferred_lft forever
8: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 60:38:e0:70:9b:7a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6238:e0ff:fe70:9b7a/64 scope link 
       valid_lft forever preferred_lft forever
10: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 60:38:e0:70:9b:78 brd ff:ff:ff:ff:ff:ff



I had to go back to the stock firmware on my Linksys because I noticed some strange problems:

  1. Many instagram images would not load when using wifi. No clue why, just displayed a gray square instead of the image, however when using a LAN cable, they would load OK.
  2. Some "status" images on WhatsApp would not load either. Same for some images on Twitter.
  3. Having no VLAN on the WAN side, I could not configure my Internet connection properly, had to use my router as an access point. It has worked that way since many months ago, however I wanted to use the PC I have as a firewall/router for other stuff, but it seems I can't. I would use the stock firmware for this, but the lack of internal DNS is a showstopper for me.

I went back to the stock firmware in bridge mode, and now everything works fine. To go back, I installed " luci-app-advanced-reboot" from this page:

Thanks for the huge effort though, I hope late I can install OpenWRT on my router and make it work as it should.

Trouble loading Instagram's images

Very interesting findings @gapf2010. My wife complained that Instagram was not working properly in the room where I have the EA6350. After all the benchmark tests I have run with different wifi calibration board images I assumed it was a problem on the Instagram end (I don't use that app much myself).
But after reading your post I started the app on my phone and could see that some images would not load, seems that updating from Instagram is not working well in general so I walked over to a different room where I have another access point and the images loaded right away!?!?
Really strange...


Fire up a laptop and debug http(s) calls... ( chrome developer view? )

Sounds like it might be some sort of fancy;

ipv4 > 6 hopping
https > http
embedded redirect

Some sort of hopping anyways....

1 Like

View > Developer > Developer Tools

Network tab, reload the page


So I am not imagining things, it does fail to work with those sites. Very strange indeed, hopefully some developer can fix this, because the official firmware even if very stable, (at least for me) does not have some features that I need from OpenWRT (or any Linux router) like OpenVPN, DNS for my network (dnsmasq), dynamic DNS registration, etc.


I tried the debugging stuff from Chrome and found out that everything is loaded ok except for the actual images which are referenced using URLs like:
The host in the URL has both an IPv4 and an IPv6 address.
The IPv4 address resolves to a hostname which belongs to my ISP so there is some advanced caching going on.
When connected through Wifi no reply is received for the IPv4 https request so it tries IPv6 instead (which does not work either since I don't have IPv6) so eventually it times out.
When connect through LAN a reply is received for the IPv4 request right away and the image is downloaded properly.
As I said before, really strange. The LAN and Wifi is connect to the same bridge and should have the same routing and firewall rules or am I missing something obvious here?

1 Like

Well, it seems your not the only one :wink:

I was scratching my head for a bit..... the fact it seemed fairly isolated to one type of hardware.......

But you mentioning dns.... certainly narrowed it down.... instead of really trying i cheated....

90% of the fixes say change to google dns..... now..... akamai....... cache wizardy...... yeah......

again.... its pretty isolated......

then I hit this post...... makes alot of sense....

So the next question is what is specific to your device that alters it in this area.... and how do we alter it better :wink: .... Having said that.... i am in no doubt that the current state of play when it comes to "authoritative" resolution is a twisted game indeed.

1 Like

Thanks @wulfy23!
I immediately tried to disable QOS, just to realize that I had not even installed QOS on my router :slight_smile:
But after installing the qos packages and rebooting the router everything now works perfectly!
I did not config or enable anything. I just installed luci-app-qos which also installs a bunch of kernel modules and other dependencies and left it at the default disabled setting and everything is now working great!

Edit: Ok I was to quick, what happened was that when I rebooted the router my laptop switched to an Wifi access point in a different room that's why it worked. So investigation ongoing...

1 Like

I run some additional tests on the "Instagram Issue" today.
When running from wireless I can see in /proc/net/nf_conntrack that the TCP session gets stuck in SYN_RECV. While from the working wired connection it's ESTABLISHED.
SYN_RECV should indicate that an SYN ACK has not been received from the remote server, but from a tcpdump captured on the router I can clearly see that an SYN ACK is received on the eth1 interface.
But for some reason it's not matched to the session and that's why it's not forwarded to the laptop.
I have compared the tcpdump in wireshark with a tcpdump from a working session established from a wired connection. I'm very far from a network expert but the SYN and SYN ACK packages sure look very similar to me. I could see a small difference regarding the ACK, for the wired session wireshark is displaying an [iRTT: 0.016209000 seconds] value in the SEQ/ACK analysis section which it does not show for wireless, but Wireshark does match the ACK to the correct segment/frame. Perhaps the Linux kernel just have higher standards :slight_smile:
I even setup IPv6 and sure enough a tcpdump showed that it started using it instead of IPv4, but with exactly the same behaviour, worked fine from wired and got stuck at wireless :frowning: