My project utilise the azure-iot-sdks which has a dependency on this c-shared-utility and using clang 3.8.0 compiler. Currently the shared utility library fails to build with clang.

Some initial errors found include:

azure-iot-sdks/c/azure-c-shared-utility/src/constbuffer.c:116:9: error: address argument to atomic
      operation must be a pointer to _Atomic type ('uint32_t *' (aka 'unsigned int *') invalid)
        INC_REF(CONSTBUFFER_HANDLE_DATA, constbufferHandle);

There are others, but still to investigate further the amount of changes that may be required.

Would this be amenable to enabling clang compilation for this project? Or too far out of scope?

I am having issues compiling the library using /TP.

I use the cmake-gui to create a default Visual Studio 14 Win64 solution.
I select properties -> C/C++/Advanced/Compile As within Visual Studio.
I receive several compilation issues. Any suggestions?

Hi!
I'm working on a mbedtls-based C device firmware (using MQTT protocol). Since our devices uses GPRS/3G connectivity, we need to add SSL/TLS session ticketing support to restore TLS session and avoid lots of data in case of network connection failures.

I'm testing the SSL Session Ticketing with IOTHUB servers without success. I'm using both my mbedtls-based device and openssl with my PC. In both cases Azure servers seems to ignore the SSL session resume feature.

The openssl commands i used to test it are:
openssl s_client -connect myIothubInstance:8883 -reconnect

or

openssl s_client -connect myIothubInstance:8883 -sess_out ./azure_sess_ticket
openssl s_client -connect myIothubInstance:8883 -sess_in ./azure_sess_ticket

Using my own nodejs mqtt server I have no problems at all.

• Is it a (wanted) limitation included by Microsoft?
• Can you consider to support the SSL Session Ticket feature so we can reduce our data usage?
• Am I doing something wrong with TLS tickets?

Empty callbacks need commenting or integration into state machines at these points:

http_proxy_io.c
tlsio_schannel.c
uws_client.c

Hi

I have built this for Arch64 but when I am running my receiver it got stuck... at this function "xio_open".
I have checked the return value of this xio_open and its returning success but none of the registered callback is getting called.

Is I am missing something ??

I tried to execute the mssbcbs_sample with OpenSSL under Windows (no SChannel), but communication gets stuck since the client appears to be unable to verify the certificate provided by the Azure IoT Hub.
I noticed that in the websockets_sample with libwebsockets the IoT Hub certificates are provided in PEM format in the WSIO_CONFIG struct.
Is there a way to specify the same certificates when creating the TLSIO_CONFIG in the mssbcbs_sample as well?

In order to have an easier handling of WolfSSL I suggest adding it as a submodule.
Thoughts?

Cheers,
/Dan

The tlsio_schannel_destroy() function in src\tlsio_schannel.c does not free the x509certificate or the x509privatekey when they are set.

Trying the tls io in mbed os 5 with a mxchip.

Met an error "got no CA chain' when creating tls io.
In mbed-os code, the logic is like this:

if( authmode != MBEDTLS_SSL_VERIFY_NONE )
    {
        mbedtls_x509_crt *ca_chain;
        mbedtls_x509_crl *ca_crl;

#if defined(MBEDTLS_SSL_SERVER_NAME_INDICATION)
        if( ssl->handshake->sni_ca_chain != NULL )
        {
            ca_chain = ssl->handshake->sni_ca_chain;
            ca_crl   = ssl->handshake->sni_ca_crl;
        }
        else
#endif
        {
            ca_chain = ssl->conf->ca_chain;
            ca_crl   = ssl->conf->ca_crl;
        }

        if( ca_chain == NULL )
        {
            MBEDTLS_SSL_DEBUG_MSG( 1, ( "got no CA chain" ) );
            return( MBEDTLS_ERR_SSL_CA_CHAIN_REQUIRED );
        }

But when i checked the code, correct me if i am wrong, I find that during creation, io_create_parameters contains only host name and port, seems there is no way to providing ca chain:

CONCRETE_IO_HANDLE tlsio_mbedtls_create(void* io_create_parameters)
  -> mbedtls_init((void *)result,tls_io_config->hostname);
     -> mbedtls_x509_crt_init(&result->cacert)
          mbedtls_ssl_conf_authmode(&result->config,MBEDTLS_SSL_VERIFY_OPTIONAL)

Update the auth mode to NONE then it works, but I got no clue if it is OPTIONAL.

Appreciate any help here.

Hi dear friends,

Recently there was a rename from Base64_Encode to Base64_Encoder.
This is just poetry and you might decide to fix this at your convenience, but Base64_Encoder is not a good name (consistent with how naming is done throughout the C SDK).

Usually the naming is {namespace}_{verb}
Like String_create.

Base64_Encoder refers to the noun encoder, does not end with a verb. If this function would have created an encoder it could be called Base64_Encoder_Create. But the function encodes bytes to Base64, thus it could be called something like Base64_Encode_Bytes.

This is obviously a small issue, but since the fix for the name collision is being done now, I'd suggest doing the rename now, so that it does not get dragged forever as some minor annoyance.

Cheers,
/Dan

Since the variable name LOG_INFO conflicts with the variable used by the Linux standard logging system in /usr/include/syslog.h, it is better to use a different name.

Hi,

We are using part of this utility in combination with a ESP32 chip.
We are seeing xio dowork calls after our connection has closed.
An error occurred and the state was changed to TLSIO_STATE_ERROR, the connection was being closed and after some debugging we found that the state in tlsio_mbedtls was not changed to TLSIO_STATE_NOT_OPEN, and remains in TLSIO_STATE_CLOSING state.
Which allows the dowork in tlsio_mbedtls to try and do actual work.

On line 236 and 237 we saw commented lines that would fix this problem
on_underlying_io_close_complete()

Nowhere else but the create and open functions is the state changed to TLSIO_STATE_NOT_OPEN.

Are there any reasons why these lines are commented?

Changing line 102 to *current_ms = (tickcounter_ms_t)(tick_counter_instance->current_ms / 1000) gets away with this run time error. (Intermittently)

Setup
Discovered in parent project azure-iot-sdk-c, branch lts_07_2017
Running on Linux 4.1.29, armv7l

Description of the problem
Failure to recover from network issues due to various reasons:

1. When network issues occur, the stack can set the io_state value in socketio_berkeley.c to "IO_STATE_ERROR" which is not handled correctly in socketio_open().
2. Similarly, in tlsio_openssl.c the tlsio_state can be set to TLSIO_STATE_ERROR which is not handled correctly in tlsio_openssl_open().

It looks like issue #2 was reported here as well: Azure/azure-iot-sdk-c#212

We fixed the issues in our Steelcase fork and will provide a PR shortly.

Hello,

I tried to get snapshots from ip camera using http api in my implementation of Azure field gateway (using Azure Gateway IoT SDK). I have the following code:

#define HOST_NAME (const char*)"96.10.1.168"
#define RELATIVE_PATH (const char*)"/axis-cgi/jpg/image.cgi?resolution=640x480"

HTTPAPI_Init();

unsigned int statusCode;
HTTPAPI_RESULT result;
HTTP_HEADERS_HANDLE requestHttpHeaders;
HTTP_HEADERS_HANDLE responseHttpHeaders;
BUFFER_HANDLE bufferHandle;
HTTP_HANDLE httpHandle = HTTPAPI_CreateConnection(HOST_NAME);
requestHttpHeaders = HTTPHeaders_Alloc();
responseHttpHeaders = HTTPHeaders_Alloc();
bufferHandle = BUFFER_new();

result = HTTPAPI_ExecuteRequest(
	httpHandle,
	HTTPAPI_REQUEST_GET,
	RELATIVE_PATH,
	requestHttpHeaders,
	NULL,
	0,
	&statusCode,
	responseHttpHeaders,
	bufferHandle);

HTTPHeaders_Free(requestHttpHeaders);
requestHttpHeaders = NULL;
HTTPHeaders_Free(responseHttpHeaders);
responseHttpHeaders = NULL;
BUFFER_delete(bufferHandle);
HTTPAPI_CloseConnection(httpHandle);
HTTPAPI_Deinit();

I built this code in VS2015 and run it on the Win10. However, I still get the following error:
Error: Time:Wed Nov 30 15:52:10 2016 File:C:\azure-iot-gateway-sdk\deps\c-utility\adapters\httpapi_winhttp.c Func:_HTTPAPI_ExecuteRequest Line:437 WinHttpSendRequest: (result = HTTPAPI_SEND_REQUEST_FAILED).
Error: Time:Wed Nov 30 15:52:10 2016 File:C:\azure-iot-gateway-sdk\deps\c-utility\adapters\httpapi_winhttp.c Func:_HTTPAPI_ExecuteRequest Line:437 GetLastError: The operation timed out

BTW, 96.10.1.168 is the publicly available ip camera and the request http://96.10.1.168/axis-cgi/jpg/image.cgi?resolution=640x480 works well in browser or postman. Any idea, what's wrong with http api?

Best Regards,
Peter

Hi,

I'm facing issues with the schannel version of tlsio when using the azure sdk.
When using a proxy and the device is disconnected, the reconnection is never back on, but instead I have the following error:

[13:55:08.820][ERROR]{C:\Sources\IoTHubAgent\externals\azure-iot-sdk-c\c-utility\adapters\socketio_win32.c:528}         Socketio_Failure: Receiving data from endpoint: 10054.
[13:55:08.820][ERROR]{C:\Sources\IoTHubAgent\externals\azure-iot-sdk-c\c-utility\src\wsio.c:448}                        on_underlying_ws_error called with error code 3
[13:55:09.330][ERROR]{C:\Sources\IoTHubAgent\externals\azure-iot-sdk-c\c-utility\src\tlsio_schannel.c:739}              [0x80090308]
[13:55:09.331][ERROR]{C:\Sources\IoTHubAgent\externals\azure-iot-sdk-c\c-utility\src\wsio.c:150}                        wsio_close when not open.

I use the last tag 2017-12-14.
This happens only when connecting through a proxy.

It may be the same problem as the Azure/azure-iot-sdk-c#264 issue I wrote for the Linux tlsio.

Hi,
I'm using the tlsio_mbedtls.c file provided on your the azure-c-shared-utility repo on my embedded project.
I'm guessing if there is a rapid way to use it with Visual studio or Linux too (some like the -Duse flags present for wolfssl, openssl and so on...).

I'm experiencing some problems on Disconnection/Connection behaviour using my (custom) embedded device.
Before to raise some other questions/tips I need to have a feedback using also a PC among with your socketio_xxx files.

Running cmake -Duse_installed_dependencies=ON ../ I get this:

CMake Error at CMakeLists.txt:659 (install):
  install TARGETS given target "aziotsharedutil_dll" which does not exist in
  this directory.

Dan advised to add -Dbuild_as_dynamic=ON and it worked. He also suggested that dll was supposed to be built always.

home/wzj/openwrt/sdk_x1000/src/c-utility/src/wsio.c: In function 'wsio_open':
/home/wzj/openwrt/sdk_x1000/src/c-utility/src/wsio.c:782:21: error: 'lws_client_connect' is deprecated (declared at /home/wzj/openwrt/sdk_x1000/src/c-utility/deps/libwebsockets/lib/libwebsockets.h:2084) [-Werror=deprecated-declarations]
cc1: all warnings being treated as errors

xlogging.h is not a necessary header file in xio.h

I'm developing my application with azure sdk. But 'xlogging.h's LOG utily' comflicts with my own LOG utility, while I don't need 'xlogging.h's LOG utily'.

so you can remove xlogging.h from xio.h, if developer need your log utility, they can include xlogging.h explicitly. However in my opinion, no other developer need log utility inside azure sdk.

I noticed that inc/azure_c_shared_utility/xlogging.h is saved as Latin-1 encoding (for pretty single quotations in a comment), so it causes compilation error because of "treating warning as error" when the developer uses non Latin-1 code page console in Windows.
It is just messy when I build sources, but it is better and easy to save as UTF-8. Thanks!

Azure IoT builds are failing on the ESP32 Toolchain. A dependency to iothub_client_retry_control has been added in iothubtransport_mqtt_common.c: Azure/azure-iot-sdk-c@3e95cee but the component object
sdk/iothub_client/src/iothub_client_retry_control.o \
is missing from the component's makefile (azure-c-shared-utility/build_all/esp32/sdk/component.mk).
This produces errors such as
libazure-iot.a(iothubtransport_mqtt_common.o):(.literal.InitializeTransportHandleData+0x40): undefined reference to retry_control_create
Adding sdk/iothub_client/src/iothub_client_retry_control.o \ to azure-c-shared-utility/build_all/esp32/sdk/component.mk under COMPONENT_OBJS fixes the issue.

when trying to build on Linux I am getting following error
/azure-c-shared-utility/adapters/httpapi_curl.c: 14:23

include curl/curl.h <<

Seems like a submodule for curl need to be added in dependencies for Linux build??

For example, CMAKE function set_platform_files has a bug evaluating use_condition and use_etw. They should not have ${ ... } on if statements.

function(set_platform_files c_shared_dir)

    if(WIN32)

        if(${use_condition})

            set(CONDITION_C_FILE ${c_shared_dir}/adapters/condition_win32.c PARENT_SCOPE)

        endif()

        if(NOT ${use_etw})

            set(XLOGGING_C_FILE ${c_shared_dir}/src/xlogging.c PARENT_SCOPE)

            set(LOGGING_C_FILE ${c_shared_dir}/src/consolelogger.c PARENT_SCOPE)

            set(LOGGING_H_FILE ${c_shared_dir}/inc/azure_c_shared_utility/consolelogger.h PARENT_SCOPE)

        else()

https://github.com/Azure/azure-c-shared-utility/blob/master/configs/azure_c_shared_utilityFunctions.cmake

See subject.

Hi,

I'm facing an issue using the HTTP API.
I need to use the SetOption method to configure a proxy :

httpapi_res = HTTPAPI_SetOption(http_handle, OPTION_HTTP_PROXY, (void*)&proxy);

This code works on Linux but not on Windows, the option seems not to be handled in the httpapi_winhttp.c implementation:

unknown option proxy_data

Thanks.

libressl dropped FIPS_mode_set.

For me the following would work at least. Don't think it would hurt anyone with pristine openssl either, so maybe consider this:

diff --git a/src/tlsio_openssl.c b/src/tlsio_openssl.c
index 5cd805b..a9db3c1 100644
--- a/src/tlsio_openssl.c
+++ b/src/tlsio_openssl.c
@@ -930,7 +930,9 @@ void tlsio_openssl_deinit(void)
 {
     openssl_dynamic_locks_uninstall();
     openssl_static_locks_uninstall();
+#ifndef LIBRESSL_VERSION_NUMBER
     FIPS_mode_set(0);
+#endif
     CRYPTO_set_locking_callback(NULL);
     CRYPTO_set_id_callback(NULL);
     ERR_free_strings();

porting_guide.md provides guidance on how to port C Shared utility to other paltforms. However, the information provided by it is not enough.

My target system is bare metal + lwip, so I only can use event-driven (asynchronous) Raw/TCP API of lwip for porting C Shared Utility. From porting_guide.md, it describes:

1. Determine if you also need to create an xio socket adapter. This depends on your TLS library. If the TLS library on your platform directly talks to the socket interface specific to your OS/platform and there is no way to intercept the encrypted bytes send and received by the TLS library to/from the socket then you should skip attempting to create an xio for the socket level, and simply create an xio adapter for the TLS library only.

I have two question about above statement:

1. I think I should skip implementing xio socket adapter because I only can use lwip raw/TCP API. Will I lose some functionalities if I don't implement xio socket adapter? For example, I cannot use http APIs of Azure IoT C SDK because I don't implement xio scoked adapter.
2. I found there is file named socket_async.c, I think I can implement the same functionality by using lwip raw/TCP API. So does it mean I still can implement xio socket adapter by using lwip raw/TCP API?

Thanks!

I build Azure_iot_sdk_c with Visual studio 2017 compiler on Windows Server 2016, but it failed with with warning C4701. could you help have a look about this issue? Thanks in advance!

Failures:
d:\azure_iot_sdk_c\src\iothub_client\src\uamqp_messaging.c(563): warning C4701: <func:#50 "_readMessageIdFromuAQMPMessage"> potentially uninitialized local variable 'result' used [D:\Azure_iot_sdk_c\build_x86\iothub_client\tests\uamqp_messaging_ut\uamqp_messaging_ut_exe.vcxproj]
d:\azure_iot_sdk_c\src\iothub_client\src\uamqp_messaging.c(683): warning C4701: <func:#51 "_readCorrelationIdFromuAQMPMessage"> potentially uninitialized local variable 'result' used [D:\Azure_iot_sdk_c\build_x86\iothub_client\tests\uamqp_messaging_ut\uamqp_messaging_ut_exe.vcxproj]

Repro steps:

1. Open VS2017 x86 Native tools command tool
2. git clone --recursive http://www.github.com/azure/azure-iot-sdk-c D:\Azure_iot_sdk_c\src
3. cd D:\Azure_iot_sdk_c
4. mkdir build_x86 && pushd build_x86
5. cmake -G "Visual Studio 15" -DCMAKE_SYSTEM_VERSION=10.0.15063.0 -Drun_unittests:BOOL=ON ..\src\
6. msbuild azure_iot_sdks.sln /p:Configuration=Release /p:Platform=win32 /m /t:Rebuild

liuxg@liuxg:/snappy/desktop/azure-c-shared/cmake$ cd make ...
bash: cd: make: No such file or directory
liuxg@liuxg:/snappy/desktop/azure-c-shared/cmake$ cd make ..
bash: cd: make: No such file or directory
liuxg@liuxg:~/snappy/desktop/azure-c-shared/cmake$ cmake ..
-- Shared_Util architecture: x86_64
CMake Error at testtools/CMakeLists.txt:9 (add_subdirectory):
The source directory

/home/liuxg/snappy/desktop/azure-c-shared/testtools/ctest

does not contain a CMakeLists.txt file.

CMake Error at testtools/CMakeLists.txt:10 (add_subdirectory):
The source directory

/home/liuxg/snappy/desktop/azure-c-shared/testtools/testrunner

does not contain a CMakeLists.txt file.

CMake Error at testtools/CMakeLists.txt:11 (add_subdirectory):
The source directory

/home/liuxg/snappy/desktop/azure-c-shared/testtools/umock-c

does not contain a CMakeLists.txt file.

-- iothub architecture: x86_64
-- Configuring incomplete, errors occurred!
See also "/home/liuxg/snappy/desktop/azure-c-shared/cmake/CMakeFiles/CMakeOutput.log".

Hi,

I was facing issue by setting certificates for the HTTP_API.
After reviewing the code of httpapi_curl.c I realize that setting option for:

• SU_OPTION_X509_CERT
• SU_OPTION_X509_PRIVATE_KEY

Always returned HTTPAPI_OK

Branch: master
also on
Tag: 2017-02-10 (line 681 and 711)

Thanks

Alexandre

It would be so nice if tickcounter would use GetTickCount in order to have less overhead.

Typically tickcounter is used for timeout measurement and the 10-15ms resolution of GetTickCount should be good enough for Windows for this task.

Thanks,
/Dan

Hi,

Since last Friday, after the last tag update, it seems that something in submodules is broken. The three modules ctest, testrunner and umock are unable to find the commits.

$ git clone --recursive https://github.com/Azure/azure-c-shared-utility.git -b 2017-10-06

Here the console output:

Cloning into 'azure-c-shared-utility'...
remote: Counting objects: 15158, done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 15158 (delta 5), reused 7 (delta 1), pack-reused 15131
Receiving objects: 100% (15158/15158), 8.64 MiB | 1.50 MiB/s, done.
Resolving deltas: 100% (10512/10512), done.
Checking connectivity... done.
Note: checking out 'f0006d9d0df434a87f66e2ad944bd9784ce47929'.
Submodule 'testtools/ctest' (https://github.com/Azure/azure-ctest.git) registered for path 'testtools/ctest'
Submodule 'testtools/testrunner' (https://github.com/Azure/azure-c-testrunnerswitcher.git) registered for path 'testtools/testrunner'
Submodule 'testtools/umock-c' (https://github.com/Azure/umock-c.git) registered for path 'testtools/umock-c'
Cloning into 'testtools/ctest'...
remote: Counting objects: 250, done.
remote: Total 250 (delta 0), reused 0 (delta 0), pack-reused 250
Receiving objects: 100% (250/250), 164.34 KiB | 239.00 KiB/s, done.
Resolving deltas: 100% (121/121), done.
Checking connectivity... done.
fatal: reference is not a tree: 62e29047979e66c321eacfcc009dc310904e0d84
Cloning into 'testtools/testrunner'...
remote: Counting objects: 208, done.
remote: Total 208 (delta 3), reused 3 (delta 3), pack-reused 204
Receiving objects: 100% (208/208), 836.48 KiB | 513.00 KiB/s, done.
Resolving deltas: 100% (100/100), done.
Checking connectivity... done.
fatal: reference is not a tree: 043791e53d81a6a1750573542765093d22effa29
Cloning into 'testtools/umock-c'...
remote: Counting objects: 963, done.
remote: Total 963 (delta 0), reused 0 (delta 0), pack-reused 963
Receiving objects: 100% (963/963), 416.23 KiB | 415.00 KiB/s, done.
Resolving deltas: 100% (649/649), done.
Checking connectivity... done.
fatal: reference is not a tree: be1d1544c4e3d707f47a604c6c573cecd4cce46f
Unable to checkout '62e29047979e66c321eacfcc009dc310904e0d84' in submodule path 'testtools/ctest'
Unable to checkout '043791e53d81a6a1750573542765093d22effa29' in submodule path 'testtools/testrunner'
Unable to checkout 'be1d1544c4e3d707f47a604c6c573cecd4cce46f' in submodule path 'testtools/umock-c'

Thanks,
Alexis.

Compiling in VS2014 - error in MqttAdapter.cs line 981.

FIX: Change to
ShutdownOnError(context, string.Empty, new TimeoutException (ErrorCode.KeepAliveTimedOut.ToString(), new Exception("Keep Alive timed out.")));

[ 22%] Linking C executable umock_c_ut_exe
[ 22%] Built target umock_c_ut_exe
[ 22%] Linking CXX static library libmicromock_ctest.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libmicromock_ctest.a(micromocktestmutex.cpp.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libmicromock_ctest.a(micromocktestmutex.cpp.o) has no symbols
[ 22%] Built target micromock_ctest
make: *** [all] Error 2
// ------------------------------------------------------------------------------
I built it step by step:
1.Clone azure-c-shared-utility,and checked out the develop branch
2. Create a folder called cmake under azure-c-shared-utility
3.Switch to the cmake folder and run "cmake .."
4.switch to the "/azure-c-shared-utility/build_all/linux/" and run "sudo ./build.sh"
and then I failed in building the azure-c-shared-utility.
Any help would be appreciated.

I have been working hard to cross compile this library for our own custom target deployment, however I have been running into a great deal of trouble with OpenSSL with FIPS support. I can't get my SSL build to pass the key verification process. As I am a supporter of good security practices , this level of protection for our application is kind of overkill. Therefore I was wondering if an FIPS_MODE_DISABLE flag can be added to the tlsio_openssl.c file around line 1017

#if (OPENSSL_VERSION_NUMBER >= 0x00907000L) && (OPENSSL_VERSION_NUMBER < 0x20000000L) #ifndef FIPS_MODE_DISABLE FIPS_mode_set(0); #endif #endif

Any thoughts ?

I'm running the recent version of c-utlity (62223f1) on a Linux host with OpenSSL 1.0.2g.

The issue is easily reproducible in scenarios where tlsio's connection is refused, e.g.:

• tlsio uses TLSv1, but the peer requires TLSv1.2;
• the peer's certificate is not signed by CA known to tlsio client.

In such cases I can observe TLS alert packets and actually whole TCP session shutting down, but neither on_io_error nor on_io_open_complete (expected IO_OPEN_ERROR as result parameter) callback is executed.

Hello,

commit 28f3614 introduces function
static int load_certificate_chain(SSL_CTX* ssl_ctx, const char* ecc_cert)
without declaring SSL_CTX. So the build on Debian 9 (stretch) fails:

[  0%] Building C object bld/src/libiotsdk/CMakeFiles/libiotsdk.dir/__/__/__/deps/shared/src/x509_openssl.c.o
cd /home/klj/iot-gateway-proxy/build/cmake/Debug/bld/src/libiotsdk && /usr/bin/cc  -DNO_ZLOG -DUSE_OPENSSL=1 -D_DEBUG -D_POSIX_C_SOURCE=200112L -I/home/klj/iot-gateway-proxy/deps/shared/inc -I/home/klj/iot-gateway-proxy/deps/umqtt/inc  -g -fPIC   -std=gnu99 -o CMakeFiles/libiotsdk.dir/__/__/__/deps/shared/src/x509_openssl.c.o   -c /home/klj/iot-gateway-proxy/deps/shared/src/x509_openssl.c
/home/klj/iot-gateway-proxy/deps/shared/src/x509_openssl.c: In function ‘load_certificate_chain’:
/home/klj/iot-gateway-proxy/deps/shared/src/x509_openssl.c:70:28: error: dereferencing pointer to incomplete type ‘SSL_CTX {aka struct ssl_ctx_st}’
                 if (ssl_ctx->extra_certs != NULL)
                            ^~
/home/klj/iot-gateway-proxy/deps/shared/src/x509_openssl.c: In function ‘x509_openssl_add_certificates’:
/home/klj/iot-gateway-proxy/deps/shared/src/x509_openssl.c:299:38: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
             BIO_METHOD* bio_method = BIO_s_mem();
                                      ^~~~~~~~~

I just updated (via nuget) to 1.0.29 and am now experiencing the following issue:
Error: Time:Sat Mar 11 21:38:55 2017 File:c:\a\azure-iot-sdk-c\c-utility\adapters\lock_win32.c Func:_Unlock Line:106 ReleaseSemaphore failed: 298

Interestingly, I'm not actually using the IoT library so removed it. Now I encounter compile issues:
Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol __imp__CryptDecodeObjectEx@32 referenced in function _x509_schannel_create aziotsharedutil.lib(x509_schannel.obj) 1
Error LNK2019 unresolved external symbol __imp__CertCreateCertificateContext@12 referenced in function _x509_schannel_create aziotsharedutil.lib(x509_schannel.obj) 1
Error LNK2019 unresolved external symbol __imp__CertFreeCertificateContext@4 referenced in function _x509_schannel_create aziotsharedutil.lib(x509_schannel.obj) 1
Error LNK2019 unresolved external symbol __imp__CertSetCertificateContextProperty@16 referenced in function _x509_schannel_create aziotsharedutil.lib(x509_schannel.obj) 1
Error LNK2019 unresolved external symbol __imp__CryptStringToBinaryA@28 referenced in function _x509_schannel_create aziotsharedutil.lib(x509_schannel.obj) 1

When running the IoTHubClient SDK sample for AMQP
azure-iot-sdks/c/iothub_client/samples/iothub_client_sample_amqp/windows/
with latest SDK version 1.0.7 on a Windows 10 PC, I get the following error:

_Error: Time:Thu May 19 00:03:14 2016 File:C:\repos\azure-iot-gateway-sdk\deps\azure-c-shared-utility\src\tlsio_schannel.c Func:on_underlying_io_bytes_received Line:395 [0x80090308]

The error is generated in the file due to the status value -2146893048 received from the function InitializeSecurityContext in sspi.c class.

The status -2146893048 refers to SEC_E_INVALID_TOKEN error code.

Any idea why this error is occuring?

Update 20-May:
This is working using version v1.0.5 of the SDK, but seem broken from v1.0.6

Thanks
/Henrik

PROBLEM:

The file base64.c in the c-utility shared repo defines the function Base64_Encode().

The same function is also defined by WolfSSL in the file coding.c

When the azure c-iot-sdk is compiled using WolfSSL an error occurs related to multiple definitions of the Base64_Encode() function.

To reproduce it you can simply use WolfSSL and ensure that WOLFSSL_BASE64_ENCODE is defined.

In my case Nucleus was the OS but i am sure it can be reporduced on any platform such as LINUX or WINDOWS

FIX:

To Fix the issue i changed the name in the following files of the SDK:

c-utility/inc/azure_c_shared_utility/base64.h :

old name : Base64_Encode
new name : Base64_Encode_Azure

c-utility/src/base64.c :

old name : Base64_Encode()
new name : Base64_Encode_Azure()

c-utility/src/sastoken.c :

old name : Base64_Encode()
new name : Base64_Encode_Azure()

When I switch to OpenSSL on Windows I have a few issues:

1. tlsio_openssl_get_interface_description() in platform_win32.c hardcodes schannel
   How to fix it for multiple library support?

2. SSL_library_init() is not called.
   It should be called in platform_init() put that is generic code.
   See 1) about best way to add transport choices in platform_win32.c

3. tlsio_openssl_get_interface_description() hardcodes TLS1.0
   Should be configurable.

4. No way to set SSL_CTX_set_cert_verify_callback()
   Can't do it in application code because I need a pointer to SSL_CTX.
   Which API should be extended?

Azure/azure-iot-arduino#25

This could lead to incorrect/inconsistent behavior on different boards.

Hi folks,

I'm trying to build the c-utility as part of the azure-iot-sdk for C, but stumble right upon the first file to be compiled. GCC spits out an error log of 61 kB, so I'm putting this into an attachment instead of pasting thousand lines of error messages here. Here are just the first two errors, because these are the ones repeated most:

In file included from <build-dir>/azure-iot-sdk-src/c-utility/inc/azure_c_shared_utility/umock_c_prod.h:23:0,
                 from <build-dir>/azure-iot-sdk-src/c-utility/inc/azure_c_shared_utility/buffer_.h:16,
                 from <build-dir>/azure-iot-sdk-src/c-utility/src/base32.c:8:
<build-dir>/azure-iot-sdk-src/c-utility/inc/azure_c_shared_utility/macro_utils.h:22951:51: error: unknown type name 'IF2'; did you mean 'IF'?
 #define IF(condition, trueBranch, falseBranch) C2(IF,ISZERO(condition))(trueBranch, falseBranch)
                                                   ^
<build-dir>/azure-iot-sdk-src/c-utility/inc/azure_c_shared_utility/macro_utils.h:6985:18: note: in definition of macro 'C2_'
 #define C2_(x,y) x##y
                  ^
<build-dir>/azure-iot-sdk-src/c-utility/inc/azure_c_shared_utility/macro_utils.h:22951:48: note: in expansion of macro 'C2'
 #define IF(condition, trueBranch, falseBranch) C2(IF,ISZERO(condition))(trueBranch, falseBranch)
                                                ^~
<build-dir>/azure-iot-sdk-src/c-utility/inc/azure_c_shared_utility/umock_c_prod.h:31:31: note: in expansion of macro 'IF'
     result modifiers function(IF(COUNT_ARG(__VA_ARGS__),,void) FOR_EACH_2_COUNTED(UMOCK_C_PROD_ARG_IN_SIGNATURE, __VA_ARGS__));
                               ^~
<build-dir>/azure-iot-sdk-src/c-utility/inc/azure_c_shared_utility/buffer_.h:20:1: note: in expansion of macro 'MOCKABLE_FUNCTION'
 MOCKABLE_FUNCTION(, BUFFER_HANDLE, BUFFER_new);
 ^~~~~~~~~~~~~~~~~
In file included from <build-dir>/azure-iot-sdk-src/c-utility/src/base32.c:8:0:
<build-dir>/azure-iot-sdk-src/c-utility/inc/azure_c_shared_utility/buffer_.h:20:1: error: macro "FOR_EACH_2_COUNTED_2" requires 3 arguments, but only 2 given
 MOCKABLE_FUNCTION(, BUFFER_HANDLE, BUFFER_new);
 ^~~~~~~~~~~~~~~~~~~~

I've tried to fix this on my own for two days now, but I'm totally lost in the utterly complex macro stuff you guys are doing there. And since this is the default build (I just ran cmake), I post this now as an issue to be hopefully fixed soon by the maintainers. Let me know if you need further input or some further tests to be conducted.

My environment is OSX 10.11.6 with homebrew's gcc 7.2.0. In contrast, the code builds without any warning when using Apple's clang (Apple LLVM version 8.0.0 (clang-800.0.42.1)).

Attachments:
build.log

this causes ambiguous build behaviour. For instance iot-sdk does not build with musl libc as here strings.h is included from /usr/include/string.h ...

[  1%] Building C object iothub_service_client/CMakeFiles/iothub_service_client.dir/src/iothub_registrymanager.c.o
In file included from /usr/local/include/azureiot/azure_c_shared_utility/strings.h:7:0,
                 from /usr/include/string.h:57,
                 from /usr/include/fortify/string.h:20,
                 from /usr/local/include/azureiot/azure_c_shared_utility/macro_utils.h:11,
                 from /usr/local/include/azureiot/azure_c_shared_utility/umock_c_prod.h:23,
                 from /usr/local/include/azureiot/azure_c_shared_utility/gballoc.h:19,
                 from /azure-iot-gateway-sdk/deps/iot-sdk-c/iothub_service_client/src/iothub_registrymanager.c:10:
/usr/local/include/azureiot/azure_c_shared_utility/strings.h:18:1: error: unknown type name 'IF'
 MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_new);
 ^
/usr/local/include/azureiot/azure_c_shared_utility/strings.h:19:1: error: unknown type name 'IF'
 MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_clone, STRING_HANDLE, handle);
 ^
/usr/local/include/azureiot/azure_c_shared_utility/strings.h:20:1: error: unknown type name 'IF'
 MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_construct, const char*, psz);
 ^
/usr/local/include/azureiot/azure_c_shared_utility/strings.h:21:1: error: unknown type name 'IF'
 MOCKABLE_FUNCTION(, STRING_HANDLE, STRING_construct_n, const char*, psz, size_t, n);
 ^
...

Build fails with G++ on Linux if the file azure_c_shared_utility/platform.h is included at the top of a cpp file. This is because platform.h includes several other files, and if compiling as C++ then eventually cstddef will be included inside an extern "C" block. G++ will then fail with errors about template with C linkage and template specialization with C linkage.

The easiest fix is to manually include cstddef before including platform.h but this is just a workaround.

In the porting guide the section on creating a socket IO implementation just has To be filled in as shown below.

Creating a socket IO implementation

This is needed if an existing out of the box TLS adapter is used.

To be filled in.

[ERROR] /azure-iot-devkit/azure-iot-sdk-c/c-utility/adapters/socketio_mbed.c:14:58: fatal error: azure_c_shared_utility/tcpsocketconnection_c.h: No such file or directory
#include "azure_c_shared_utility/tcpsocketconnection_c.h"

/azure-iot-devkit/azure-iot-sdk-c/c-utility/adapters/tcpsocketconnection_c.cpp:8:58: fatal error: azure_c_shared_utility/tcpsocketconnection_c.h: No such file or directory

#include "tcpsocketconnection_c.h" works the magic.

Error in CMAKELISTS.txt:
The "crypt32 ws2_32 secur32" libs need to be added to the WIN32 option.
Do I need to do a pull request or can someone make the edit?

if(${use_openssl})
  if (WIN32)
    target_link_libraries(
       aziotsharedutil
       $ENV{OpenSSLDir}/lib/ssleay32.lib 
       $ENV{OpenSSLDir}/lib/libeay32.lib 
       crypt32 ws2_32 secur32)
    else()
        target_link_libraries(aziotsharedutil ssl crypto)
    endif()
endif()

Fedora by default builds curl using NSS instead of OpenSSL This causes the Azure IoT gateway samples to segfault while trying to establish a connection to the iothub. With help from @andrew-buckley it was determined that building curl with OpenSSL support and setting LD_LIBRARY_PATH to use the libcurl compiled with OpenSSL fixes the problem. You can find more information in this issue: Azure/iot-edge-v1#62