Discussion:
Intermittent problem browsing to one web site from Android/iPad - an update, problem gone away
(too old to reply)
NY
2024-07-29 11:06:04 UTC
Permalink
The Problem
===========

Some of you who have frequented this newsgroup for a year or so may
remember that I posted a question and request for diagnostic help in
working out why one particular web site (webspace that I rent from
GoDaddy) suddenly started giving intermittent problems when browsed from
Android and iPad devices.

The symptom was that one (but never all) of my Android devices, and also
my wife's iPad, using a variety of different browsers, would fail to
browse to the web site. One day it would be one device that was
affected, another day it would be a different device. Some browsers gave
a "cannot access" message, whereas others would eventually display a
page after a delay of about 90 seconds. Rebooting a device and/or my
router would usually solve the problem - for a few weeks. It was not
router-specific: it happened with both Plusnet's own router and my
TPlink router.

Wireshark traces (*) showed the client sending TCP packets at 1, 2, 4,
... second intervals with no response from the server. Eventually, a
response would arrive and the HTTP dialogue then proceeded, and the page
was displayed. Intriguingly it only seemed to happen with my VDSL
connection, and not with my mobile phone's Vodafone internet connection.
Sometimes turning the phone's/tablet's wifi off and then back on
(clearing a cache?) seemed to work for a while: typically I could then
browse a few different pages on the GoDaddy webspace and then it would
fail again.

I did see it very occasionally with Linux PCs (Ubuntu, Mint, MX) running
Firefox. The common factor seemed to be Linux, because Android and iPad
OSes are based on Linux. Windows PCs worked fine.

GoDaddy weren't much help in helping me diagnose the problem.


"Solution"
==========

Last month GoDaddy notified me that they were migrating my webspace from
one of their servers to another one. And ever since then, we have had no
problems. So it looks as if something at their old server had gone bad
and the migration to the new servers had caused the problem to go away.




(*) Getting Wireshark traces was not easy because of the router's
"switch" which tries to filter out all traffic that is not to/from a
device that in on that Ethernet segment. A PC that was connected by
Ethernet would not see all traffic on wifi, as expected because of the
switch. More strangely, even if the Wireshark PC was connected to the
same wifi network as the phone that experienced the problem, it didn't
see all traffic. I had to buy a managed switch which had the option of
mirroring traffic on one Ethernet port to another port, and connect a
wifi access point to one port and the Wireshark PC to the mirror, and
then connect the phone that was experiencing the problem to that wifi.
Andy Burns
2024-07-29 11:28:35 UTC
Permalink
Post by NY
Wireshark traces (*) showed the client sending TCP packets at 1, 2,
4, ... second intervals with no response from the server.
I have seen that where the server is sniffy about packet MTU, things go
wrong if any form of VPN or wifi tunnelling is introduced, but not
noticed it for a few years.
NY
2024-07-29 13:31:59 UTC
Permalink
Post by Andy Burns
Post by NY
Wireshark traces (*) showed the client sending TCP packets at 1, 2, 4,
... second intervals with no response from the server.
I have seen that where the server is sniffy about packet MTU, things go
wrong if any form of VPN or wifi tunnelling is introduced, but not
noticed it for a few years.
Given that the common factor seems to be Unix/Linux (Linux
Ubuntu/Mint/MX, Android, IOS on iPad) I wonder if there is some code in
the TCP that they all use which gets its knickers in a twist when
talking to the GoDaddy's old server.

Although the LAN trace seems to show the server failing to respond to
repeated requests from the (eg Android) client, it is possible that the
client is repeatedly sending a crap request. If I could be arsed, I'd
compare a trace of the failure with a trace now it works, looking for
the point at which the traffic diverges between "working" and "failing".

From memory, it worked when we first took out the GoDaddy web hosting
(to replace Plusnet's which was forever plagued by too much traffic
which caused the site to be mothballed until I begged for it to be
reinstated).

Then after a few years, the problem suddenly appeared - intermittently
and in phases (it consistently failed for one client, then suddenly
consistently worked for a month or so).

Then (the other month) GoDaddy moved to a new server and it seems to
have gone away again.


I established it wasn't anything simple like DNS-lookup failure when
doing URL-to-IP translation. I could always ping the webspace by URL as
well as by IP. Sadly GoDaddy's server would not allow me to browse by
IP, only by URL. I imagine it's tied in with the domain name that we
use: if I browse to the URL with the domain name, it works; if I do an
nslookup and browse to the IP, it always fails. Maybe many domains all
point to the same IP and the specific domain being browsed gets passed
to route traffic to the correct folders on the server.
Andy Burns
2024-07-29 13:38:44 UTC
Permalink
if I do an nslookup and browse to the IP, it always fails.
All shared hosting is like that, you have to have a "host:" header in
the request, which you won't get if the browser only knows the IP addr.
Graham.
2024-10-12 21:17:48 UTC
Permalink
Post by NY
(*) Getting Wireshark traces was not easy because of the router's
"switch" which tries to filter out all traffic that is not to/from a
device that in on that Ethernet segment.
I have an old 10BASE-T Layer-1 hub that I use in these situations.
(From the days when a "hub" didn't mean an ISP's router)
--
Graham.
%Profound_observation%
Loading...