Mysterious loss of connectivity

[marcox]

Yes, but that doesn't mean it plays no role. All bridge mode is essentially is a router configured with DMZ set to your Asus' IP. It still there shuttling packets back and forth. If you can't reach the modem, the problem is with the Asus. If you can reach the modem the problem is with the modem.

I think it is a modem problem and the router cannot fix this. I use the modem inside my 4G-AC86U and have same problems. And the modem inside is a quectel LTE-A EM12-G. The quectel forum is full with problems and this modem So perhaps some LTE modems have problems with some ISP!

 

[Lynx]

I suspect it's a timing issue between the modem and the Asus. Not knowing the particulars of your modem makes it difficult to do anything but guess. Yours may be an LTE passthrough modem, but usually that means you cannot reach the modem in any way through the router, even when everything's working correctly. In that case, to connect to the modem's management interface would require a connection separate from the router.

Sorry I forgot that the modem does add itself as a hop when VPN is not used:
VPN OFF:

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms RT-AX86U-4168 [192.168.1.1]
2 2 ms 1 ms 1 ms 192.168.8.1
3 * * * Request timed out.
4 48 ms 51 ms 45 ms 192.168.213.21
5 43 ms 47 ms 47 ms 192.168.213.22
6 * * * Request timed out.
7 * * * Request timed out.
8 53 ms 47 ms 47 ms 63.130.104.194
9 51 ms 38 ms 47 ms 90.255.251.2
10 47 ms 47 ms 48 ms 216.239.41.149
11 47 ms 47 ms 47 ms 172.253.66.87
12 50 ms 47 ms 47 ms dns.google [8.8.8.8]

VPN ON:

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms RT-AX86U-4168 [192.168.1.1]
2 52 ms 47 ms 47 ms 10.8.0.1
3 50 ms 44 ms 45 ms 5.226.136.129
4 57 ms 48 ms 47 ms ae2.rt0-thn2.ldn.as25369.net [5.226.136.9]
5 48 ms 53 ms 48 ms google1.lonap.net [5.57.80.136]
6 48 ms 55 ms 58 ms 108.170.246.129
7 51 ms 47 ms 45 ms 142.251.54.29
8 * * 46 ms 63.130.104.194
9 * 48 ms 47 ms dns.google [8.8.8.8]

I posted about this here:

https://confusedbird.com/thread-113.html

Could it be that Huawei B818-263 adds itself as a hop to allow GUI access to itself in bridge mode? Because I can always access it on 192.168.8.1 over WAN (so long as I bypass VPN).

 

[marcox]

Sorry I forgot that the modem does add itself as a hop when VPN is not used:
VPN OFF:

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms RT-AX86U-4168 [192.168.1.1]
2 2 ms 1 ms 1 ms 192.168.8.1
3 * * * Request timed out.
4 48 ms 51 ms 45 ms 192.168.213.21
5 43 ms 47 ms 47 ms 192.168.213.22
6 * * * Request timed out.
7 * * * Request timed out.
8 53 ms 47 ms 47 ms 63.130.104.194
9 51 ms 38 ms 47 ms 90.255.251.2
10 47 ms 47 ms 48 ms 216.239.41.149
11 47 ms 47 ms 47 ms 172.253.66.87
12 50 ms 47 ms 47 ms dns.google [8.8.8.8]

VPN ON:

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms RT-AX86U-4168 [192.168.1.1]
2 52 ms 47 ms 47 ms 10.8.0.1
3 50 ms 44 ms 45 ms 5.226.136.129
4 57 ms 48 ms 47 ms ae2.rt0-thn2.ldn.as25369.net [5.226.136.9]
5 48 ms 53 ms 48 ms google1.lonap.net [5.57.80.136]
6 48 ms 55 ms 58 ms 108.170.246.129
7 51 ms 47 ms 45 ms 142.251.54.29
8 * * 46 ms 63.130.104.194
9 * 48 ms 47 ms dns.google [8.8.8.8]

I posted about this here:

https://confusedbird.com/thread-113.html

Could it be that Huawei B818-263 adds itself as a hop to allow GUI access to itself in bridge mode? Because I can always access it on 192.168.8.1 over WAN (so long as I bypass VPN).

Only for my interests.... work the huawei correct and the huawei reconnect and only the asus does not check this?

 

[sbsnb]

Could it be that Huawei B818-263 adds itself as a hop to allow GUI access to itself in bridge mode? Because I can always access it on 192.168.8.1 over WAN (so long as I bypass VPN).

Bridge mode doesn't mean it's not a hop, it just means it doesn't do NAT. It's sort of like DMZ. The packets still have to go through the modem. For the modem to function on the network it has to be routable somehow. There are different tricks to make it appear as though it's not there, but it's always there.

 

[marcox]

Only for my interests.... work the huawei correct and the huawei reconnect and only the asus does not check this?

Add: My Huawei B618 has this problem, too - till i update to the actual firmware, than he never lost the connection. NOW with my inside modem in ASUS ROUTER i have this problem again :-(

 

[Lynx]

sbsnb is there anything I should try to try to get a better understanding of the problem? I have created as comprehensive logs around the issue as I can in the posts above. It is not very intellectually satisfying to just set 'networking monitoring' enabled (and rely on the convoluted wanduck detection routines) or have the router automatically reboot every 12 hours to resolve the issue.

 

[sbsnb]

You have to wait until it happens. If you are able to leave it in that state and communicate with us here while it's that way we can probably figure it out pretty quickly.

 

[Lynx]

Ah cool, OK. Only problem is I agreed to let my wife set my router password to stop me tinkering instead of working. And now 'network monitoring' has been set, which I presume will auto-correct the issue. I will work on earning back the router password, then hopefully we can identify the cause.

Edit: actually would you be able to give me a few commands/tests to try running if it does happen and I have access?

 

[sbsnb]

The first thing is seeing if you can reach the modem while the internet isn't working. I'd also check the routing table for any peculiarities. I'd see if it happens without the VPN running. If it's every 48 hours on the money it should be easy to shut down the VPN a few minutes before reset. That's about all I can think of for now.

 

[Lynx]

Thanks a lot for your suggestions. I find it hard to decipher routing tables. What does this one roughly amount to?

default	10.0.0.1	0.0.0.0	UG	0	0	0	WAN
10.0.0.0	*	255.0.0.0	U	0	0	0	WAN
10.0.0.1	*	255.255.255.255	UH	0	0	0	WAN
10.8.2.0	*	255.255.255.0	U	0	0	0	tun11
192.168.1.0	*	255.255.255.0	U	0	0	0	LAN
239.0.0.0	*	255.0.0.0	U	0	0	0	LAN

 

[sbsnb]

It says, roughly:

1. Packets destined for any address should be sent over the WAN interface
2. Packets destined for any address 10.0.0.0 to 10.255.255.255 should be sent over the WAN interface
3. Packets destined for the specific IP address 10.0.0.1 should be sent over the WAN interface
4. Packets destined for any address 10.8.2.0 to 10.8.2.255 should be sent over the VPN
5. Packets destined for any address between 192.168.1.0 and 192.168.1.255 should be sent over the LAN interface
6. Packets destined for any address between 239.0.0.0 and 239.255.255.255 should be sent over the LAN interface

The order doesn't matter for priority since they all have the same metric. Priority goes to the most specific route. For example, a packet addressed to 10.8.2.12 matches route #1, #2, and #4, but #4 is the most specific so that's where it goes.

 

[Lynx]

Thanks a lot - that is really helpful.
Finally any guess what these 48 hour disconnect/reconnects reported by my LTE modem are about?

2021-07-26 17:47:20SystemNotice WAN connection INTERNET_R_UMTS1:IPv4 disconnected
2021-07-26 17:47:21SystemNotice WAN connection INTERNET_R_UMTS1:IPv4 connected
2021-07-28 17:47:20SystemNotice WAN connection INTERNET_R_UMTS1:IPv4 disconnected
2021-07-28 17:47:22SystemNotice WAN connection INTERNET_R_UMTS1:IPv4 connected

 

[sbsnb]

Thanks a lot - that is really helpful.
Finally any guess what these 48 hour disconnect/reconnects reported by my LTE modem are about?

That's the reset. If that's the cause of the problem you will see your Asus' logs showing the problem at the same time.

 

[Lynx]

Hmm. So is that my ISP (Vodafone) kicking my modem's MAC address off the network because it has been connected for 48 hours? I am trying to square this with WAN IP provided to my ASUS router (24 hour leases), and am having difficulty making sense out of these two things.

 

[sbsnb]

I don't think it would be very feasible for the ISP to monitor connection time to the second and force millions of clients to reset at precisely 48 hours. I would suspect that it's in the modem's firmware to reset itself after 48 hours, but it's hard to tell what's really happening.

 

[Lynx]

Ok thanks. Is it plausible though that Vodafone only allow a 48 hour connection and that the WAN IP allocated to the ASUS router (not in sync) is then set to expired. Thus my Asus router, not aware of the refresh, expecting that it can just go on using the connection, goes on trying to use the expired WAN IP? When this happens I see a WAN IP and active lease reported on my Asus router, yet I have loss of connectivity. So this is my best explanation about what is going on. If this is what is going on, is there actually any way for my Asus router to know that it has to update WAN IP based on this reset? If not, then relying upon the wanduck network down detection routine would seem entirely appropriate.

I wonder if this is affecting marcox too. Namely with LTE you get a) WAN IP lease, but there is also b) an out of sync with the WAN IP lease, but periodic disconnect / reconnect, where the ISP expects renewal but Asus router doesn't understand this.

 

[sbsnb]

Ok thanks. Is it plausible though that Vodafone only allow a 48 hour connection and that the WAN IP allocated to the ASUS router (not in sync) is then set to expired.

I don't think there's a mechanism for a DHCP server to change the lease time on a client. Once the client is assigned a lease, the client manages the expiration.

 

[Lynx]

I don't think there's a mechanism for a DHCP server to change the lease time on a client. Once the client is assigned a lease, the client manages the expiration.

I just tried disconnecting and reconnecting my mobile to the network and admittedly the IP stays the same.
I am just struggling to work out why the 48 hour connection refresh results in loss of connectivity.

 

[sbsnb]

There are several hypothetical scenarios where that could happen, but what is truly the cause is impossible to determine without troubleshooting while it's happening.

For example, they way the modem's bridge mode works could make it so that when the modem resets its connection it 'looses' sync with the router. I understand some bridge modes work by obtaining a DHCP address from the ISP and duplicating that IP address to the Asus. If that's how yours works it could be that the modem is getting a new IP from the ISP and for some reason is not giving that IP to the Asus. That would cause a mismatch.

 

[Lynx]

Thanks. That makes sense. If it's relevant at all, the only way I could get the bridge mode to work is by setting DHCP on on the Huawei router BEFORE setting bridge mode to on. So I am wondering if when my ASUS router gets its WAN IP, it is actually just getting this from my modem, not from the ISP. I did notice that when I had the Huawei router in normal mode, it had WAN IP = X, and when I set it to bridge mode, that same WAN IP = X got set as my WAN IP on my ASUS router. If I navigate to 'devices' in my Huawei router GUI in bridge mode, it shows my Asus router as having IPv4 address: ‏10.4.131.245 (which I think is the WAN IP of my ASUS).

Could it also relate to something to do with ISP handing out IP to first MAC address it sees (modem)?

So if modem not correctly signalling new IP to router, then there is no way out but to have router periodically check connectivity and restart WAN on loss thereof?