I live in north Devon and have exactly the same issue. Cuts off at midnight and comes back at 1am! Read the whole thread. Saying I have internet and WiFi is working fine but not a single device can connect to it. It’s very frustrating!
This is a difficult issue to pin down. All the usual line tests are clear and do not detect a fault. all the network levels look fine with all voltage and resistance levels across the circuit exactly where they should be with no fluctuations visible. There are no errors showing on the circuit, and checking the Openreach Yukon (DLM) logs at those times also shows no increase in errors.
Have you taken a look at the logs within the router at the times of the disconnection, do these show anything ?
Also, looking at your router remotely, I'm showing that memory and CPU utilisation are very high so I have a replacement Hub on the way just so we can take that out of the equation.
When the connection is lost do you have a wired device connected, and would you be able to run a ping and trace route and post the results of these.
Not sure if your questions are address to me ?
However, will respond as follows....
Yes, I have had performance logs reviewed and analysed during the "dropout" period and there appeared to be no problem with my signal even though all my devices became "un-connected".
I have no wired devices
I have been supplied with and tested a new replacement router (it made no difference)
Happy to run a ping and trace route if you advise how this should be done (I'm not very techie savvy I'm afraid !)
The fact that different people around the country are experiencing this issue suggests that the solution is not a "localised" one ?
My post was in answer to Trystrem, but if any customer affected could post a traceroute that would be helpful. I would advise to run a traceroute during the day when things are fine, then run one when the connection fails for comparison. Details of how to run can be found :
Ping has started…
PING www.google.com (18.104.22.168): 56 data bytes
64 bytes from 22.214.171.124: icmp_seq=0 ttl=252 time=6.886 ms
64 bytes from 126.96.36.199: icmp_seq=1 ttl=252 time=7.350 ms
64 bytes from 188.8.131.52: icmp_seq=2 ttl=252 time=6.980 ms
64 bytes from 184.108.40.206: icmp_seq=3 ttl=252 time=7.841 ms
64 bytes from 220.127.116.11: icmp_seq=4 ttl=252 time=6.772 ms
64 bytes from 18.104.22.168: icmp_seq=5 ttl=252 time=6.467 ms
64 bytes from 22.214.171.124: icmp_seq=6 ttl=252 time=6.808 ms
64 bytes from 126.96.36.199: icmp_seq=7 ttl=252 time=8.550 ms
64 bytes from 188.8.131.52: icmp_seq=8 ttl=252 time=6.365 ms
64 bytes from 184.108.40.206: icmp_seq=9 ttl=252 time=6.280 ms
--- www.google.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.280/7.030/8.550/0.673 ms
Traceroute has started…
traceroute: Warning: www.google.co.uk has multiple addresses; using 220.127.116.11
traceroute to www.google.co.uk (18.104.22.168), 64 hops max, 72 byte packets
1 ttrouter (192.168.1.1) 1.870 ms 1.721 ms 1.851 ms
2 * * *
3 22.214.171.124 (126.96.36.199) 6.716 ms 7.102 ms 6.028 ms
4 188.8.131.52 (184.108.40.206) 6.715 ms 7.185 ms 7.510 ms
This may be different than my issue taking a deeper look. This looks like a DNS issue to me. (Although I'm unsure how the superrouters report these connection issues, I don't use it).
The similarities are uncanny. I've reported my issue in a separate thread.
If it is the same thing : All line tests will return fine, internet works normally otherwise, engineer visits won't pick up anything.. Oh any my issue was first reported years ago.
Try setting your routers DNS servers to 220.127.116.11 and 18.104.22.168, reset it and try again. If you can't do that, try setting your laptop/PC to use the above DNS servers while this error is occurring.
Let me know how you get on. Although if it's the same as my issue, this won't work.
Thankfully the router I use can run tests while its disconnected to diagnose issues - the issue being reported from my end is DHCP issues on talktalks side (getting assigned a WAN IP address).
I believe the issue here is the IP lease time expiring on their end then failing to assign a new IP or refresh the lease.
@OCE_Michelle I'm assuming the wan DCHP lease time is set to 24 hours before its lease is refreshed?
Would explain the clockwork disconnections both here and for myself (and others).