Set proxy settings in Windows compact 2013 for use Azure IoT SDK for C

Hello,
I want to use the Toradex example ‘azure-iot-sdk -c/Iothub_client/samples /iothub_client_sample_http/’ (on github) access the cloud. If I work without a firewall, then the connection to Cloud works. Is the firewall active, the connection is blocked.

Is there a way that the proxy setting (server address, port, user, password) can be set in the Windows Compact Image / Registry?

Thanks.

The new version of the SDK seems to support proxy for HTTP protocol:
https://github.com/Azure/azure-c-shared-utility/blob/8c9173f4ad7eb528efbc3f6a929e01d65aa77cd1/devdoc/http_proxy_io_requirements.md
did you already try that?
I see that there are some samples showing how to use it.
You may add some additional trace information inside:
https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/httpapi_wince.c
to check if the client uses the final URL or provides the URL for the proxy.

@valter.tx
I use the new version of the SDK: release_2017_12_14. In this sample, i add the code for using a Proxy configuration:

HTTP_PROXY_OPTIONS http_proxy_options = { 0 };
http_proxy_options.host_address = "1.2.3.4"
http_proxy_options.port = 8080;
http_proxy_options.username = "domain\\user";
http_proxy_options.password = "pwd";
			
if (IoTHubClient_LL_SetOption(iotHubClientHandle, OPTION_HTTP_PROXY, &http_proxy_options) != IOTHUB_CLIENT_OK)
{
	(void)printf("failure to set proxy\n");
}

Do you have a newer Version of the sample for Windows compact 2013? VMinute add this sample for 2 years on github.

Trace Information from the azure sdk WinCE sample: iothub_client_sample_http

Starting the IoTHub client sample HTTP...
Info: IoT Hub SDK for C, version 1.1.29
Error: Time:Tue Jan 09 23:04:01 2018 File:..\..\azure-iot-sdk-c\c-utility\adapters\httpapi_wince.c Func:HTTPAPI_CloneOption Line:636 unknown option proxy_data
Error: Time:Tue Jan 09 23:04:01 2018 File:..\..\azure-iot-sdk-c\c-utility\src\httpapiex.c Func:HTTPAPIEX_SetOption Line:609 error code = HTTPAPIEX_INVALID_ARG
Error: Time:Tue Jan 09 23:04:01 2018 File:..\..\azure-iot-sdk-c\iothub_client\src\iothubtransporthttp.c Func:?IoTHubTransportHttp_SetOption@@YA?AW4IOTHUB_CLIENT
_RESULT_TAG@@PAXPBDPBX@Z Line:2426 HTTPAPIEX_SetOption failed
IoTHubClient_LL_SetMessageCallback...successful.
IoTHubClient_LL_SendEventAsync accepted message [zu] for transmission to IoT Hub.
Info: HTTPAPI_Init::Start
Info: HTTAPI_Init::Time is now (UTC) Tue Jan 09 23:04:01 2018

Info: HTTPAPI_Init::End
Info: HTTPAPI_CreateConnection::Start
Info: HTTPAPI_CreateConnection::Connecting to XXXXXXXX.azure-devices.net
Info: HTTPAPI_CreateConnection::End
Info: HTTPAPI_ExecuteRequest::Start
Error: Time:Tue Jan 09 23:04:23 2018 File:..\..\azure-iot-sdk-c\c-utility\adapters\httpapi_wince.c Func:HTTPAPI_ExecuteRequest Line:324 connect failed
Info: HTTPAPI_ExecuteRequest::End=0
Confirmation[0] received for message tracking id = zu with result = (null)
Info: HTTPAPI_ExecuteRequest::Start
Error: Time:Tue Jan 09 23:04:44 2018 File:..\..\azure-iot-sdk-c\c-utility\adapters\httpapi_wince.c Func:HTTPAPI_ExecuteRequest Line:324 connect failed
Info: HTTPAPI_ExecuteRequest::End=0
Error: Time:Tue Jan 09 23:04:44 2018 File:..\..\azure-iot-sdk-c\iothub_client\src\iothubtransporthttp.c Func:?DoMessages@@YAXPAUHTTPTRANSPORT_HANDLE_DATA_TAG@@PAUHTTPTRANSPORT_PERDEVICE_DATA_TAG@@PAUIOTHUB_CLIENT_LL_HANDLE_DATA_TAG@@@Z Line
:2097 expected status code was 200, but actually was received 0... moving onIoTHubClient_LL_SendEventAsync accepted message [zu] for transmission to IoT Hub
.
Info: HTTPAPI_ExecuteRequest::Start
Error: Time:Tue Jan 09 23:05:05 2018 File:..\..\azure-iot-sdk-c\c-utility\adapters\httpapi_wince.c Func:HTTPAPI_ExecuteRequest Line:324 connect failed
Info: HTTPAPI_ExecuteRequest::End=0

I thought/hoped that the proxy was handled by the layer above the os-specific HTTP implementation, but does not seems so.
This means that https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/httpapi_wince.c
should take care of managing the proxy. This would mean store the information and then change the connect sequence so instead of connecting to host it connects to proxy and then passes the final destination URL to it.
I think that currently only:
https://github.com/Azure/azure-c-shared-utility/blob/8bf30bccdd925f61e0eecd7dbc24d243ef6fbfae/adapters/httpapi_curl.c
supports that.
This may require a change to the SDK and a pull request to have it added to the official release.

@valter.tx
How do I need to configure Windows Compact 2013 so I can use the Windows proxy?
Do you have any instructions on how to adjust the image?

It’s not an issue about the image. You can configure the HTTP implementation in CE (coming from Internet Explorer) but the SDK is not using that, it uses sockets directly.
To support proxy you need to change the implementation in the file I pointed out in my previous reply.
For HTTP (unencrypted) requests you can simply send the whole URL (domain and path) to the proxy server, for HTTPS you need first to send a CONNECT command to establish a connection to the end server getting it’s SLL certificates then, after SLL handshake, you can send the GET request directly to the target because your HTTP proxy should have established a “tunneled” connection to the end-point.
Some proxy also supports the “old” HTTP behavior via HTTPS, taking just the GET request and behaving as a man-in-the-middle. If you can control your proxy this may be the simplest implementation, but may not be compatible with 100% of HTTP proxies out there.

@valter.tx
Hello Valter, do you mean this link 'https://github.com/Azure/azure-c-shared-utility/blob/8c9173f4ad7eb528efbc3f6a929e01d65aa77cd1/devdoc/http_proxy_io_requirements.md
'?

I think that this is used with protocols that use the TLS interface (MQTT, AMQP) but, unfortunately, not for HTTP. For HTTP there are platform-specific implementations. On Linux it uses curl, for desktop Windows the WINHTTP api and for CE sockets.
As you can see in:
https://github.com/Azure/azure-c-shared-utility/blob/5db432502576db9f953764346298405c6a6d51b8/adapters/platform_win32.c
TLS_IO is currently not supported on CE.
I ported mbedTLS to CE (it’s really just a matter of rebuilding it), and so the mbed implementation may be adapted for this, but in that case you could probably use AMQP and MQTT but not HTTPS.

If you port the TLS layer to CE you may use this HTTP implementation:
https://github.com/Azure/azure-c-shared-utility/blob/fd12f45f9d59ddd1c9f991caf0c88acd3d429fc9/adapters/httpapi_compact.c
but it’s something I did not test.
If you want we can have a call discussing this, it may be faster than discussing it with messages.
I may try to help you do the implementation, but at the moment we can’t allocate resources on this.

The MQTT or AMPQ protocols would be even better than HTTP. I tried both protocols with the example code ‘iothub_client_sample_mqtt_ws’ or ‘iothub_client_sample_ampq_ws’. I found this in Source “TLS IO interface currently not supported on WEC 2013”.
If we can use mbedTLS here, this would be fine as we port mbedTLS to the platform.
Do you have an example that we can integrate mbedTLS into the azure SDK?

Here:
https://github.com/VMinute/mbedtls
you can find the changes needed to build mbedtls for CE using cmake.
Those may not be for the latest release.
Then you should be able to link it to CE-specific code, in the same way it’s built for mbed.