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

[#1]

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?

[#2]

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.

[#3]

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.

[#4]

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 ....

[#5]

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.

[#6]

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

[#7]

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.

[#8]

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

[#9]

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]

[#10]

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.

[#11]

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!

[#12]

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?

[#13]

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

[#14]

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)

Configuration is a Plusnet Hub One with a 2.4 GHz wifi network only, to
which the Mint PC (and nothing else) is connected by wifi. There is also a
Linksys Velop mesh network whose primary node is connected by Ethernet to
the router (as IP 192.168.1.65) but AFAIK none of the traffic appears in the
trace because of the router's network switch filtering traffic. I normally
connect to the mesh network, but I've simplified things as much as possible
by enabling the router's own wifi, so as to give one fewer thing that could
be implicated.

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%20su...

(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.

[#15]

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%20su...

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...