Connection on WAN interface (GL-X750V2)

I am reaching out for assistance with an issue I’m encountering on my GL-X750V2.

Following a power outage, I’ve been experiencing problems with the WAN port’s functionality. Prior to the outage, when I connected the X750 to my main router via the WAN port, it established a connection immediately. However, now it seems to be perpetually trying to connect without success, even after waiting for an extended period.

I have attempted a full reset and also updated the device to the latest beta version 4.0, but to no avail.

Interestingly, the Luci interface indicates packet activity:

Despite this, I am still unable to access the internet, and the WAN port does not receive an IP address.

Currently, the only workaround I’ve found to restore functionality to the WAN port is to perform a complete restart of the GL-X750V2.

Is there a DHCP reservation on your main router?

@admon, thank you for your inquiry. I have conducted tests with two primary routers to observe the behavior in question. When I directly connect my laptop to the Ethernet ports on these routers, I am able to access the internet and successfully receive an IP address.

That’s not the answer to my question :sweat_smile:
Are there -any- settings on the main routers which could be a problem here?

If you’re asking whether the router is configured with static IP leases, then the answer is no.

1 Like

If you disable DHCP on your GL and set a static IP - does it work then?

Apparently it says that it has established a connection but there is not internet access:

Here is the info from the main router:

image

The IP subnet looks a bit odd to me. Is it correct that the main router is using 192.168.8.1?
If you ping from any device which is connected to the GL X750V2, does it work?

The “internet access check” of the router is not really reliable.

Indeed, the router’s address is accurate; however, I am unable to receive a ping to it from a device connected to the X750.

If you plug out, wait for 10-15 seconds, plug in the ethernet cable again - it still acts the same?

Should I keep the static address for this test or switch back to DHCP?

Keep static. If static does not work we know there is something way more wrong than it should be.

Still receiving the same message with the cable unplugged for longer than 60 seconds:

I do not know what the X750 thinks the interface is connected to :frowning:

Here is an output from luci:

I restarted the eht0 interface from the luci panel. Here is the corresponding log:

Mon Nov 6 10:36:40 2023 daemon.notice netifd: Interface ‘wan’ is now down
Mon Nov 6 10:36:40 2023 daemon.warn dnsmasq[1]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Mon Nov 6 10:36:40 2023 kern.info kernel: [ 5971.611039] eth0: link down
Mon Nov 6 10:36:40 2023 daemon.notice netifd: Interface ‘wan’ is disabled
Mon Nov 6 10:36:40 2023 daemon.notice netifd: Network device ‘eth0’ link is down
Mon Nov 6 10:36:40 2023 daemon.notice netifd: Interface ‘wan’ has link connectivity loss
Mon Nov 6 10:36:40 2023 daemon.notice netifd: Interface ‘wan’ is enabled
Mon Nov 6 10:36:40 2023 daemon.notice netifd: Interface ‘wan’ is setting up now
Mon Nov 6 10:36:40 2023 daemon.notice netifd: Interface ‘wan’ is now up
Mon Nov 6 10:36:40 2023 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Mon Nov 6 10:36:40 2023 daemon.info dnsmasq[1]: using nameserver 202.69.205.1#53
Mon Nov 6 10:36:40 2023 daemon.info dnsmasq[1]: using only locally-known addresses for test
Mon Nov 6 10:36:40 2023 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Mon Nov 6 10:36:40 2023 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Mon Nov 6 10:36:40 2023 daemon.info dnsmasq[1]: using only locally-known addresses for local
Mon Nov 6 10:36:40 2023 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Mon Nov 6 10:36:40 2023 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Mon Nov 6 10:36:40 2023 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Mon Nov 6 10:36:42 2023 kern.info kernel: [ 5973.796177] eth0: link up (100Mbps/Full duplex)
Mon Nov 6 10:36:42 2023 kern.info kernel: [ 5973.800973] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Mon Nov 6 10:36:42 2023 daemon.notice netifd: Network device ‘eth0’ link is up
Mon Nov 6 10:36:42 2023 daemon.notice netifd: Interface ‘wan’ has link connectivity
Mon Nov 6 10:36:46 2023 user.notice mwan3[6377]: Execute ifdown event on interface wan (unknown)
Mon Nov 6 10:36:46 2023 user.info mwan3track[25372]: Detect ifdown event on interface wan (eth0)
Mon Nov 6 10:36:47 2023 user.notice mwan3track[25372]: Interface wan (eth0) is offline
Mon Nov 6 10:36:59 2023 user.notice firewall: Reloading firewall due to ifdown of wan ()
Mon Nov 6 10:37:07 2023 user.notice route_policy: default_policy=1 mac_list=
Mon Nov 6 10:37:12 2023 user.notice mwan3[7683]: Execute ifup event on interface wan (eth0)
Mon Nov 6 10:37:15 2023 user.notice mwan3[7683]: Starting tracker on interface wan (eth0)
Mon Nov 6 10:37:22 2023 user.info mwan3rtmon[5003]: Detect rtchange event.
Mon Nov 6 10:37:24 2023 user.notice firewall: Reloading firewall due to ifup of wan (eth0)
Mon Nov 6 10:37:28 2023 user.notice route_policy: default_policy=1 mac_list=
Mon Nov 6 10:38:00 2023 user.notice mwan3[9461]: Execute ifdown event on interface wan (eth0)
Mon Nov 6 10:38:06 2023 user.notice firewall: Reloading firewall due to ifdown of wan (eth0)
Mon Nov 6 10:38:14 2023 user.notice route_policy: default_policy=1 mac_list=
Mon Nov 6 10:38:14 2023 user.info mwan3track[8083]: Detect ifdown event on interface wan (eth0)
Mon Nov 6 10:38:19 2023 user.notice mwan3track[8083]: Interface wan (eth0) is offline

It seems that the eth0 port is always up wether a cable is connected or not:

Can we do a remote check?

Hello Cathy, thank you for your reply. If it helps to solve the problem then sure :slight_smile:

Hi, there seems to be a time difference between us. Please share your router with us through Goodcloud. The tech support account is “gl.inet_support”. Or you could send email to support@glinet.biz.