Keep losing internet connection
TYCO
Posts: 5,891
Forum Member
✭
Can someone please decode this for me? Every 5 = 10 minutes my internet goes off for about a minute. I got this log from the router. The most recent item is me changing the time.
Info Jan 20 12:30:19 CONFIGURATION mbus igd sync successfull
Info Jan 20 12:30:16 CONFIGURATION mbus atomic sync successful
Info Jan 1 20:56:15 CONFIGURATION mbus igd sync successfull
Info Jan 1 20:56:12 CONFIGURATION mbus atomic sync successful
Warning Jan 1 20:52:32 SNTP Unable to contact server: 193.204.114.232
Warning Jan 1 20:51:47 SNTP Unable to contact server: 193.204.114.233
Warning Jan 1 20:46:02 SNTP Unable to contact server: 193.204.114.233
Warning Jan 1 20:45:12 SNTP Unable to contact server: 193.204.114.232
Info Jan 1 20:44:01 GRP Default destination is routed via gateway 10.245.168.1
Warning Jan 1 20:44:01 DHCC lease ip-address 10.245.171.86 bound to intf Internet
Warning Jan 1 20:44:01 DHCC IP address 10.245.171.86 (255.255.248.0) set on intf Internet: ok.
Info Jan 1 20:43:59 xDSL linestate up (ITU-T G.992.5; downstream: 16377 kbit/s, upstream: 914 kbit/s; output Power Down: 19.1 dBm, Up: 12.4 dBm; line Attenuation Down: 19.5 dB, Up: 11.0 dB; snr Margin Down: 9.1 dB, Up: 6.0 dB)
Info Jan 1 20:43:37 xDSL linestate down
Warning Jan 1 20:43:14 DHCC IP address 10.245.171.86 deleted: ok
Info Jan 1 20:43:14 GRP Default destination is not routed anymore via gateway 10.245.168.1
Info Jan 1 20:43:14 xDSL linestate down
Error Jan 1 20:41:35 FIREWALL replay check (1 of 6): Protocol: ICMP Src ip: 2.230.7.235 Dst ip: 10.245.171.86 Type: Destination Unreachable Code: Port Unreacheable
Error Jan 1 20:40:14 FIREWALL replay check (1 of 1): Protocol: ICMP Src ip: 2.230.7.235 Dst ip: 10.245.171.86 Type: Destination Unreachable Code: Port Unreacheable
Warning Jan 1 20:39:27 SNTP Unable to contact server: 193.204.114.232
Warning Jan 1 20:38:42 SNTP Unable to contact server: 193.204.114.233
Info Jan 1 20:36:45 GRP Default destination is routed via gateway 10.245.168.1
Warning Jan 1 20:36:45 DHCC lease ip-address 10.245.171.86 bound to intf Internet
Warning Jan 1 20:36:45 DHCC IP address 10.245.171.86 (255.255.248.0) set on intf Internet: ok.
Info Jan 1 20:36:44 xDSL linestate up (ITU-T G.992.5; downstream: 16377 kbit/s, upstream: 1022 kbit/s; output Power Down: 19.2 dBm, Up: 12.1 dBm; line Attenuation Down: 19.5 dB, Up: 11.0 dB; snr Margin Down: 9.3 dB, Up: 7.0 dB)
Info Jan 1 20:36:22 xDSL linestate down
Warning Jan 1 20:35:59 DHCC IP address 10.245.171.86 deleted: ok
Info Jan 1 20:35:59 GRP Default destination is not routed anymore via gateway 10.245.168.1
Info Jan 1 20:35:59 xDSL linestate down
Warning Jan 1 20:32:57 SNTP Unable to contact server: 193.204.114.233
Warning Jan 1 20:32:12 SNTP Unable to contact server: 193.204.114.232
Warning Jan 1 20:26:27 SNTP Unable to contact server: 193.204.114.232
Warning Jan 1 20:25:41 SNTP Unable to contact server: 193.204.114.233
Error Jan 1 20:25:35 FIREWALL replay check (1 of 4): Protocol: ICMP Src ip: 2.230.7.235 Dst ip: 10.245.171.86 Type: Destination Unreachable Code: Port Unreacheable
Error Jan 1 20:23:40 FIREWALL replay check (1 of 1): Protocol: ICMP Src ip: 2.230.7.235 Dst ip: 10.245.171.86 Type: Destination Unreachable Code: Port Unreacheable
Warning Jan 1 20:19:56 SNTP Unable to contact server: 193.204.114.233
Info Jan 20 12:30:19 CONFIGURATION mbus igd sync successfull
Info Jan 20 12:30:16 CONFIGURATION mbus atomic sync successful
Info Jan 1 20:56:15 CONFIGURATION mbus igd sync successfull
Info Jan 1 20:56:12 CONFIGURATION mbus atomic sync successful
Warning Jan 1 20:52:32 SNTP Unable to contact server: 193.204.114.232
Warning Jan 1 20:51:47 SNTP Unable to contact server: 193.204.114.233
Warning Jan 1 20:46:02 SNTP Unable to contact server: 193.204.114.233
Warning Jan 1 20:45:12 SNTP Unable to contact server: 193.204.114.232
Info Jan 1 20:44:01 GRP Default destination is routed via gateway 10.245.168.1
Warning Jan 1 20:44:01 DHCC lease ip-address 10.245.171.86 bound to intf Internet
Warning Jan 1 20:44:01 DHCC IP address 10.245.171.86 (255.255.248.0) set on intf Internet: ok.
Info Jan 1 20:43:59 xDSL linestate up (ITU-T G.992.5; downstream: 16377 kbit/s, upstream: 914 kbit/s; output Power Down: 19.1 dBm, Up: 12.4 dBm; line Attenuation Down: 19.5 dB, Up: 11.0 dB; snr Margin Down: 9.1 dB, Up: 6.0 dB)
Info Jan 1 20:43:37 xDSL linestate down
Warning Jan 1 20:43:14 DHCC IP address 10.245.171.86 deleted: ok
Info Jan 1 20:43:14 GRP Default destination is not routed anymore via gateway 10.245.168.1
Info Jan 1 20:43:14 xDSL linestate down
Error Jan 1 20:41:35 FIREWALL replay check (1 of 6): Protocol: ICMP Src ip: 2.230.7.235 Dst ip: 10.245.171.86 Type: Destination Unreachable Code: Port Unreacheable
Error Jan 1 20:40:14 FIREWALL replay check (1 of 1): Protocol: ICMP Src ip: 2.230.7.235 Dst ip: 10.245.171.86 Type: Destination Unreachable Code: Port Unreacheable
Warning Jan 1 20:39:27 SNTP Unable to contact server: 193.204.114.232
Warning Jan 1 20:38:42 SNTP Unable to contact server: 193.204.114.233
Info Jan 1 20:36:45 GRP Default destination is routed via gateway 10.245.168.1
Warning Jan 1 20:36:45 DHCC lease ip-address 10.245.171.86 bound to intf Internet
Warning Jan 1 20:36:45 DHCC IP address 10.245.171.86 (255.255.248.0) set on intf Internet: ok.
Info Jan 1 20:36:44 xDSL linestate up (ITU-T G.992.5; downstream: 16377 kbit/s, upstream: 1022 kbit/s; output Power Down: 19.2 dBm, Up: 12.1 dBm; line Attenuation Down: 19.5 dB, Up: 11.0 dB; snr Margin Down: 9.3 dB, Up: 7.0 dB)
Info Jan 1 20:36:22 xDSL linestate down
Warning Jan 1 20:35:59 DHCC IP address 10.245.171.86 deleted: ok
Info Jan 1 20:35:59 GRP Default destination is not routed anymore via gateway 10.245.168.1
Info Jan 1 20:35:59 xDSL linestate down
Warning Jan 1 20:32:57 SNTP Unable to contact server: 193.204.114.233
Warning Jan 1 20:32:12 SNTP Unable to contact server: 193.204.114.232
Warning Jan 1 20:26:27 SNTP Unable to contact server: 193.204.114.232
Warning Jan 1 20:25:41 SNTP Unable to contact server: 193.204.114.233
Error Jan 1 20:25:35 FIREWALL replay check (1 of 4): Protocol: ICMP Src ip: 2.230.7.235 Dst ip: 10.245.171.86 Type: Destination Unreachable Code: Port Unreacheable
Error Jan 1 20:23:40 FIREWALL replay check (1 of 1): Protocol: ICMP Src ip: 2.230.7.235 Dst ip: 10.245.171.86 Type: Destination Unreachable Code: Port Unreacheable
Warning Jan 1 20:19:56 SNTP Unable to contact server: 193.204.114.233
0
Comments
look like physical line faults on the connection to the exchange, perhaps loose connections or fauty cables.
The fact that it's using an address like 10.245.171.86 suggests an ISP using Carrier-Grade NAT, which is a hack small ISPs in some countries use to get around a shortage of IPv4 addresses. It suggests to me that your ISP may not be spending much money on equipment.
Yes, small hacky ISPs like BT. We already know that they refuse to spend money on equipment or trying to find any dormant IP space they might have hidden away
http://bt.custhelp.com/app/answers/detail/a_id/44044/~/ip-address-translation%2Fsharing
I just wish ISPs would get on and make IPv6 a reality rather than trying to stretch out the life of v4 with crap like this. BT has been involved in IPv6 for decades, they should be in a position to roll it out to their users by now.
This is something that even the large anti-innovation US ISPs are much better than us at doing. All of the major cable companies and at least one telco have been steadily getting things rolled out to their residential users
I'm sure they could, but it's not an easy thing to adjust to. We've had an IPv6 stack on most of our office systems since the mid-90's, people still don't like it and avoid it if they can. It's a pity the latest mobile networks, like 4G, didn't just go IPv6 only.
Sadly the folks who dreamed up IPv6 did so at a time when they assumed the whole network could be switched over easily, so they ignored backwards compatibility. That easy switchover isn't the case now. It's a little like trying swap to driving on the other side of the road, Sweden did it in the 60s, no-one would like to try it now!
I think you have an excessively rosy view of what it's like in the US. I work for a US company, and travel there regularly. My friends and colleagues complain about their ISPs as much as we do, and are astonished about how cheap internet access is in Europe. Some bits of the US are great, just like some bits of the UK, but overall I think the UK is better off, and is in the middle of the European scale.
That's possible, but it could also be that the router is contacting an NTP pool and that's the server it has chosen to use.
But that implies either v4 or v6, rather than both. Dual stack is a thing and by now the enterprise network gear that the ISPs are using should have most, if not almost all of the bugs shaken out. Home router support might be an issue, but considering BT specify and have control over the routers that they hand out, they should be able to get working v6 in the HH. Ditto TalkTalk/Sky/Virgin.
Some of the UK ISPs already have v6 on their core networks, it's just the "getting it to DSL customers" bit that they won't tackle.
Meanwhile, if I wanted a dedicated server or VPS, it's relatively easy to find a provider that will give me IPv6 access for it.
On mobile, some non-UK network operators are doing IPv6. T-Mobile US does it on 3G and LTE.
You may have misread what I said. I did say that US ISPs were normally anti-innovation, but on the sole issue of IPv6 adoption they are lightyears ahead of many others, including 99% of the UK ISPs (I think IDnet, Andrews and Arnold and Entanet are the only ones that will give it to you on ADSL/fibre). If you have a Comcast internet connection, for example, there's a very good chance that you're able to use IPv6 straight away. They've also worked with router and modem manufacturers to iron out any bugs, whereas UK ISPs seem to prefer horrific bodges like CGNAT and saying "it's too difficult".
Even high end ISPs like Zen are hiding behind the excuse that they don't need to do IPv6 because they have enough IPv4 addresses for now. It misses the point somewhat.
Ultimately v6 has to happen regardless of any issues it might have itself - trying to invent a new protocol isn't feasible at this point. I don't see things going well if it gets to the point where everyone is NATted and a real IP address is a paid-for luxury.
Where is network research done? Universities, computer companies, telcos and research establishments in Western Europe and the USA.
Who has all the Class As and Class Bs? Yep, that's right.
So the deployment and operational issues aren't getting flushed out, because no big, influential operator has a shortage of IPv4 that they can't "solve" with CGNAT. It's compounded by a lot of core equipment having hardware assist for IPv4 but putting the IPv6 through the slow path, a lot of DNS implementations on embedded systems not supporting AAAA properly and a rather disturbing and naive faith in a NAT boundary being as much security as anyone might need.
I've got IPv6 at home (a /48, in fact) and in the office (one of the few IPv6 endpoints at my university), and I have IPv6-only and dualstack stuff in my private estate. But it's hard to see, in the west, where the compelling case is. Sadly.
At your end you could double-check the cables and connectors between your router and phone socket, in case there's a bad connection there. If that doesn't help then the next step would be to contact the company.