Since upgrading to firmware 386.3_2, my Internet will not stay connected for even a day.

[DTS]

That's why I wanted you to try a wired client, in case its wireless issue. Or something to do w/ these being phones. IOW, don't limit your testing to a couple of wireless smartphones. We need more data points.

OK, will test and reply.

 

[eibgrad]

Also dump the following.

ip route
ip rule

 

[eibgrad]

BTW, there's always the possibility that clients are having a problem w/ DNS, and that internet connectivity is otherwise still there. That's the problem w/ relying only on a browser to determine if you have internet access. You need to try pinging a public IP (e.g., ping 8.8.8.8) from those same failed wireless clients to see if indeed this is only a DNS problem. Esp. if you're using DoT and Strict; I've seen instances where DoT is not nearly as reliable as good ol' Do53.

 

[DTS]

That's why I wanted you to try a wired client, in case its wireless issue. Or something to do w/ these being phones. IOW, don't limit your testing to a couple of wireless smartphones. We need more data points.

A wired client can connect to the router and get a local IP address. It can ping the router. But it cannot ping 8.8.8.8, and the wired client cannot access the Internet thru a browser, via curl, etc.

 

[DTS]

Also dump the following.

ip route
ip rule

# ip route
default via 175.101.62.186 dev eth0
10.45.0.17 dev tun11 proto kernel scope link src 10.45.0.18
175.101.62.180/29 dev eth0 proto kernel scope link src 175.101.62.183
175.101.62.186 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
192.168.100.0/24 dev br0 proto kernel scope link src 192.168.100.1

# ip rule
0:      from all lookup local
10010:  from 192.168.20.0/24 lookup main
10210:  from 192.168.100.0/24 lookup ovpnc1
10211:  from 192.168.1.0/24 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

 

[DTS]

192.168.20.0/24 is the guest network and it is intended to be routed to the WAN interface and not the VPN tunnel.

192.168.100.0/24 are all other clients (wireless and wired) and this traffic should all go thru the VPN tunnel.

192.168.1.0/24 I believe that address range is limited to the router itself.

as we established before, this command succeeds:

traceroute -ni tun11 8.8.8.8

This one succeeds as well via the WAN interface:

traceroute 8.8.8.8

 

[DTS]

BTW, there's always the possibility that clients are having a problem w/ DNS, and that internet connectivity is otherwise still there. That's the problem w/ relying only on a browser to determine if you have internet access. You need to try pinging a public IP (e.g., ping 8.8.8.8) from those same failed wireless clients to see if indeed this is only a DNS problem. Esp. if you're using DoT and Strict; I've seen instances where DoT is not nearly as reliable as good ol' Do53.

ping 8.8.8.8 fails on all wireless and wired clients.
however, I'm not sure if that is a valid test because I have this setting set to "No":

Respond ICMP Echo (ping) Request from WAN: No

It has been set that way all along, which is why I have been testing with traceroute instead of ping on the router.

I can run this command in Termux on a wireless client:

tracepath 8.8.8.8

That fails at 30 hops after the first hop to the router.

I can also run this command in Termux on Android, but it doesn't connect:

telnet 8.8.8.8 53

However, on the router itself I get a response like this:

# telnet 8.8.8.8 53
Connection closed by foreign host

 

[Treadler]

BTW, there's always the possibility that clients are having a problem w/ DNS, and that internet connectivity is otherwise still there. That's the problem w/ relying only on a browser to determine if you have internet access. You need to try pinging a public IP (e.g., ping 8.8.8.8) from those same failed wireless clients to see if indeed this is only a DNS problem. Esp. if you're using DoT and Strict; I've seen instances where DoT is not nearly as reliable as good ol' Do53.

An interesting comment.
For the last month or so Adguard DNS via DoT has stopped working here.
Do53, all good.
DoT with any other compatible server works fine.

(Factory, or Merlin firmware, same issue).

 

[eibgrad]

ping 8.8.8.8 fails on all wireless and wired clients.
however, I'm not sure if that is a valid test because I have this setting set to "No":

Respond ICMP Echo (ping) Request from WAN: No

It has been set that way all along, which is why I have been testing with traceroute instead of ping on the router.

I can run this command in Termux on a wireless client:

tracepath 8.8.8.8

That fails at 30 hops after the first hop to the router.

I can also run this command in Termux on Android, but it doesn't connect:

telnet 8.8.8.8 53

However, on the router itself I get a response like this:

# telnet 8.8.8.8 53
Connection closed by foreign host

The "Respond ICMP Echo (ping) Request from WAN" setting is irrelevant. That simply determines if the WAN will respond to ping requests from the *internet* side. Most ppl set it to NO to remain stealthy. But it has no bearing on this current issue.

If you can't ping a public IP like 8.8.8.8, then it doesn't seem to be only a DNS issue.

I wanted to see the following output as well.

ip route
ip rule

 

[DTS]

I wanted to see the following output as well.

ip route
ip rule

That's pasted a couple posts above. Thanks

 

[DTS]

I was trying to wait it out and find a solution rather than restart my router. However, while reading thru various threads here I changed "Network Monitoring" from ping to DNS query and applied that change. I was not thinking that it would have an immediate impact on this issue. However, as soon as I applied the change, everything started working again. It's probably a good thing, otherwise I would be dealing with a house full of people complaining for the weekend.

I suspect that almost any setting change I made may have resolved the issue. I'm not convinced this specific setting has anything to do with the problem. I think it was the act of apply a setting change that got my router out of its partially malfunctioning state.

Does that give anyone any insight into what is going on?

 

[eibgrad]

I was trying to wait it out and find a solution rather than restart my router. However, while reading thru various threads here I changed "Network Monitoring" from ping to DNS query and applied that change. I was not thinking that it would have an immediate impact on this issue. However, as soon as I applied the change, everything started working again. It's probably a good thing, otherwise I would be dealing with a house full of people complaining for the weekend.

Network monitoring?? That's a function of Dual WAN. Do you have a dual wan configuration?!

 

[DTS]

Network monitoring?? That's a function of Dual WAN. Do you have a dual wan configuration?!

No, single WAN. I did not know the setting was only for dual WAN, but like I said, I don't think it was this setting itself that had anything to do with resolving the issue. I think it was the act of applying any setting that got my router out of the malfunctioning state. Does that make sense?

 

[eibgrad]

No, single WAN. I did not know the setting was only for dual WAN, but like I said, I don't think it was this setting itself that had anything to do with resolving the issue. I think it was the act of applying any setting that got my router out of the malfunctioning state. Does that make sense?

Ok, I just realized that setting is also under Administration->System->Basic Config. You'd think that would be on the WAN page, just as it is for Dual WAN. I don't use it, so it surprised me when you claimed to have made a change. I thought you were using the Dual WAN page.

 

[eibgrad]

I agree. You probably could have made other changes, any one of which would reinitialize the WAN. So *something* is messing up the WAN over time. But trying to determine what that is is difficult. Perhaps your router is having difficulty renewing its lease. Does it keep accurate time? A few years ago I had a router that couldn't keep accurate time, so much so it would fail to renew the DHCP lease before it expired! End result, the WAN would simply stop working once the ISP actually expired the lease.

 

[DTS]

Ok, I just realized that setting is also under Administration->System->Basic Config. You'd think that would be on the WAN page, just as it is for Dual WAN. I don't use it, so it surprised me when you claimed to have made a change. I thought you were using the Dual WAN page.

Yes, I saw it at Administration->System->Basic Config. I wasn't really thinking when I changed it, as my plan had been to leave my router in that broken state until we could figure out the issue. I had a momentary lapse of focus when I changed it.

But I was also not surprised at all by the result. I saw it a couple times previously. ANY settings change seems to get my router out of this state.

 

[eibgrad]

Have you considered the possibility its the modem? I had a similar problem about 6-7 years ago, and discovered it was a failing modem (or perhaps the power supply, not sure which). I had the cable company replace both and all was normal again. Many ppl just assume these modems will last forever. But heat eventually gets to them and make them less and less reliable. I know you said you tried a different ISP, but it wasn't clear if that necessarily meant a change in modem (for all I know, you have your own). It could also be line issues between the modem and router, modem and street, etc. The only way to eliminate those possibilities if some other router worked perfectly.

 

[DTS]

I agree. You probably could have made other changes, any one of which would reinitialize the WAN. So *something* is messing up the WAN over time. But trying to determine what that is is difficult. Perhaps your router is having difficulty renewing its lease. Does it keep accurate time? A few years ago I had a router that couldn't keep accurate time, so much so it would fail to renew the DHCP lease before it expired! End result, the WAN would simply stop working once the ISP actually expired the lease.

That's an interesting suggestion, but in the troubleshooting you helped me with earlier in this thread, we saw that both the WAN and the VPN tunnel were up.

 

[DTS]

Have you considered the possibility its the modem? I had a similar problem about 6-7 years ago, and discovered it was a failing modem (or perhaps the power supply, not sure which). I had the cable company replace both and all was normal again. Many ppl just assume these modems will last forever. But heat eventually gets to them and make them less and less reliable. I know you said you tried a different ISP, but it wasn't clear if that necessarily meant a change in modem (for all I know, you have your own). It could also be line issues between the modem and router, modem and street, etc. The only way to eliminate those possibilities if some other router worked perfectly.

I have tested with 2 different ISP's (Comcast & ATT) as well as with 2 different AC86U's. Same problem in all permutations, starting with firmware 386.3_2. I did not have this problem before updating the firmware.

EDIT. The different ISP's use different modems. One is fiber, one is coax to the street. Not much in common. Also, I have devices connected directly to both ISP's modems (Roku, etc.) and I can say that the problem is not related to the ISP.

This issue is strictly happening somewhere between the incoming interface (I guess br0) and the outgoing connection to the tunnel or WAN. The testing you helped me with isolates it to between those two points, but that area is like a black hole for my knowledge.

 

[DTS]

BTW, I also did a full factory reset after upgrading to 386.3_2