On 06/09/2022 19:08, Andy Burns wrote:
> NY wrote:
>
>> the phone's browser eventually gives up.
>
> what browser, Dolphin? Presumably you've tried others?
Yes, I've also tried Firefox and Google Chrome.
I've just tried three times with each browser. Dolphin and Chrome both
eventually produce "failed to load" messages. Firefox consistently
eventually gets through, with the delay between requesting the page and
it being displayed being typically around 60-90 seconds (Firefox seems
to have a longer timeout period: it is more patient and doesn't time
out!). When I'm back on the "router-AP" connected to the port-mirroring
switch, so I can get a Wireshark trace, I'll look to see if it's always
the same story: the first traffic after the browser requests the page
being a series of SYN packets with similar port numbers which retransmit
at ever-increasing intervals until one of them elicits a response and
everything then proceeds as normal.
> The retransmissions are what you'd expect if something between you and
> the webserver is chucking away packets in one direction or the other.
Yes, it looks as if either the phone's packets are not getting through
to the web server or else the server's replies are not getting back. I
wonder if there's a way to determine which...
It looks as if there's pretty major packet loss, though evidently not
100% if packets do occasionally get through. And interesting that once
initial contact has been made, all subsequent traffic gets through -
it's not as if the initial SYN packets finally get acked, but then the
next link in the chain incurs the same long delays and retries.
I was expecting to see the HTTP GET not producing a response from the
server, which could have been at a higher level (eg the HTTP server) but
it looks as if it's a much lower level where packets are disappearing
into a black hole.
> Is the webserver under your control? What O/S is it?
No it's not. It's run by GoDaddy and we rent webhosting space. I'm not
sure what OS it is, but I *think* it's Unix.
> The TCP port number re-use is odd, generally only see that if some
> "rogue" process is ripping through hundreds of TCP connection attempts
> per second and wraps round 16 bit port number within the 2MSL_WAIT period.
>
>> Success after long delay
>> ------------------------
>>
>> I've just got a trace for the case where there is a very long delay in
>> the browser, but it eventually works:
>
> have you done anything to force keep-alives?
No. What would I do to force keep-alives?
I wonder whether I've got enough evidence to suggest where the problem
may lie, so I know whether to raise a support call with my ISP (Plusnet)
or with the web server hosting company (Godaddy).
The fact that the problem is dependent on the connection (ie ISP rather
than phone's mobile internet connection over Vodafone) tends to point
the finger at Plusnet. But why should it only affect one computer (my
phone) and one web server?
Wish me luck in trying to get either company interested in running
traces to track down the problem ;-) Would they even have the technical
expertise to interpret Wireshark traces, I wonder?