Is it port 8095 it doesn't like?

I don't think so.

Waiting to see if I get an answer from the Sophos forum.

I've had exactly the same problem as you, on (OSX) 10.9.4 and (Chrome) 35.0.1916.153, with
Sophos Anti-Virus 9.0.11. The only way I could find to get the speed test to run was to turn off "block access to malicious websites..." and "block malicious downloads...". Making an exception for www.thinkbroadband.com didn't work.

The symptoms were that the test tries to connect to a server, then (sometimes) tries to connect to another one, then gives up and tells it's unable to connect to please try again later.

Meanwhile, there were no problems with Firefox (except that the TBBx1 results were about a fifth of the TBBx6 results, and the latter had a glitch to 91.8 on an 80Mbps FTTC connection).

I can't understand this. Surely Sophos would screw up the Firefox connection the same as the Chrome one?
Did you get anywhere on the Sophos forums?

Can you put asterisks in the exceptions box? You might find it works if you put *.thinkbroadband.com as the speedtest connects to some different servers to complete the test after it loads the flash.

Thanks,

john

Thanks for the suggestion!

The Sophos preferences don't allow asterisks. But a range *is* allowed, as in 80.249.99.130/24.

Sadly, that range doesn't work.

Aha! I found another /24 address range which *does* work.

I'm not sure that I should say here how I found it, or what exactly it is! But I would appreciate knowing whether the entire /24 is necessary. (Maybe a /28 or even a /30 is enough?...)

I suppose this really is Sophos's issue. Maybe they think an IP address is "malicious" if it hasn't got a DNS name?

pi12ca

I got absolutely nothing from the Sophos forums.

I know its pointing to sophos, but does it work when trying a speedtest via a chrome incognito window?

pi12ca

Bumped my question on the Sophos forums and got the following response from a moderator:

I can recreate this. I'll pass the thread over to our development team for comment.

Will let you know if/when I get anything else.

Got this confirming that they are aware of the issue and it will, hopefully, be fixed in the next update:

Looking at the data generated by thinkbroadband.com's site, they've rolled their own protocol which unfortunately includes very short handshake components. This is something which tripped up our identification of non-http content. This has already been improved, and the next update should fix this issue with thinkbroadband.com's speed test tool.

Web filtering components will always have some impact on performance testing, though once we can identify content as non-http and bypass it this interference should be minimal.

Both Safari and Firefox run their flash browser plugins as a separate process, which means our Web Protection feature doesn't filter it. The performance issues are unlikely to be related to our product; as Thinkbroadband acknowledge:

> Users of Firefox and Safari in OS X may see slow speeds on the 'TBB' download figures. This is due to an issue with Flash in these browsers. We suggest Apple users try the Google Chrome browser as this is unaffected.

Ookla's speedtest.net site measures performance using the HTTP protocol, so is not affected by this HTTP identification issues, but with Chrome the results wil include time taken to scan the content. Are you able to use their speed testing services instead?