Iot Hub connection string not working in azure-iot-sdk-c samples

2.3k Views Asked by At

I am working in a raspberry pi 3, raspbian OS, and I am using the azure-iot-sdk-c

I followed the github instructions in here: https://github.com/Azure/azure-iot-sdk-c, I downloaded and correctly built all the samples in the iothub_client/samples folder

The error is, when I put the connection string in the iothub_client_sample_http.c

Here:

static const char* connectionString = "[device connection string]";

and run it, I get many errors like this:

Error: Time:Mon Dec 19 14:23:36 2016 File:/home/pi/Desktop/azure-iot-sdk-c/c-utility/adapters/httpapi_curl.c Func:HTTPAPI_ExecuteRequest Line:576 Failure in HTTP communication: server reply code is 401 Info: HTTP Response:{"Message":"ErrorCode:IotHubUnauthorizedAccess;Unauthorized","ExceptionMessage":"Tracking ID:13262df6828d469e9b29e2176a86fad3-G:9-TimeStamp:12/19/2016 22:23:37"} Error: Time:Mon Dec 19 14:23:36 2016 File:/home/pi/Desktop/azure-iot-sdk-c/iothub_client/src/iothubtransporthttp.c Func:DoEvent Line:1626 unexpected HTTP status code (401)

This is my conection structure:

static const char* connectionString = "HostName=<myiothub>;DeviceId=<mydevice>;SharedAccessKey=<myaccesskey>";

Why is it giving me a 401 if I am directly using the strings provided from the azure portal?

I have tried every connection string (hubowner, service & device) and still gives me 401 :C

1

There are 1 best solutions below

0
On BEST ANSWER

I generated and used a SAS key as connection string and it all worked fine.

static const char* connectionString ="HostName=<myiothub>;CredentialType=SharedAccessSignature;DeviceId=<mydevice>;SharedAccessSignature=SharedAccessSignature sr=<iothub>&sig=<saskey>&se=<time>&skn=device" 

I generated the SAS from a prebuilt version of Device explorer

This worked because, as explained in Control access to IoT Hub:

The only way that IoT Hub authenticates a specific device is using the device identity symmetric key. In cases when a shared access policy is used to access device functionality, the solution must consider the component issuing the security token as a trusted subcomponent.