cancel
Showing results for 
Search instead for 
Did you mean: 

Packet Loss - Finding the cause

FIXED
markos
Grafter
Posts: 64
Thanks: 6
Registered: ‎20-02-2013

Packet Loss - Finding the cause

Hi,

 

I've got PNHUB1 with:

 

Port 1 - Connected to a TPLink 8 port Switch (feeds audio/video stuff in lounge)

Port 2 - Connected to another TPLink 8 port Switch (feeds home office IT stuff inc an AP for wifi)

Port 3 - Connected to an AP in the kitchen for WiFi there

Has run very sweetly for a lengthy period of time.

Now... in the last few weeks we've suddenly hit periods of packet loss with regards to the internet. All areas, all at the same time. So TV in lounge loses connection to Netflix, kids iPads in the kitchen, my desktop in the office, etc. It doesn't always drop the connection, but nothing's happening. I say it's packet loss because when I do a PING to google.com (-n 30) I get in the region of 50 to 70% "packets lost" across the 30 pings (from a wired connection I might add). Because it's all areas I'm assuming (wrongly or rightly) it's my connection from PN.

When I get the packet loss it's suddenly BANG! No browsing possible. In the night it sometimes rights itself after 20 or so minutes (I've got an uptime monitor running), or when I wake up and go through the process of rebooting the hub. I'd estimate it happens once every 90-120 minutes and then I'm probably rebooting the hub 80% of those times.

So I raise a ticket, the PNHUB1 is already in the test socket. I'm currently waiting for the "someone will call you in 72 hours" (and we're at about hour 68!) so I thought I'd try and pin point the issue. 

I was convinced it was the PNHUB1 as when the PN tech support guy had me reset the unit back to factory settings with a pin I found the unit would freeze and reboot when navigating the menus. So I swapped it out with an old one which was previously suspected (incorrectly) of being at fault about 6 months ago for another issue. Seems that's not the case as I had another packet-loss episode 10 minutes later.

I'm now wondering if the network is being flooded somehow so I've literally only got my desktop PC connected via an ethernet cable into the hub1 and that's all. I've left WiFi running, but turned off (and disconnected) the AP's.

Time passes... and I wait to see if I hit another packet-loss episode.

In the meantime I wondered if anyone else had any suggestions what it may or may not be? It occurred to me I haven't changed the filter, but I'd have thought that was either working or not working rather than being intermittent?


81 REPLIES
VileReynard
All Star
Posts: 11,202
Thanks: 307
Fixes: 11
Registered: ‎01-09-2007

Re: Packet Loss - Finding the cause

Have you tried switching off the Hub1 for at least one hour, then switching it back on?

It will clear any mangled connections and should give you a different IP address.

markos
Grafter
Posts: 64
Thanks: 6
Registered: ‎20-02-2013

Re: Packet Loss - Finding the cause

Thanks for the suggestion. The replacement router has been turned off for 6 months, but it still has just done the same thing as the other one (I'm using a fixed IP btw).

So having just had another packet loss period (it didn't disconnect) I've replaced the filter on the line (which is plugged into the 'test' socket).

 

If it happens again then I'll turn off WiFi so there's really only this one (wired) device connected.

I'll keep you posted (for anyone in the future having this same issue).

 

bill888
Seasoned Pro
Posts: 901
Thanks: 132
Fixes: 24
Registered: ‎18-10-2008

Re: Packet Loss - Finding the cause

For next time you do witness packet loss issues, try pinging the Plusnet router, or other devices on your LAN.  If you see no packet loss, then the issue is clearly external.

fwiw, I did report this packet loss issue, but, it was only visible to Thinkbroadband's BQM.  I couldn't see any actual signs of packet loss whatsoever.

https://community.plus.net/t5/Fibre-Broadband/Packet-loss-using-Thinkbroadband-BQM-monitor-part-2/m-...

DLM kicked in last Saturday on my line, and I got a new IP address on same subnet when the router reconnected, and the mystery (fake) packet loss being reported by BQM disappeared.

markos
Grafter
Posts: 64
Thanks: 6
Registered: ‎20-02-2013

Re: Packet Loss - Finding the cause

Ah! Yes, I hadn't thought to ping the router.

Incidentally, if you're using Thinkbroadband's BQM are you using a something other than the PNHub1?

38 minutes "up" and counting...

markos
Grafter
Posts: 64
Thanks: 6
Registered: ‎20-02-2013

Re: Packet Loss - Finding the cause

Hmmm.... I spoke too soon. Packet loss and then it reconnected all by itself.

Managed to ping the router successfully, no losses.

Plusnet Staff
Plusnet Staff
Posts: 39
Thanks: 18
Registered: ‎20-12-2013

Re: Packet Loss - Finding the cause

Hi,

 

I am sorry to hear you are having issues with packet loss. Can you try something for me please.

 

On a single device within the property can you manually configure the DNS settings for the device.

On a windows device follow the link below for instructions.

 

https://www.windowscentral.com/how-change-your-pcs-dns-settings-windows-10

 

Please set the DNS to the following servers

Primary 212.159.13.49  & Secondary 212.159.13.50

 

What I am interested to see is on the device with the manual settings setup does the problem with packet loss stop but carry on with the other devices not setup in this way.

 

Thanks

 Peter Birt
 Plusnet Support Team
markos
Grafter
Posts: 64
Thanks: 6
Registered: ‎20-02-2013

Re: Packet Loss - Finding the cause

Thanks PeterBirt for responding.

I've made that change, however I think I can short-cut to an answer.

My desktop has been using Google's Public DNS for sometime (8.8.8.8 / 8.8.4.4) and yes, this desktop PC stops being able to browse/FTP, etc. at the same time as when the other devices become affected. I'll still monitor it though.

For the record, here's the results of a ping from earlier:

 

C:\Users\mark>ping google.com -n 30

Pinging google.com [216.58.206.142] with 32 bytes of data:
Request timed out.
Reply from 216.58.206.142: bytes=32 time=10ms TTL=55
Reply from 216.58.206.142: bytes=32 time=10ms TTL=55
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 216.58.206.142: bytes=32 time=10ms TTL=55
Request timed out.
Request timed out.
Reply from 216.58.206.142: bytes=32 time=10ms TTL=55
Request timed out.
Reply from 216.58.206.142: bytes=32 time=9ms TTL=55
Request timed out.
Request timed out.
Reply from 216.58.206.142: bytes=32 time=10ms TTL=55
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 216.58.206.142: bytes=32 time=10ms TTL=55
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 216.58.206.142:
    Packets: Sent = 30, Received = 7, Lost = 23 (76% loss),
Approximate round trip times in milli-seconds:
    Minimum = 9ms, Maximum = 10ms, Average = 9ms

 

steveocee
Grafter
Posts: 26
Thanks: 4
Fixes: 1
Registered: ‎30-05-2018

Re: Packet Loss - Finding the cause

Pings alone are useless for anything more than confirming you have packetloss. If you want to find out where the packetloss is then try doing a pathping.

e.g. pathping 8.8.8.8

It does a trace route and then runs through a full ping scan of each hop.

 

Significantly more useful than a ping test. Incidentally I have no idea why changing your DNS settings will help in figuring out packet loss, once the name resolution is completed it has nothing to do with ongoing packet transfer.

PC Gamer, MikroTik Nerd, Networking Dweeb
VileReynard
All Star
Posts: 11,202
Thanks: 307
Fixes: 11
Registered: ‎01-09-2007

Re: Packet Loss - Finding the cause

If I do a traceroute, it changes its routing each time

$ traceroute google.com
traceroute to google.com (216.58.198.110), 30 hops max, 60 byte packets
1 router (192.168.1.1) 1.414 ms 1.661 ms 1.645 ms
2 * * *
3 * * *
4 be3-3102.pcn-ir02.plus.net (195.166.143.132) 25.581 ms 25.853 ms 25.928 ms
5 195.99.125.140 (195.99.125.140) 26.058 ms 26.129 ms 195.99.125.144 (195.99.125.144) 26.257 ms
6 peer2-et3-0-1.slough.ukcore.bt.net (62.172.103.214) 36.452 ms peer8-et-3-1-6.telehouse.ukcore.bt.net (109.159.252.174) 35.171 ms peer2-et-7-0-1.slough.ukcore.bt.net (109.159.252.120) 35.222 ms
7 109.159.253.185 (109.159.253.185) 35.344 ms 195.99.126.135 (195.99.126.135) 11.401 ms 109.159.253.67 (109.159.253.67) 17.526 ms
8 * * *
9 74.125.253.230 (74.125.253.230) 21.531 ms 216.239.57.120 (216.239.57.120) 11.773 ms 64.233.175.153 (64.233.175.153) 11.574 ms
10 lhr25s07-in-f14.1e100.net (216.58.198.110) 11.740 ms 74.125.242.67 (74.125.242.67) 16.784 ms 64.233.175.153 (64.233.175.153) 16.623 ms

Repeating this gives a slightly different routing.

I blame BT.

But I think the cause lies locally.

It doesn't matter which DNS or DHCP is used - once the allocations have been handed out, they should be unchanging (for at least 24 hours).

Have you tried copying bulk data via the router from one PC to another PC and comparing checksums whilst watching TV to see if you can stress the router a little bit?

markos
Grafter
Posts: 64
Thanks: 6
Registered: ‎20-02-2013

Re: Packet Loss - Finding the cause

Thank you Steveocee - never seen pathping before? Impressed. Ran it whilst I was not having problems and I see this:-

C:\Users\mark>pathping google.com

Tracing route to google.com [216.58.212.110]
over a maximum of 30 hops:
  0  CICDEV03.lan [192.168.1.103]
  1  PNHUB1 [192.168.1.254]
  2  410.xe-2-2-0.central10.pcn-bng03.plus.net [84.93.253.80]
  3  411.be7.pcn-ir02.plus.net [84.93.253.87]
  4  195.99.125.144
  5  194.72.16.58
  6  195.99.126.135
  7     *        *        *
Computing statistics for 150 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           CICDEV03.lan [192.168.1.103]
                                0/ 100 =  0%   |
  1    3ms     0/ 100 =  0%     0/ 100 =  0%  PNHUB1 [192.168.1.254]
                                1/ 100 =  1%   |
  2  ---     100/ 100 =100%    99/ 100 = 99%  410.xe-2-2-0.central10.pcn-bng03.plus.net [84.93.253.80]
                                0/ 100 =  0%   |
  3    8ms     1/ 100 =  1%     0/ 100 =  0%  411.be7.pcn-ir02.plus.net [84.93.253.87]
                                0/ 100 =  0%   |
  4    8ms     1/ 100 =  1%     0/ 100 =  0%  195.99.125.144
                                0/ 100 =  0%   |
  5   10ms     1/ 100 =  1%     0/ 100 =  0%  194.72.16.58
                                2/ 100 =  2%   |
  6    9ms     3/ 100 =  3%     0/ 100 =  0%  195.99.126.135

Trace complete.

Hop #2 looks interesting, but I guess this is congestion (?) - when I really get problems I'll run it again.

markos
Grafter
Posts: 64
Thanks: 6
Registered: ‎20-02-2013

Re: Packet Loss - Finding the cause

VileReynard - I haven't tried stressing the router, no. The issue seems to show up when there's (seemingly) very little going (as well as busy times). But it's an idea.

markos
Grafter
Posts: 64
Thanks: 6
Registered: ‎20-02-2013

Re: Packet Loss - Finding the cause

And one from when it goes bad:

C:\Users\mark>pathping google.com

Tracing route to google.com [216.58.208.174]
over a maximum of 30 hops:
  0  CICDEV03.lan [192.168.1.103]
  1  PNHUB1 [192.168.1.254]
  2     *     410.xe-2-2-0.central10.pcn-bng03.plus.net [84.93.253.80]
  3  411.be7.pcn-ir02.plus.net [84.93.253.87]
  4     *     195.99.125.144
  5     *     62.172.103.232
  6  195.99.126.135
  7     *        *        *
Computing statistics for 150 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           CICDEV03.lan [192.168.1.103]
                                0/ 100 =  0%   |
  1    1ms     0/ 100 =  0%     0/ 100 =  0%  PNHUB1 [192.168.1.254]
                               44/ 100 = 44%   |
  2  ---     100/ 100 =100%    56/ 100 = 56%  410.xe-2-2-0.central10.pcn-bng03.plus.net [84.93.253.80]
                                0/ 100 =  0%   |
  3    8ms    56/ 100 = 56%    12/ 100 = 12%  411.be7.pcn-ir02.plus.net [84.93.253.87]
                                0/ 100 =  0%   |
  4    8ms    57/ 100 = 57%    13/ 100 = 13%  195.99.125.144
                                0/ 100 =  0%   |
  5   10ms    62/ 100 = 62%    18/ 100 = 18%  62.172.103.232
                                0/ 100 =  0%   |
  6    9ms    44/ 100 = 44%     0/ 100 =  0%  195.99.126.135

Trace complete.
markos
Grafter
Posts: 64
Thanks: 6
Registered: ‎20-02-2013

Re: Packet Loss - Finding the cause

Just an update... The Open Reach engineer came last week, and typically it remained up whilst he was here. He ran tests, couldn't see any issues anywhere. Suggests it might be the PN Hub, but says he will escalate it it as this can be monitored by BT...

 

Meanwhile the connection continues to freeze - normally when I need it not to!

 

I've updated my "question" on PN's support pages - not sure if it's better to do that or start a new one? Nobody's replied yet.

Plusnet Help Team
Plusnet Help Team
Posts: 10,121
Thanks: 3,200
Fixes: 508
Registered: ‎21-04-2017

Re: Packet Loss - Finding the cause

I'm sorry for the lack of response on your fault ticket, and that you're still experiencing connection problems following the engineer visit.

From what I can see the engineer sent the fault report back to us advising that no fault was found.

However based on what you've said I've ordered you a replacement router now. If this doesn't resolve the problem we'll need to arrange another engineer visit to further investigate this.

If this post resolved your issue please click the 'This fixed my problem' button
 Anoush Mortazavi
 Plusnet Help Team