As reported elsewhere here, I have moved from the Thuraya 7100 (which used the #1722 dial-up, 9.6kbits/sec billed at $1/minute) to the Thuraya XT (which provides a “GPRS” connection, 50kbits/sec, billed at $6/MB).
And I found the XT just wasn’t usable. It worked but extremely slowly.
I happened to be using a windows 8 tablet and via Task Manager – Performance – Open Resource Monitor (at the bottom of the screen) I found the following
where the little bastard highlighted in yellow was the cause. Blocking source ports 53825-53828 for outgoing took care of it.
I am documenting this in case somebody goes up the same path.
It may bethat the 7100 was seen within the OS as a “metered” connection which isn’t offered by the OS to apps for background update downloads. But the XT’s GPRS connection is offered as “unmetered”. But whatever the cause, this google program decided it could “go for it”.
A google on cache.google.com doesn’t reveal much about what this process is actually doing but it seems to be sending a load of stuff to google. Some hits suggest it is your browsing history but this machine has spent most of its time in the aircraft and has not been used for general internet. I could not find the actual windows process because it is hiding behind svchost.exe. Chrome browser was not installed but possibly had been, and I know that when you uninstall Chrome it leaves behind processes which send data to google.
I realise an easier way to block all this crap is to firewall everything and allow just 1 or 2 specific sites, but that is not trivial if you want to make good use of the 50kbit/sec Thuraya XT speed which opens up a lot of options. A proper solution is to firewall everything except say port 12345 and then set up a proxy server somewhere on port 12345 and that would stop all these hidden processes running up data, but that’s a load of work…
Blocking source ports is kind of pointless as they are assigned randomly.
Peter wrote:
I realise an easier way to block all this crap is to firewall everything and allow just 1 or 2 specific sites, but that is not trivial if you want to make good use of the 50kbit/sec Thuraya XT speed which opens up a lot of options.
It takes no longer than 5 minutes to do this properly. You create a firewall profile that is most restrictive and then you just choose this profile or another one, as you see fit. No reason to spend more than a few minutes on this, really. Either firewall based on target IP or firewall based on executable name and use a “trusted” browser. Important thing is that you have to be in “block all” mode with positive exceptions, not the other way around.
Peter wrote:
It may bethat the 7100 was seen within the OS as a “metered” connection which isn’t offered by the OS to apps for background update downloads. But the XT’s GPRS connection is offered as “unmetered”. But whatever the cause, this google program decided it could “go for it”.
That might have worked somewhat 10 years ago but today applications generally do not query the connection properties. It’s not an OS thing, it’s an application thing.
Peter wrote:
It may bethat the 7100 was seen within the OS as a “metered” connection which isn’t offered by the OS to apps for background update downloads. But the XT’s GPRS connection is offered as “unmetered”.
Any connection can be set up as metered. Open the connections panel, right-click the network in question and select ‘Set as metered connection’.
Important thing is that you have to be in “block all” mode with positive exceptions, not the other way around.
Yes, of course.
But even then it can get you, because even a browser can go wild with background downloads. IE10 had several “secret” processes which downloaded megabytes of data (crap like Bing search engine updates). I spent ages blocking these. Chrome downloads (and uploads to google) huge amounts of stuff and is responsible for the last issue (BTW even if you uninstall Chrome, the silent uploads to google continue… one has to use admin rights in the command prompt to delete Chrome from /PF but one can’t delete /users/username/appdata/google so some hidden process is sitting on that). FF’s main auto update can be disabled so maybe that is the best one to use.
So the offending data flows were from inside the very apps I need to use (browsers).
The obvious other stuff (e.g. adobe and java updates) I blocked ages ago. BTW, win8 doesn’t allow the java update to be disabled. You can uncheck the checkbox but it always comes back checked. The firewall is the only way. But as you say, blocking everything and then allowing just one browser executable would be better. Well, so long as it isn’t IE or Chrome, or FF with some “safe browsing” add-on 
Blocking destination IPs is IME a waste of time. Normally there are many and the app will switch around them until it gets a connection.
One can understand why all the Iridium products all use their own apps
Any connection can be set up as metered. Open the connections panel, right-click the network in question and select ‘Set as metered connection’.
I think the option to change the connection type appears only when the connection is available. That is certainly the case at the moment. I will try it later.
I am not pleased to report that the background data ops, notably the covert google data feedback apparently emanating from IE10 (or from some IE10 add-on) has blown away the last $160 topup on the Thuraya XT phone account…
I think I will get my private wx site reworked to get everything via PHP and re-present it on a single IP and then I can firewall “all but”. The other site I have access to does present it on a single IP but it doesn’t work at all over a Thuraya connection, presumably because of MTU issues.
It is however still cheaper than Iridium!
You can’t ask every internet server in the world you want to talk to to reduce its MTU so that’s not really a solution…
There should be a way to configure your Windows to use a lower MTU if the ICMP auto-negotiation doesn’t work for some reason. Virtually all servers on the internet use 1500 as MTU and if it was a generic Thuraya issue, then the phone couldn’t talk to most servers unless the data packets are always very small. The problem must lie elsewhere.
Where is the windows 8 config?
I could not find it anywhere.
Ever since they added netsh (Vista?) there is a very simple way without messing with the registry: http://www.richard-slater.co.uk/archives/2009/10/23/change-your-mtu-under-vista-windows-7-or-windows-8/
MTU discovery is done by the client sending out packets with the don’t fragment (DF) bit set. If the packet is too large for either station on the path, an ICMP message “fragmentation required” is returned. If ICMP is blocked, then this method does not work and it is possible for client and server to agree on an MTU that doesn’t work and data is lost.
A solution to this is to limit the maximum segment size (MSS) on the client. It’s a bit ugly but your only solution if Path MTU Discovery (PMTUD) goes wrong.
netsh has definitely been around since XP and probably since WIn2K.
Personally I’d have a laptop running Debian with squid running in a default-deny configuration (using DNS names not IP addresses), and block all outbound connections except those initiated by Squid or by my ssh client.
ICMP blocking is probably the reason why we have so many MTU problems these days, because ICMPs are a good DOS attack vector. A lot of people block pings (which are ICMP packets) but they also block a lot of other stuff which then breaks.
