Cannot access one specific website - but only from Android/iPad (OK from Windows and Linux)

[#1]

Moderators Note

Post released from automated spam filter

[#2]

Apologies for double-posting: the first one failed with a false-positive spam message that also said it had timed out, so I wasn't sure whether I'd actualyl posted it before I went out, and assumed that perhaps I hadn't, so I tried again. When that failed I got a moderator to reverse the spam status - and *both* copies came back!

Here are the results of tcptraceroute and tcpping. Sorry, this is a very long post because of the repeated pings that are recorded.

There are two traceroutes for the Plusnet connection, one for the Vodafone connection (tether Mint to mobile phone which is using its Vodafone connection). The Vodafone one is a *lot* shorter (fewer hops) and completed a *lot* quicker.

There is a very long tcpping which I left running while I changed from Plusnet to Vodafone and back to Pusnet. It shows that PN is generally faster and more consistent, but with occasional dropouts followed by several slow pings before getting back to normal. Vodafone is generally slower and more variable, but with fewer really bad dropouts. Finally, with PN, I did a tcpping of www.bbc.co.uk for comparison with a site that can always be browsed by all devices on all connections - again there are periodic dropouts.


Throughout all this time when I was on PN, I was never able to get the goosebears pages to load.

Via Plusnet FTTC/VDSL

martin@martin-mint:~$ sudo tcptraceroute goosebears.co.uk
Selected device wlx000f00d56252, address 192.168.1.6, port 47483 for outgoing packets
Tracing the path to goosebears.co.uk (160.153.128.26) on TCP port 80 (http), 30 hops max
 1  192.168.1.254  8.641 ms  1.835 ms  4.260 ms
 2  * * *
 3  * * *
 4  136.hiper04.sheff.dial.plus.net.uk (195.166.143.136)  14.938 ms  14.683 ms  14.347 ms
 5  peer7-et-3-1-6.telehouse.ukcore.bt.net (109.159.252.234)  14.662 ms  14.100 ms  14.173 ms
 6  166-49-214-194.gia.bt.net (166.49.214.194)  14.730 ms  16.936 ms  14.055 ms
 7  80.157.200.225  14.824 ms  15.118 ms  14.539 ms
 8  pd9ef3a22.dip0.t-ipconnect.de (217.239.58.34)  20.660 ms  21.137 ms  21.107 ms
 9  80.156.160.34  36.054 ms  20.268 ms  20.057 ms
10  ae2.ams3-bbsa0106-01.bb.gdinf.net (188.121.32.5)  20.981 ms  21.132 ms  21.051 ms
11  188.121.32.115  20.661 ms  22.371 ms  20.462 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  ip-160-153-128-26.ip.secureserver.net (160.153.128.26) [open]  21.668 ms  22.466 ms  22.767 ms

martin@martin-mint:~$ sudo tcptraceroute goosebears.co.uk
Selected device wlx000f00d56252, address 192.168.1.6, port 59915 for outgoing packets
Tracing the path to goosebears.co.uk (160.153.128.26) on TCP port 80 (http), 30 hops max
 1  192.168.1.254  5.429 ms  4.413 ms  2.033 ms
 2  * * *
 3  * * *
 4  140.hiper04.sheff.dial.plus.net.uk (195.166.143.140)  14.390 ms  13.522 ms  16.021 ms
 5  peer7-et-0-1-7.telehouse.ukcore.bt.net (109.159.252.240)  13.299 ms  13.315 ms  12.917 ms
 6  166-49-214-194.gia.bt.net (166.49.214.194)  13.520 ms  13.923 ms  13.740 ms
 7  80.157.200.225  14.318 ms  20.926 ms  16.664 ms
 8  pd9ef3a22.dip0.t-ipconnect.de (217.239.58.34)  20.309 ms  19.944 ms  22.563 ms
 9  80.156.160.34  19.157 ms  20.660 ms  19.265 ms
10  ae2.ams3-bbsa0106-01.bb.gdinf.net (188.121.32.5)  19.932 ms  20.328 ms  19.865 ms
11  188.121.32.115  19.452 ms  19.158 ms  19.332 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  ip-160-153-128-26.ip.secureserver.net (160.153.128.26) [open]  19.962 ms  20.878 ms  20.400 ms



Via Vodafone mobile

martin@martin-mint:~$ sudo tcptraceroute goosebears.co.uk
Selected device wlx000f00d56252, address 192.168.43.246, port 54733 for outgoing packets
Tracing the path to goosebears.co.uk (160.153.128.26) on TCP port 80 (http), 30 hops max
 1  192.168.43.1  5.015 ms  3.322 ms  3.194 ms
 2  * * *
 3  192.168.213.21  41.028 ms  40.296 ms  38.189 ms
 4  192.168.213.22  41.124 ms  42.541 ms  35.594 ms
 5  10.203.137.165  37.548 ms  35.564 ms  37.526 ms
 6  ip-160-153-128-26.ip.secureserver.net (160.153.128.26) [open]  49.402 ms  46.186 ms  39.672 ms


tcpping trace is attached (too large to include in message!)

[#3]

@martinund As a comparison , I tried the tcptraceroute and tcpping from my Ubuntu desktop on my Plusnet 80/20  connection ( static IP in the 80.229.x.x range )

The traceroute is almost identical, except for a minor difference at hops 8 & 9

tcpping responses are around the 15-16ms but I got no timeouts ( ran to 300 pings )

[#4]

@MisterW Useful to know that you are getting almost the same routing. Odd that your tcpping doesn't have intermittent dropouts.

My connection is nominally 40/10 - the router reports Maximum data rate: 9334 / 38596 but the actual sync speed is around 22-32 (D) / 8.9-14 (U) - it seems to alternate between 32/9 and 22/10 every few weeks. Interestingly, despite the sync speeds that the router reports at a given time, the Ookla Speedest results seem the show that the higher the downstream data rate, the lower the upstream speed. Noise Margin is fairly constant at 5.5-6 upstream but varies between 8 for 32 Mb/s and 15 for 22 Mb/s as if it can't decide whether to go for a higher speed with a lower margin or a lower speed with plenty of margin.

But I'm not aware of "lumpy" performance - eg videos that normally play fine but occasionally have dropouts or large file downloads where the reported download speed fluctuates wildly, both of which might happen if ping times were occasionally much longer than normal.

Could that be a factor in what I'm seeing? Can't see how it could be responsible for periods of many minutes when there is no response from a given server when other internet usage on the same or another PC is fine. Or why it would affect only one site. It is looking as if there's there's a bizarre routing problem.

One other thing I tried. After a long period when Mint was never able to access the goosebears site, I tried flushing the PC's DNS cache. "sudo systemd-resolve --flush-caches" and this immediately allowed a new request for the page to work. There was still intermittent access: sometimes a page would load immediately, sometimes there was a delay of 30-60 seconds but it worked eventually, so any delay was less than Firefox's "give up and go home" timeout. I've got a LAN trace of several such consecutive attempts which I need to look at.

I'll try rebooting my router (again!) to flush its DNS cache. Although the router disconnects and reconnects its VDSL connection every few days at about 2 AM (is that normal?), I imagine it's not flushing the DNS cache. I think frebooting may have improved things for a few days last time I did it, but there have been so many times with Mint that it's worked/failed even with the same VDSL connection and the same boot of the router, that I'll never know whether rebooting produces a real lasting improvement or whether I've just hit a lucky-by-chance phase.

My general impression is that the problem is gradually happening more often. When I first began investigating, I could never get a Mint or Ubuntu PC to fail (same PC hardware, two different boot drives!).