BBC, certain other websites not working on this ISP+phone combo

Question

On Windows Phone 8.1, I'm getting "We're having trouble displaying this page... Refresh the page or try again later". E.g. for

• http://bbc.co.uk
• http://metafilter.com
• http://arstechnica.co.uk

Working websites:

• https://google.co.uk
• https://duckduckgo.com
• https://en.m.wikipedia.org

I know bbc.co.uk can work because a) duh b) the BBC site worked at my home and I've used it many times (via thephone.coop, who resell service by TalkTalk).

It doesn't work at this other house though. The connection is by BT fibre (FTTC) with a BT Home Hub. It has IPv6 (though http://test-ipv6.com says the DNS can't reach IPv6-only DNS servers). It has BT's DNS typo correction hijacking enabled. I assume the DNS hijack is a default that could be disabled (but it's not really mine to mess with).

It doesn't look like a IPv6 issue. The BBC do not use IPv6 - ping6 bbc.co.uk returns unknown host (from a computer on the same net that can acces bbc.co.uk).

I don't think the BBC use HTTPS, so it's not that. I know they're planning to, but the computer that can access bbc.co.uk is not redirected to a HTTPS version.

http://6-dot-gfblip.appspot.com shows no problem with losses (or bad latency) on the wifi and DNS.

Answer 1

Looks like a certain pattern emerges in testing! Always remember to include the scheme in your URLs :).

HTTPS://bbc.co.uk works, as predicted by the pattern.

The pattern is broken by http://6-dot-gfblip.appspot.com and the original http://gfblip.appspot.com. That said, the long-distance probes to http://apenwarr.com (and eqldata.com, URL scheme unknown) suffer high latency (1000ms+) and very high loss (or latency greater than the 2000ms timeout). I notice http://gfblip.appspot.com is on ipv6 - am I seeing another pattern? Oh yes.

http://v6.testmyipv6.com works (as does the ds. version, which stands for dual-stack). http://v4.testmyipv6.com does not work.

I don't think there's a traditional HTTP proxy. It wouldn't be needed for performance on a "fibre" connection. I've checked some online tests looking at HTTP headers and caching behaviour, and a TCP traceroute. (Interesting note: http://www.proxydetect.com/ is broken, at least when accessed over ipv6. It reports a proxy using an ipv4 address (which would be even more pointless), but the ipv4 address belongs to Cloudflare, who do not provide ISPs with HTTP middlebox services).

Conclusion

The problem is with HTTP over IPv4, on this specific internet connection.

(And the phone OS, obviously. I've seen phones based on Android OS working here).

It's still not clear why. Nor do I have a workaround I could apply to the phone. There may be aircap in my future...