Add support for Linksys EA6350 v3

anon50098793 · February 27, 2019, 8:50pm

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

jeff · February 27, 2019, 8:56pm

View > Developer > Developer Tools

Network tab, reload the page

gapf2010 · February 27, 2019, 10:32pm

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.

anders · February 28, 2019, 8:32pm

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: https://instagram.fmmx1-1.fna.fbcdn.net/vp/1796e5f30c5f84.....
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?

anon50098793 · March 1, 2019, 4:44am

Well, it seems your not the only one

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

anders · March 1, 2019, 3:34pm

Thanks @anon50098793!
I immediately tried to disable QOS, just to realize that I had not even installed QOS on my router
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...

anders · March 3, 2019, 6:14pm

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

anon50098793 · March 4, 2019, 5:47am

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.

anders · March 4, 2019, 5:27pm

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.

anders · March 5, 2019, 7:17pm

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

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

gapf2010 · March 5, 2019, 8:16pm

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?

anders · March 5, 2019, 8:39pm

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.

guidosarducci · March 8, 2019, 5:19am

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.

gapf2010:

I had to go back to the stock firmware on my Linksys because I noticed some strange problems:
...
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.

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.

gapf2010 · March 9, 2019, 12:56pm

Hey, thanks for the suggestion, however I tried that before reverting to stock firmware and it did not work. Probably because the WAN f my Internet connection must has some special configuration for it to work:

It is PPPoE
It requires a separate VLAN
The WAN traffic MUST be tagged for the connection to work

Besides this, since there's the issue with instagram and possibly other web sites, I can not use OpenWRT until it is fixed.
Thanks again

escalion · March 10, 2019, 12:16pm

Hi @gapf2010, have you tried recreating this with IPv6 removed from the build configuration (so, IPv4 only) - may be worth isolating IPv6 as a potential cause.

gapf2010 · March 10, 2019, 3:24pm

Hi @escalion , I did not try rebuilding the image myself, because some of the build options are a little confusing to me, but with help I think I could do it. I did try disabling IPv6 the best I could in the configuration, and the issue persisted, though.

gapf2010 · March 14, 2019, 1:42pm

Hi, I found this suggestion to workaround the issue with instagram not loading images: Trouble loading Instagram's images Can anyone please test it and confirm if it works?

anders · March 14, 2019, 6:42pm

I have tried changing the DNS servers before and it did not help in my case.
I guess the mtr part was a suggestion on how to analyze the problem, not how to fix it.

gapf2010 · March 16, 2019, 3:08am

The problem with images on Instagram and other sites should be somewhere in the wireless bridging of the firmware, because I had the issue while using my EA6350v3 router as a simple access point in bridge mode. Another machine (a Linux server) was the DNS forwarder, firewall, DHCP server, NAT, connect to my ISP with PPPoE, etc. My Linksys was only working to bridge the wireless clients to the LAN network and even then the issue was present, however if I connected the client PCs to the Linksys using a cable, the images load fine.

jeff · March 16, 2019, 5:26pm

I'm trying to resolve an issue with the boot counter code that was apparently modified for this device, without breaking this device.

If someone has some time, I could use two diagnostics on the s_env partition, which I believe is mtd9.

mtdinfo /dev/mtd9 -u
hexdump -C /dev/mtd9ro

The first prints general information about the partition, and is not intended to modify it in any way

The second I expect will print the boot-count records from the partition. On a different device, the output looks like

00000000  11 08 11 20 01 00 00 00  12 08 11 20 ff ff ff ff  |... ....... ....|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000800  11 08 11 20 02 00 00 00  13 08 11 20 ff ff ff ff  |... ....... ....|
00000810  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00001000  11 08 11 20 00 00 00 00  11 08 11 20 ff ff ff ff  |... ....... ....|
00001010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*

[...]

00017000  11 08 11 20 01 00 00 00  12 08 11 20 ff ff ff ff  |... ....... ....|
00017010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00017800  11 08 11 20 00 00 00 00  11 08 11 20 ff ff ff ff  |... ....... ....|
00017810  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00040000

If it's crazy long, the first several records and the last couple should be fine.

Post or PM is OK, as this output likely doesn't have general interest to most readers of the thread.