Add support for Linksys EA6350 v3

@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.

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 @anon50098793!
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:

  • Any qos / adblock running?

  • can you try with the firewall off if the EA is not your edge router [ end test - firewall back on ]

  • If dns is running from dnsmasq in the router in direct of the wireless clients can you try pointing them at another dns server.... preferrably outside....

  • you'll have to change dnsmasq ( on the edge router ) if your inside core router is going to be used. It won't respond to non-local subnets... dont know the tickbox name from the top of my head.

It's not related to either QOS or AD-blocking. I did not have that installed to begin with, but I have now installed it and disabled both just for testing. The only out of the ordinary network config I have is that I'm running MWAN3 with LTE backup in case my fibre connection should be down. But since I'm not the only one with this issue it seems that it's more likely related to certain ISPs than the router config.

Using another DNS server does not help, I tried to resolve that hostname using the Google DNS servers and got exactly the same IPs back, so the DNS answer is based on the network the request is coming from.
I suppose that if I specify the IPv6 address of a DNS server it will work differently since my IPv6 network is not associated with my ISP, it's one of those free Tunnelbroker networks. But I'm only interested in finding the issue not work around it.

1 Like

I did a final test of the Instagram issue with the latest snapshot, complete reset of the config and just configured Wifi.
The router works ok when it is the second router but is just as broken as before when used as the first router (internet facing). Using the exact same router config :frowning:

Well, it's never too late to give up...


The main difference is that when the router is not internet-facing, then it is not doing any NAT, just bridging, correct? so the problem may lie somewhere on the routing part of the firmware?

No, I used exactly the same config in both tests so it used NAT both times.
In other words when it was not internet facing the traffic was NAT:ed twice.
So whatever is causing this is removed when the packages passes the other router.

1 Like

Pardon the delay, folks; catching up just took some time...

My point from above is that the switch doesn't appear to be dual-connected to the two CPU ethernet ports, so any such switch VLAN entry is non-physical and likely confusing to most users.

Only eth0 is switch-connected, while eth1 is connected to the WAN-port PHY (itself dual-connected to the switch). Isolation between LAN and WAN is then enforced by the switch's default VLAN-2 configuration.

Yes, I believe you're correct as per the above.

Since the WAN side has a dedicated ethernet port eth1, configuring VLANs on the switch isn't the right approach. You probably want to set up a driver-level VLAN which has long been supported on OpenWRT e.g. your IPTV is on VLAN-50 while your internet is on VLAN-10.

If this is your issue, it's as simple as navigating in Luci to Network > Interfaces > WAN > "Physical Settings" tab, and under "Interface" entering a Custom Interface of eth1.10.