I've just bought a second hand Linksys EA6350v3 and I saw there was support for OpenWrt.
I'm currently expanding my wireless coverage and I'm hoping to connect this wireless router to my VLAN trunk and then split the two LANs into two interfaces. I was looking over the Add support for Linksys EA6350 v3 thread and I was wondering the verdict was in regards to the VLAN support on this router? Ideally the trunk would come into the router via the WAN port. Could someone clarify on this please?
Another member mentioned they had problems loading Instagram and other websites using it as simple AP. Did this ever get fixed or did they find a solution?
I'm also hoping to use wpad-openssl to bridge my Linksys WRT1900ACS and EA6350v3. I don't really need anything fancy from the Linksys EA6350v3 other than receiving a VLAN trunk and routing the VLANs to their designated interfaces with an AP setup for each.
The EA6350v3 is fully supported. In fact, it's one of the most recommended devices since Escalion and I added support for it at the beginning of the year.
Still, it's facing the same VLAN issues as all of the IPQ401x regarding to VLAN in LuCI and the inability to use vlans 1 and 2, which are indeed forced by the driver.
In the sake of completeness, I added a couple of patches (not mine, patches from Christian Lampeter) which never reached upstream and by what other users of my build told me, it works fine using those patches.
The problem is that it requires a custom kernel and a custom network detection script, both such things can only be done by building an image itself.
I won't self publicity myself anymore as I have a hater which is really noisy. I would recommend to try the default OpenWrt first and then try the build to compare results.
Edit: to be clear, my sole purpose is to give OpenWrt users options to choose!
Just be aware that there now is a(n unsupported) v4 hardware revision around (next to the never going to be supported v1 and v2); the marking is often hidden on the paper box (but should be visible on the bottom side of the device itself).
I'm running an EA6350V3 with a current snapshot as an AP and it runs fairly well. The Archer C7 it replaced had somewhat better 2.4GHz performance, but the EA6350v3 excels at 5G. It's getting VLANs (wired) from the main router, and running home WiFi, Guest WiFi, home LAN and home IOT devices on their respective isolated VLANs.
Every once and a while (~weekly?) the LUCI interface inexplicably craps out, lately with:
/usr/lib/lua/luci/dispatcher.lua:251: /etc/config/luci seems to be corrupt, unable to find section 'main'
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:251: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:144: in function </usr/lib/lua/luci/dispatcher.lua:143>
but previously with a complaint about a missing main config file section that was not missing. A simple reboot takes care of it. Minor annoyance that I expect will resolve itself within a few more commits.
Yes.
Beware that the configuration needs to be done manually (LuCI does not work) and that a mistake will render the device unusable till it's restored to factory.
Not quite as scary as having to re-flash, as failsafe and restoring network defaults will get you back. However, your config should not touch VLANs 1 or 2 and, at least with the similar IPQ4019 in the EA8300, bridging the same VLAN across the “Internet” port and one or more of the “LAN” ports has “challenges”.
I trunk multiple VLANs on my EA8300s in my configurations.
Would you mind sharing your VLAN config (etc/config/network) please so I can see how you've setup the four LAN segments? If you don't mind sharing it don't forget to scrub any personal information.
The problem seems to be that a bridge over the two sets, "Internet" port and the "LAN" ports, doesn't ARP properly. While I haven't dug into it yet, I believe it is due to there being two MACs involved, one for the "Internet" port and one for the "LAN" ports. My guess is that the bridge master responds to the ARP, which ends up being "wrong" for the other set.
I noticed you used the WAN (internet port) as the trunk.
Essentially if I left the WAN port as tagged across two VLANs such as 5 and 10 tagged to the CPU (eth0) and then bridged the interfaces to these VLANs e.g. eth0.5 and eth0.10 that should work right?
My network configs follow. Nothing too fancy. I've not sorted out the VPN VLAN yet on the main router-the network file includes a work in progress Wireguard setup for now. MAC addresses and public keys have been replaced with blah.blah.blah.blah - probably unnecessary, and the exercise reminded me I should change the static IP's of my network to less uncommon, but still uncommon, addresses to thwart fingerprinting. So thanks for that.
My home set-up consists of a bridged modem feeding a main Edgerouter X that runs DNS and DHCP for all the VLANs. The Edgerouter ports have the home security system and two wired lines carrying the VLANs to AP's on the first and second floors of our house plugged into them. The Edgerouter X network file follows first for context, followed by the EA6350v3 network file:
Thanks for that. I will have a look over so that I can digest it and work it out in my head; I usually work with LuCI so looking at the VLAN section straight from a config file won't click straight away.
Of course you can; you always can. If you're just after including extra packages though, you might want to take a look at the image builder instead of the buildroot.
Well, Christian Lampeter, the guy who made the commit (I did the patch and fixed the detection script which he forgot to do) indeed had authority to upstream the patch by himself. However, he didn't do.
Mostly because it fixes most of the ipq4018 devices but breaks most of the ipq4019.
In such a case, we have to wait not for OpenWrt but for the Linux kernel. Thy must have to find a way to fix it in a future kernel.
Or, as I did, apply an ad-hoc patch for your particular target.