SoapHttpClientProtocol throws ConnectFailure despite having successfully sent message on WM 6.5 with .NET CF 3.5

Question

Here's a knotty one.

This is a Windows Mobile 6.5 device running the .net Compact Framework 3.5.9085.00 with a simple auto-generated web service call via an automatically generated SOAP proxy, a subclass of System.Net.SoapHttpClientProtocol (C#)

The call to doInvoke() almost immediately throws a System.Net.WebException for not connecting to the network. Normally this would indicate some kind of web-proxy or connection error, however when I stick a simple logging server at the web service address then I can see the POST being received loud and clear, so it clearly can connect to the network.

The same code works absolutely fine on another device of the same model. When I use the simple logging server I can see an identical POST to the other device, but this one eventually throws a System.Net.WebException: The operation has timed-out instead (which it would, as it isn't going to get a response).

I'm baffled. There's doubtless some configuration difference between the two that's causing the problem but I've no idea what.

It's as though the first device has set up a write-only connection to the server and it falls over when it tries to read the response, but I've never heard of such a situation before.

Anybody shine any light on this one?

System.Net.WebException: Could not establish connection to network.
       at System.Net.HttpWebRequest.finishGetResponse()
       at System.Net.HttpWebRequest.GetResponse()
       at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
       at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.doInvoke(String methodName, Object[] parameters, WebClientAsyncResult asyncResult)
       ...

    Exception Status: ConnectFailure
    Exception Message: Could not establish connection to network.
    No Inner exception. 

Answer 1

Turns out that this odd behaviour is due to the device's WiFi Network Adapter being set to 'Work' instead of 'The Internet'.

This can be set through the control panel, or by adding the registry key

HKLM\ControlPanel\WiFi\Ethernet

containing value

"DestId"="{436EF144-B4FB-4863-A041-8F905A62C572}"

(Which is The Internet's GUID).

'Work' seems to be the default that you get if this registry key isn't there.

As soon as this value was set, the connection worked fine.

Why the connection can send but not receive in 'Work' mode (rather than, say, doing neither) is still a mystery, but this was how it was solved.