Azure-Samples / iot-hub-c-m0wifi-getstartedkit

Get started with the Adafruit Feather M0 Wifi Azure IoT Starter Kit
MIT License
5 stars 8 forks source link

TLS failed to start the connection process. #44

Open tebones opened 7 years ago

tebones commented 7 years ago

Hi all, I am new to this and are haveing som issues sending my sensor data to the IoT Azure Hub. I have cheked my setup several times, this is last resort.

In the serial logger I get this statuses:

Attempting

to connect to SSID: Utsikten 17

Connected to wifi Fetched NTP epoch time is: 1481151547 Checking for the presence of the BME280 temp/humid/press module. Found and initialized BME280 module. Info: IoT Hub SDK for C, version 1.0.17 Info: deviceId=FeatherWifi Info: IoTHubClient accepted the message for delivery

Error: Time:Wed Dec 7 22:59:27 2016 File:C:\Users\Trond Erik Mometo\Documents\Arduino\libraries\AzureIoTUtility\src\adapters\tlsio_arduino.c Func:tlsio_arduino_open Line:264 TLS failed to start the connection process. Error: Time:Wed Dec 7 22:59:27 2016 File:C:\Users\Trond Erik Mometo\Documents\Arduino\libraries\AzureIoTProtocol_MQTT\src\azure_umqtt_c\mqtt_client.c Func:mqtt_client_connect Line:884 Error: io_open failed Error: Time:Wed Dec 7 22:59:27 2016 File:C:\Users\Trond Erik Mometo\Documents\Arduino\libraries\AzureIoTHub\src\sdk\iothubtransport_mqtt_common.c Func:SendMqttConnectMsg Line:1554 failure connecting to address MometoIoTv3.azure-devices.net:0. Info: Evaluated delay 0 at 1 attempt to retry

Any help leading me in the right direction would be appreciated :)

Looking at the address the port definition ":0" looks somewhat strange to a newbee like me?

Best regards Trond Erik

GregTerrell commented 7 years ago

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).

https://github.com/Azure/azure-iot-arduino/issues/26

tebones commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 arduinobuild#####

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 arduinobuild#### directory. Recompile the code and check if this directory was populated again.

jorupp commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

I'm investigating.

Eskibear commented 7 years ago

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

Following are my Arduino related specs, FYI.

Board

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

haku15 commented 7 years ago

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

gmhewett commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

Eskibear commented 7 years ago

Solved by this new firmware

BertKleewein commented 7 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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