TLS failed to start the connection process. about iot-hub-c-m0wifi-getstartedkit

[GregTerrell]

I don't believe MQTT is a supported option for the Arduino and FeatherM0. Http only, there is commitment to MQTT going forward based on an issue posted in the azure-iot-arduino repo (see link below).

Azure/azure-iot-arduino#26

[tebones]

Thanks for reply :)

Then I guess this should be updated in the code or the guide for this starter-pack. Because I followed the guide several times and ended up with the error above.

[mamokarz]

Hi tebones,
Microsoft has just added MQTT for Arduino. You are probably running in a issue with your Connection Key. Please double check if all configurations there are correct, mainly if you are not providing the MometoloTv3 twice.

[tebones]

Hi mamokarz, changed my code to use http and it worked, but stops again after about 3 hours.

Motivated with my luck I went ahead with your second example making really sure all my keys are ok. Node is up, all azure devices is up, even my feather is online but I end up with the same error as the previous example: "TLS failed to start the connection process". There must be something wrong somewhere :)

Pls advice :) I need to get this working for a showcase on IoT for my co-workers ;)

[jorupp]

I too was unable to get things working with MQTT due to this connection error. Gave the HTTP example a try, and it worked.

I can't seem to get Wireshark to read my traffic today so I can't be sure, but any chance that this device doesn't support TLS 1.2 and the Azure IoT HTTP endpoint is allowing an older TLS version, but the MQTT endpoint isn't? MQTT works fine from C#, just not from this Arduino Feather M0.

[mamokarz]

Can you please activate the MQTT logs, localize IoTHubClient_LL_CreateFromConnectionString on remote_monitoring.c, and add the traceOn option after that, as follow.

#if defined(IOT_CONFIG_MQTT)
iotHubClientHandle = IoTHubClient_LL_CreateFromConnectionString(IOT_CONFIG_CONNECTION_STRING, MQTT_Protocol);
#elif defined(IOT_CONFIG_HTTP)
iotHubClientHandle = IoTHubClient_LL_CreateFromConnectionString(IOT_CONFIG_CONNECTION_STRING, HTTP_Protocol);
#else
iotHubClientHandle = NULL;
#endif            

bool traceOn = true;
IoTHubClient_LL_SetOption(iotHubClientHandle, "logtrace", &traceOn);

[jorupp]

Added that, but didn't result in any more logging. I'm guessing that's because the connection is what's failing - it's not a MQTT protocol error - it's the raw TLS connection setup that's failing. Ie. where adapters/sslClient_arduino.c calls the underlying sslClient.connect, it's getting back a 'false' (0), leading to the failure.

To help debug, I've tried using the WiFiSSLClient example to connect to my *.azure-devices.net hostname. When I connect on 443, I get a successful connection. When I connect to 8883 (the port my C# MQTT example connects to), I don't get a successful connection (Adafruit_WINC1500SSLClient.connect returns false).

[jorupp]

Routing my traffic through my desktop so I can sniff it in Wireshark, I see a difference in how the connection setup process goes on 443 vs. 8883.

Here's what the port 443 connection looks like:
C->S: Client Hello
S->C: Server Hello, Certificate, Certificate Request, Server Hello Done
C->S: Client Key Exchange, Change Cipher Spec, Hello Request, Hello Request
S->C: Change Cipher Spec, Hello Request, Hello Request
encrypted data
(ie. successful connection - data flows)

And here's the port 8883 connection (same for first 3 parts):
C->S: Client Hello
S->C: Server Hello, Certificate, Certificate Request, Server Hello Done
C->S: Client Key Exchange, Change Cipher Spec, Hello Request, Hello Request
S->C: [TCP ACK]
no data for 15 seconds
C->S: [TCP FIN, ACK]
(ie. connect timeout, client disconnects)

Shouldn't the TLS handshake process work the same on both ports?

And to add more fun, here's what the port 8883 conversation looks like from my .Net test app:
C->S: Client Hello
S->C: Server Hello, Certificate, Certificate Request, Server Hello Done
C->S: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
S->C: Change Cipher Spec, Encrypted Handshake Message
encrypted data
(ie. successful connection - data flows)

Of possible interest, both of the connections from the Arduino use cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c), while the one from .Net uses TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028).

[mamokarz]

I’m wondering if we are running in some contamination problem. Sometimes, the Arduino IDE do not recognize changes in the library and just reuse parts of the previous compilation. To avoid it, can you please totally delete the previous result? It is located in a temporary directory with the name arduino_build_#####

C:\Users\ <<userName>> \AppData\Local\Temp\arduino_build_####

You will find simplesample_mqtt.ino.bin inside of it. Delete all files and directories inside of this arduino_build_#### directory. Recompile the code and check if this directory was populated again.

[jorupp]

Still not getting any debug output :( Doesn't really surprise me though, as all that output comes after the connection happens. The underlying SSL/TLS connection isn't getting established - that's the issue.

[jorupp]

And @mamokarz - re: the address you suggested on the other thread - I can't get a TLS connection to MokaFeatherM0Suite.azure-devices.net:8883 either, but :443 works just fine (same thing I'm experiencing on the IoT hub I'm testing with). It's got to be something with the details of how the TLS security handshake is working between the Feather M0 w/ WINC1500 and the MQTT-SSL endpoint of the IoT Hub.

[mamokarz]

I'm investigating.

[Eskibear]

Hi, at my first glance I know I have exactly the same problem with @jorupp , and it's definitely a problem of the TLS connection establishment.

For M0 trying to establish TLS connection via port 8883, it's all the way good UNTIL here:

// File: Adafruit_WINC1500Client.cpp
int Adafruit_WINC1500Client::connect(IPAddress ip, uint16_t port, uint8_t opt, const uint8_t *hostname)
{
        .....
	// Connect to remote host:
	if (connectSocket(_socket, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) < 0) {
		close(_socket);
		_socket = -1;
		return 0;
	}
----->// Wait for connection or timeout:
	unsigned long start = millis();
	while (!IS_CONNECTED && millis() - start < 20000) {
		m2m_wifi_handle_events(NULL);
	}
	if (!IS_CONNECTED) {
		close(_socket);
		_socket = -1;
		return 0;
	}

	return 1;
}

And it finally leads to a SOCK_ERR_CONN_ABORTED.
And following is part of tcpdump log for M0 to connect 8883:

......
C->S: TLSv1.2	Client Key Exchange, Change Cipher Spec, Hello Request, Hello Request
S->C: TCP 8883→52174 [ACK] Seq=3185 Ack=393 Win=64752 Len=0
C->S: TCP 52174→8883 [FIN, ACK] Seq=393 Ack=3185 Win=4338 Len=0
......

My tests

• [FAIL] M0 using MQTT_Protocol with port 8883
• [ok] M0 using HTTP_Protocol with port 443
• [ok] Mock Device (azure-iot-sdk-c in Visual Studio) using MQTT_Protocol with port 8883
• [ok] Mock Device (azure-iot-sdk-node) using MQTT_Protocol with port 8883

Following are my Arduino related specs, FYI.

Board

• Adafruit feather M0

AzureIoT Libraries

• AzureIoTHub v1.0.21
• AzureIoTProtocol_HTTP v1.0.21
• AzureIoTProtocol_MQTT v1.0.21
• AzureIoTUtility v1.0.21

WiFi Library

Both Adafruit_WINC1500 and WiFi101 are tested, same results.

@mamokarz So is there any positive news? If needed I can provide my source code and connection string.
Thanks.

[haku15]

I also have the same problem: HTTP is working, but MQTT isn't.
Same errors messages as posted above.
Library versions:

• AzureIoTHub v1.0.21
• AzureIoTProtocol_HTTP v1.0.21
• AzureIoTProtocol_MQTT v1.0.21
• AzureIoTUtility v1.0.21
• Adafruit_WINC1500 v0.8.1
• WiFi101 v0.12.1

[gmhewett]

@mamokarz Just wanted to check in on this issue. I am also experiencing the same problems with the same libraries as others in this thread. Any outlook on a possible solution? Thanks

[snobu]

Same here. And now with the Direct Methods feature only working over MQTT, protocol isn't much of a choice anymore.

I've always used Adafruit_WINC1500SSLClient sslClient in ATWINC1500 projects to connect to various endpoints over TLS 1.2, 443/TCP or arbitrary ports, this always seems to work. I'm assuming there's a bit more complexity involved in the case of this MQTT sample. If we can help here with testing stuff out, i'd be glad to do it.

@ IoT Hub product group folks, is this MQTT sample working for you on ATWINC1500?

[Eskibear]

@snobu It seems to be firmware issue, look at the related issue here

[Eskibear]

Solved by this new firmware

[BertKleewein]

I've also verified this. I couldn't use MQTT with the 19.4.4 firmware and it worked with the 19.5.2 firmware.

[berkaysit]

After one year I faced the same problem; Firmware update and uploading personal Azure IoT hub address' certificate (<name>.azure-devices.net) into the WiFi module exactly solved it. Thank you very much.

[mysaggar]

Hi @berkaysit could you elaborate a bit more and provide all the library versions and the chip used by you,
I have access to The NodeMCU and Adafruit Feather HUZZAH chipset both based on the esp8266.
The error I am receiving is

connected with Moriarty, channel 11
dhcp client start...
ip:192.168.43.126,mask:255.255.255.0,gw:192.168.43.1
Connected to wifi Moriarty.
Fetched NTP epoch time is: 28812.
result = IOTHUB_CLIENT_OK
Sending message: {"deviceId":"Feather HUZZAH ESP8266 WiFi","messageId":1,"temperature":28,"humidity":36}.
IoTHubClient accepted the message for delivery.
TLS failed to start the connection process.
Error: io_open failed
failure connecting to address iotpra2.azure-devices.net.
TLS failed to start the connection process.
Error: io_open failed
failure connecting to address iotpra2.azure-devices.net.
TLS failed to start the connection process.
Error: io_open failed
failure connecting to address iotpra2.azure-devices.net.
TLS failed to start the connection process.
Error: io_open failed
failure connecting to address iotpra2.azure-devices.net.

[berkaysit]

Hi @mysaggar I was using Arduino MKR1000. I have made the firmware update by original Arduino IDE desktop software. Since over a year has passed, I can't check the library versions. Maybe you should use https or http prefix at your adress.

[mysaggar]

Is There any workaround for Adafruit Feather HUZZAH ESP8266 board? Or you received this error right?, so what firmware update did you install ?
Also I didn't get the last part of using the https/http prefice at my address.
The new firmware is only for the MKR1000 i.e. the ATMEL wifi chip