topic Re: Cannot access one specific website - but only from Android/iPad (OK from Windows and Linux) in Broadband

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

martinund — Mon, 27 Sep 2021 19:53:53 GMT

I am having intermittent problems accessing site http://goosebears.co.uk/weather/. The symptom is a timeout trying to retrieve the page.

This only affects Android phones and iPads connected by wifi to my Plusnet FTTC/VDSL connection; it works 100% of the time from Windows and Linux PCs connected to the same Plusnet connection, either by wifi or Ethernet.

If the Android/iPad devices are connected instead to my Vodafone mobile internet connection (instead of Plusnet VDSL), there is no problem, which tends to suggest that it's something with the Plusnet connection.

It happens intermittently: I was getting it almost all the time last week, then it worked almost all the time until today when it has stopped working again.

I have tried rebooting the router and the phones/tablets. I've confirmed that nslookup on Windows and the equivalent operation in NetAnalyzer (techet.net) on Android always resolves the correct IP address. Unfortunately the website is not configured to allow browsing by its IP address instead of domain name goosebears.co.uk (in the browser's URL field) - even from a working Windows PC - otherwise I'd try that to remove DNS domain-to-IP mapping from the equation. I've tried with the router configured either to use Plusnet's DNS servers or Google's 8.8.8.8 DNS server (rebooting after changing it). I've tried with both the Plusnet Hub One and with a TPLink 8890 router. I've tried using Dolphin and Firefox browsers on Android, and Safari and Chrome on iPad.

Normally I'd use Wireshark to see what traffic is being sent from PC to server and from server to PC, but I can't get Wireshark connected by wifi to see any traffic (for any web site access, not specifically the one that fails) so the switch in the router is filtering out that traffic. I haven't found an equivalent of Wireshark for an Android device which a) works and b) doesn't require the phone to be rooted; otherwise I'd do the standard thing with LAN traces to get around switch traffic-filtering: run the trace on the same device as the one which experiences the problem.

One "funny" that I've seen on the Wireshark trace of a Windows access to the page is that the HTTP GET response returns the data compressed with ZIP, rather than in plain text that shows up in Wireshark.

I'm puzzled as to what could be causing the fault to happen intermittently (repeated times it works, then repeated times it fails). It's something that has only just started happening, maybe two weeks ago. It's worked fine for about 2 years on my present Plusnet connection, and about 5 years before that on the Plusnet connection at our previous house).

Any suggestions?

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

Gandalf — Tue, 28 Sep 2021 09:24:37 GMT

Hi @martinund

Hmm, really odd issue. The first thing I'd try is separating the dual band wireless frequency (2.4GHz and 5GHz) apart into separate network names as some devices tend not to like it when they're merged together.

1. Go to the router's homepage at http://192.168.1.254
2. Click on the Advanced Settings tab
3. Type in the admin password found from the back of the router and click the OK button
4. Click on the Continue to Advanced Settings button then the Wireless tab
5. Click on the 5GHz Wireless tab
6. Select No next to Sync with 2.4GHz
7. Change the name of the Wireless SSID to something different
8. Click the Apply button and wait for the change to be applied

I'd then try browsing to that website again on your Android phone or iPad. Let us know how it goes.

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

martinund — Tue, 28 Sep 2021 12:25:22 GMT

There is an added factor which I didn't mention initially because I didn't want to complicate the issue. I don't *think* it's a factor, because of tests I've already done, but I'll mention it anyway.

Because of the size of our house, we use a Linksys Velop mesh network (primary Velop node connected to Plusnet router by Ethernet) with wifi and DHCP turned off on Plusnet router, and NAT on both Velop and Plusnet, and DHCP on Velop. It has worked perfectly, even for this site, for two year until now.

I did wonder whether it might be a factor when I first experienced the problem, so I turned on wifi on the Plusnet router (2.4 GHz only) and connected my phone to that rather than the mesh network. This was at a time when the site was consistently failing, and it still failed when I used the PN's 2.4 GHz wifi rather than the Velop's mixed 2.4 and 5 (with 5 being used preferentially) with an extra layer of NAT.

So I've already tried what you suggested, but to no avail.

Weird that it only affects (all) browsers on Android and iPad, and that I've not had any problems using Firefox or Chrome on Windows or Linux. And at least *some* of the Windows devices which work have been connected by the same wifi (even the same Velop node) as the Android devices which fail, even if the majority are connected by Ethernet to the primary Velop. I'd love to see what the LAN traffic is (the HTTP GET/response) for the Android trying to get the page. And why does it work consistently for a few days and then fail consistently for a few days? Given that it only fails via the Plusnet connection, and works OK using my Vodafone mobile internet connection, I *think* the web hosting isn't the cause (but I could be wrong...). Weird.

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

MisterW — Tue, 28 Sep 2021 12:54:25 GMT

I'm puzzled as to what could be causing the fault to happen intermittently (repeated times it works, then repeated times it fails). It's something that has only just started happening, maybe two weeks ago. It's worked fine for about 2 years on my present Plusnet connection, and about 5 years before that on the Plusnet connection at our previous house).

Normally I'd suggest that, where its worked in the past and suddenly stopped working, it could be down to a change in public IP address. We often see similar issues with some VPN connections taking a dislike to certain IP ranges.

However that doesnt explain why it works on Windows & Linux but not Android/Ipad , that's just weird ....

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

martinund — Tue, 28 Sep 2021 13:56:02 GMT

I wish I could lay my hands on a simple dumb Ethernet hub, as opposed to an intelligent switch. Then I'd be able to connect it in between my Velop primary node and my router, and it would "tee" all the data onto a second Ethernet port where I could capture it with Wireshark. I might then see a difference between the request that a Windows browser makes and one that an Android browser makes, or some difference in the responses that the web server makes to the two requests. I could also capture the conversation for Android when it works and compare it with the conversation for Android when it fails.

Sadly I bought switches rather than hubs (and most/all routers include switches) to prevents all traffic being replicated on all ports, to prevent a heavy PC-to-PC conversation within my LAN saturating the rest of the LAN.

Is it normal that two devices that are both connected to the same wifi access point will not be able to see each other's traffic? I thought that a wireless LAN behaved like lots of ports of an Ethernet hub, in that all of the wifi-connected devices see all of the wifi traffic (even if that is kept separate from traffic on Ethernet ports of the router).

Am I right that the same WAN address is kept as long as the DSL connection is alive - ie that if the router "reports DSL uptime" of (for example) 2 days, the WAN address will not have changed within that time? My router does seem to disconnect and reconnect at about 02:00 several times a week, so there is potential for the WAN address to change each time. I'll check the WAN address each morning and see if there's any correlation with when it does/doesn't work.

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

MisterW — Tue, 28 Sep 2021 14:18:00 GMT

Am I right that the same WAN address is kept as long as the DSL connection is alive - ie that if the router "reports DSL uptime" of (for example) 2 days, the WAN address will not have changed within that time?

Correct. Even if the DSL does drop, there's still a chance the the IP address wont change.

You mention you have a Linux machine. Its possible with some Wireless cards to set 'monitor mode' with Wireshark and capture non-directed traffic https://wiki.wireshark.org/CaptureSetup/WLAN

Alternativly, if you have 2 NICs in a Linux box , you might be able to configure as a bridge, connect it between the Velop and the hub and then use wireshark on the bridge

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

martinund — Wed, 29 Sep 2021 09:08:20 GMT

There have been "developments". The good news is that I've got Wireshark traces of three cases:

- very long delay (about 2 minutes) but eventual successful access to web page (Case 1)

- browser times out (Case 2)

- successful access to a web page (Case 3)

These traces were taken more or less consecutively - so after the browser had timed out (Case 2) I pressed page-refresh F5 (having started a new trace) and immediately the page loaded. Very random behaviour.

The bad news is that the problem also affects Linux Mint.

Interesting that for Linux Mint, it works (immediately or after a long delay) on occasions, whereas for Android it's a permanent failure with no occasional sucesses.

I was faffing around trying to enable "monitor mode" on my wireless adapter on the Linux Mint PC (thanks for the suggestion, MisterW) so I could get a trace for the Android phone browsing to the web site, when something made me try accessing the site from Firefox on Mint. And it failed. So I set Wireshark capturing and reproduced the problem.

It looks as if the delay is at the DNS query stage, translating the domain name to its IP address. In the "long delay but succeeds" trace, I can see a query, then a number of "TCP retransmission" packets from Mint client to web site (with no response) every few seconds for about 60 seconds, then about 90 seconds after the DNS query, I see a normal HTTP GET from Mint to web server with a response a few milliseconds later.

My knowledge of low-level TCP isn't good enough to decode exactly what's happening, but filtering on conversation between Mint PC and web server, there is a long gap when the Mint is sending its retransmission packets and there is no response at all from the server.

Is there anyone who could analyse the Wireshark traces? I can supply details like IP addresses and packet numbers where "the action is". There's nothing confidential in the traces (AFAIK) but there are probable a few passwords sprinkled around, so I'm reluctant to attach the traces to this thread - probably do it by private message to someone.

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

MisterW — Wed, 29 Sep 2021 10:05:07 GMT

@martinund If you think its a DNS lookup problem, have you tried using 'dig' on the mint PC ? https://phoenixnap.com/kb/linux-dig-command-examples

Results specifying different DNS servers and possibly the trace option might be informative.

Do the systems that fail have the DNS server set to the router ( 192.168.1.254 ) ?

For info , Ive just tried both the http://goosebears.co.uk/weather/ link from Firefox on my Ubuntu desktop and a dig goosebears.co.uk and both work fine.

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

martinund — Wed, 29 Sep 2021 12:43:39 GMT

I've run the various dig commands and a traceroute. At the moment Linux Mint can browse OK to the web site and I can't make it go wrong, so these are baseline results to be compared with when I next experience the fault.

One thing may be significant: my router reports its DSL uptime as being since 02:00 (approx) this morning, with a minor change of WAN address (different in final byte) since yesterday when I was getting the browser failures and I took the Wireshark traces. Plusnet DNS servers (Primary and Secondary) used were the same as before but in the opposite order, so queries may have been using the opposite server to what they are using now. Significant or red herring?

All devices (Windows, Linux, Android, iPad) that are connected to the wireless (mesh) network get their IP, gateway and DNS server details from the Linksys Velop's primary node 10.120.1.1

ipconfig/ifconfig for a device gives

IP=10.120.1.y

DHCP, DNS, gateway = 10.120.1.1

The Velop talks to the router using IP 192.168.1.65 (not sure how I chose that address, but I've set it in the router's address reservation so it's fixed) and the gateway/DNS is 192.168.1.254 (the PN router). (At one time, I had the Velop hard-coded to use (most preferable to least preferable) DNS 8.8.8.8 (Google), then 8.8.4.4, then it defaulted to 192.168.1.254 which would have used PN's DNS servers. However I removed those hard-codings to Google's DNS when I started having these problems a few weeks ago to see if it made any difference - it didn't. So the problem was the same no matter whether I used Google's or PN's DNS servers.)

The router's WAN details are:

Broadband network IP address:	87.115.[redacted]
Default gateway:	172.16.13.210
Primary DNS:	212.159.6.9
Secondary DNS:	212.159.6.10

My WAN IP changes every few days (differing usually just in the last byte) because my router seems to drop and reconnect its VDSL connection at around 02:00 several times a week (calculated from current time and connection time).

On Linux Cinnamon Mint PC...

martin@martin-mint:~$ dig goosebears.co.uk

; <<>> DiG 9.16.1-Ubuntu <<>> goosebears.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48017
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;goosebears.co.uk.       IN   A

;; ANSWER SECTION:
goosebears.co.uk.   1151   IN   A   160.153.128.26

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Sep 29 12:46:05 BST 2021
;; MSG SIZE rcvd: 61

martin@martin-mint:~$ dig @8.8.8.8 goosebears.co.uk   [Google's DNS]

; <<>> DiG 9.16.1-Ubuntu <<>> @8.8.8.8 goosebears.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6028
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;goosebears.co.uk.       IN   A

;; ANSWER SECTION:
goosebears.co.uk.   10800   IN   A   160.153.128.26

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 29 13:18:19 BST 2021
;; MSG SIZE rcvd: 61

martin@martin-mint:~$ dig @212.159.6.9 goosebears.co.uk       [Plusnet's 1st DNS]

; <<>> DiG 9.16.1-Ubuntu <<>> @212.159.6.9 goosebears.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48232
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;goosebears.co.uk.       IN   A

;; ANSWER SECTION:
goosebears.co.uk.   6166   IN   A   160.153.128.26

;; AUTHORITY SECTION:
goosebears.co.uk.   3600   IN   NS   ns50.domaincontrol.com.
goosebears.co.uk.   3600   IN   NS   ns49.domaincontrol.com.

;; Query time: 24 msec
;; SERVER: 212.159.6.9#53(212.159.6.9)
;; WHEN: Wed Sep 29 13:22:30 BST 2021
;; MSG SIZE rcvd: 116

martin@martin-mint:~$ dig @212.159.6.10 goosebears.co.uk   [PN's 2nd DNS server]

; <<>> DiG 9.16.1-Ubuntu <<>> @212.159.6.10 goosebears.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26821
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;goosebears.co.uk.       IN   A

;; ANSWER SECTION:
goosebears.co.uk.   6079   IN   A   160.153.128.26

;; AUTHORITY SECTION:
goosebears.co.uk.   3600   IN   NS   ns50.domaincontrol.com.
goosebears.co.uk.   3600   IN   NS   ns49.domaincontrol.com.

;; Query time: 28 msec
;; SERVER: 212.159.6.10#53(212.159.6.10)
;; WHEN: Wed Sep 29 13:23:57 BST 2021
;; MSG SIZE rcvd: 116

martin@martin-mint:~$ dig goosebears.co.uk +trace

; <<>> DiG 9.16.1-Ubuntu <<>> goosebears.co.uk +trace
;; global options: +cmd
.           6582   IN   NS   m.root-servers.net.
.           6582   IN   NS   l.root-servers.net.
.           6582   IN   NS   k.root-servers.net.
.           6582   IN   NS   j.root-servers.net.
.           6582   IN   NS   i.root-servers.net.
.           6582   IN   NS   h.root-servers.net.
.           6582   IN   NS   g.root-servers.net.
.           6582   IN   NS   f.root-servers.net.
.           6582   IN   NS   e.root-servers.net.
.           6582   IN   NS   d.root-servers.net.
.           6582   IN   NS   c.root-servers.net.
.           6582   IN   NS   b.root-servers.net.
.           6582   IN   NS   a.root-servers.net.
;; Received 262 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

uk.           172800   IN   NS   nsa.nic.uk.
uk.           172800   IN   NS   nsb.nic.uk.
uk.           172800   IN   NS   nsc.nic.uk.
uk.           172800   IN   NS   nsd.nic.uk.
uk.           172800   IN   NS   dns1.nic.uk.
uk.           172800   IN   NS   dns2.nic.uk.
uk.           172800   IN   NS   dns3.nic.uk.
uk.           172800   IN   NS   dns4.nic.uk.
uk.           86400   IN   DS   43876 8 2 A107ED2AC1BD14D924173BC7E827A1153582072394F9272BA37E2353 BC659603
uk.           86400   IN   RRSIG   DS 8 1 86400 20211012050000 20210929040000 26838 . FcyMoL9te/wJe/OfC9TK5J9YT5sk2Uli2JFA7lPO0Vr6i4SECieGh0Zh oLuE1ePbT3CL1B65NDp6u2jqeuIk8IHEItWqNVJZkyTrqbZR32XO38Ac hXkmwvzl7WQqvnhJBAFRX/Lgj2JcUbnMbRVhSkMmkOI6po0EW42Zz1aG CufejyM/0XH1tzh9vS34PjRgjaakXQ7aOPt30YK/gU9+1VWKUvzDTIST 4XCNZY56EZPhLhKCi7zuv9eH5g9ChmbvLBLAD4FC4QASDn693fU9SbLC nMmZIZ9l/1aNjLkYQETlv/VO9dQH5KZutMOJsSauDyzsRHGDmMKtxaG0 ZuX93A==
;; Received 800 bytes from 199.7.91.13#53(d.root-servers.net) in 12 ms

goosebears.co.uk.   172800   IN   NS   ns49.domaincontrol.com.
goosebears.co.uk.   172800   IN   NS   ns50.domaincontrol.com.
g9f1kiihm8m9vhjk7lrvetbqceogjiqp.co.uk.   10800 IN NSEC3 1 1 0 - G9F5O8Q1LBTUKBV4FRD3PU0HUIPAP422 NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534
g9f1kiihm8m9vhjk7lrvetbqceogjiqp.co.uk.   10800 IN RRSIG NSEC3 8 3 10800 20211103011306 20210929004001 33621 co.uk. kcZFKw3z3waajkH0DJud96pZ9FkDKyIcgT2zHiT/FRDTLmWyE4iZnr1O +uQYbloFjTVd6bSNDOV46KR3zBdYbh+MDb+J2xv5nQxYuIU3KQ9HJX9J KfWlrgJBKdJeh2XNo/R8TcrYqUYQr9NT8cTgie+PS9Il/3AnB2NaI4r5 aDY=
ebv0lqlhjl9cs7rm2ridri679hi85l5s.co.uk.   10800 IN NSEC3 1 1 0 - EBV9E0EK0N0FTVQNAEOVONQP0N1Q6UBA NS DS RRSIG
ebv0lqlhjl9cs7rm2ridri679hi85l5s.co.uk.   10800 IN RRSIG NSEC3 8 3 10800 20211101152640 20210927152203 33621 co.uk. Zd+SmXLnZR+BtyWQ59FlnUy4PjCjxSgKhkRM2qUYYymn54oGtJb8g873 PqtJmYNBl3Y2BYxeJDjIb3tVUW8FvxHtdMhQAbLCmrfRtGO1n9ZXNd0A iI5DmdTs4K3XiXKnG4H3ggGaRCrwpC4CUPKsihq7U829tyK/FDEaxlg7 oBw=
;; Received 623 bytes from 43.230.48.1#53(dns4.nic.uk) in 20 ms

goosebears.co.uk.   10800   IN   A   160.153.128.26
goosebears.co.uk.   3600   IN   NS   ns50.domaincontrol.com.
goosebears.co.uk.   3600   IN   NS   ns49.domaincontrol.com.
;; Received 116 bytes from 97.74.104.25#53(ns49.domaincontrol.com) in 20 ms

martin@martin-mint:~$ traceroute www.goosebears.co.uk
traceroute to goosebears.co.uk (160.153.128.26), 64 hops max
1   10.120.1.1 0.652ms 0.620ms 0.748ms
2   192.168.1.254 2.302ms 1.017ms 1.078ms
3   * * *
4   * * *
5   195.166.143.136 15.301ms * *
6   109.159.252.234 15.082ms * *
7   166.49.214.194 14.720ms * *
8   80.157.200.225 15.114ms * *
9   217.239.58.34 20.276ms * *
10   80.156.160.34 20.131ms * *
11   188.121.32.5 20.522ms * *
12   * * *
13   * * *
14   * * *
15   * * *
16   * * *
17   * * *
18   * * *
19   * * *
20   * * *
21   * * *
22   * * *
23   * * *
24   * * *
25   * * *
26   * * *
27   * * *
28   * * *
29   * * *
30   * * *
[and so on - never completes as far as 160.153.128.26 goosebears.co.uk]

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

MisterW — Wed, 29 Sep 2021 13:24:19 GMT

At the moment Linux Mint can browse OK to the web site and I can't make it go wrong, so these are baseline results to be compared with when I next experience the fault.

That doesnt surprise me when looking at the dig results. If you look at the first dig result, Linux is defaulting to using its built in DNS caching system (DNSMASQ) (IP address of server reported as 127.0.0.53) and as its already got the lookup in its cache then that's as far as the DNS request goes.

From what I can see, your normal DNS forwarding chain is going to be Velop (10.120.1.1) , then Hub one (192.168.1.254) then PN's DNS servers. I'd be pretty sure that both the Velop and the Hub one have some caching, similar to DNSMASQ. I suspect that the problem is a failing of one of the DNS servers to forward requests under some circumstances.

What I would suggest is that when the Linux box exhibits the problem again, you try dig(s) in the following order

dig goosebears.co.uk

dig @10.120.1.1 goosebears.co.uk

dig @192.168.1.254 goosebears.co.uk

dig @212.159.6.9 goosebears.co.uk

dig @8.8.8.8 goosebears.co.uk

That should tell us exactly where the DNS forwarding is failing.

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

martinund — Wed, 29 Sep 2021 13:26:09 GMT

For completeness, and to eliminate one point of potential failure, I've turn on 2.4 GHz wifi on the router itself and connected the Linux PC to it. As far as I can see, the dig and traceroutes are the same apart from the omission of the initial hop from 10.120.1.1 to 192.168.1.254.

IP config changes from

10.120.1.x

10.120.1.1 gateway, DHCP, DNS

to

192.168.1.x
192.168.1.254 gateway, DHCP, DNS

When I first experienced the problem on Android, I did the same and it made no difference to the long delay and timeout. But I'll keep things as simple as possible!

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

martinund — Wed, 29 Sep 2021 13:29:35 GMT

MIsterW - just seen your reply of a few seconds ago. I'll try all those digs/traceroutes when it next goes wrong. Shall I go back to connecting to the Velop network or leave it connected to the router network?

As a matter of interest, should I be worried that the traceroute never completes its hops as far as the web server?

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

MisterW — Wed, 29 Sep 2021 13:42:58 GMT

Shall I go back to connecting to the Velop network or leave it connected to the router network?

Sorry, I hadnt realised you were connected directly to the router, in that case forget about the dig using the velop ip and it wont work ( and isnt relevant ).

I shouldnt worry about the traceroute, some hops wont respond. You're obviously routing to the site correctly at the moment

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

martinund — Thu, 30 Sep 2021 11:01:25 GMT

http://goosebears.co.uk/timeout/goosebears%20Linux%20-%20very%20long%20delay%20but%20eventually%20succeeds.pdf

(the last trace is with Mint connected to the mesh network, so its IP is 10.120.1.97 and the DNS is 10.120.1.1, unlike all the other traces)

The last one is probably the best one, because it does eventually recover. Apologies, I've not got to grips with "or" clauses in analysis filters, so I've got all the DNS packets followed by all the Mint-to/from-server packets.

Notice that the PC does a DNS AAAA (IPv6) query and gets a response, and then sends a few SYN packets which are retransmitted at every-doubling time intervals, with no reponse whatsoever from the server, until 2996 when a new packet is sent (ie not a repeat of an old one). This seems to trigger another DNS query.reponse (2997/3001) after which things get going and there is the normal HTTP GET/reponse.

Something seems to be causing major packet loss (either of the retransmissions or else the server's response to them) until it all comes right again or else the PC gives up with retransmitting and sends something new which this time elicits a server response.

Someone in comp.mobile.android has suggested doing tcptraceroute/tcptraceping when the fault is occurring, to see in more detail what servers are/aren't responding along the way. Sod's Law: at the moment it's working fine (even for Android). But when it next goes wrong I'll do the traces and post the results. In the meantime, I'll set up tethering on my phone and connect Mint to that wifi network, to get comparison tcptraceroute/ping traces for a connection that works all the time. And I'll do traces for Plusnet in a working state for comparison.

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

martinund — Thu, 30 Sep 2021 12:26:22 GMT

When I look more closely, for the case where it times out, there is a
DNS Query (Type AAAA = IPv6) and response almost immediately, then a few TCP
SYN packets from client to webserver which get retransmitted
1,2,4,8,16,32,64 seconds from the first copy. And no traffic back from
webserver to client whatsoever throughout the whole trace which continues
about 150 seconds after the DNS query. So no HTTP GET/response. The Analyze
filter is "ip.addr eq 192.168.1.6 and ip.addr eq 160.153.128.26" which would
show traffic in either direction.

Since the DNS response does not contain the webserver's IP, I'm wondering
whether the PC did a DNS query for the IP address long long ago and has
cached the information without making an explicit request (apart from the
AAAA query) at the time when I press "go" on the browser to load the page.

In the case that works, there's the same DNS Query and response, followed a
few packets later by HTTP GET/response for the main page and its images etc.

Here are Wireshark traces of the relevant packets, printed to PDFs. I've
done two versions: one which expands all the fields, one packet per page;
and one which is one line per packet, all packets on same page. Apart from
the DNS traffic, I've done an IPv4 conversation filter on client and
webserver.

Client PC (Linux Mint) is 192.168.1.6
Router is 192.168.1.254
Webserver is 160.153.128.26 ("ip-160-153-128-26.ip.secureserver.net" in the
traces)

http://goosebears.co.uk/timeout/timeout3.pdf
http://goosebears.co.uk/timeout/timeout3-summary.pdf
http://goosebears.co.uk/timeout/success.pdf
http://goosebears.co.uk/timeout/success-summary.pdf
http://goosebears.co.uk/timeout/goosebears%20Linux%20-%20very%20long%20delay%20but%20eventually%20succeeds.pdf

The last one is probably the one to concentrate on because it shows many cycles of retransmitted SYN packets from Mint (and absolutely no response from the server) for a period of 64 seconds, followed by a brand new SYN packet 2996 and another DNS query (2997 like 1402): both the DNS and the new SYN get responses (from router and web server respectively) and the rest of the process (HHTP GET/reponse) continue as normal.

Apologies in the last trace that I've got all the DNS packets followed by all the Mint-Server packets - I've not got the hang of "or" clauses in filters, to get all the selected packets (from both filters) in order.

This last trace is for Mint connected to the mesh network (primary node connected by Ethernet to router) rather than Mint connected directly to router. So IP is 10.120.1.97 and DNS server is 10.120.1.1.

I wonder what could cause such complete packet loss than none of the retransmitted packets get to the server or else none of the server's replies get back.

Someone in comp.mobile.android has suggested running tcptraceroute and tcpping from Mint, to give more detailed hop-by-hop information. At the moment (sod's law) it's working, but I'll run these commands (as well as tethering Mint to my phone to test the Vodafone connection) as comparisions against results for when the Plusnet connection is again playing up. Watch this space! We're getting closer: it looks like it's not a DNS problem but a major packet-loss problem...

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

dvorak — Thu, 30 Sep 2021 12:55:30 GMT

Moderators Note

Post released from automated spam filter

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

martinund — Thu, 30 Sep 2021 14:22:21 GMT

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!)

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

MisterW — Thu, 30 Sep 2021 15:47:55 GMT

@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 )

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

martinund — Thu, 30 Sep 2021 16:31:07 GMT

@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!).