I am working with the Evaluation kit for CYW43907. When I can expect to buy the chipsets to build my own solution? Additionally, if I can be put it in touch with a sales or support engineering (Seattle area) that would be really helpful.

Thanks,

Vamsi

Hi everyone,

WICED 4.1.0 cannot connect to Azure IoT Hub over TLS-based MQTT connection due to WICED's inability to establish a TLS channel.

Direct connection has never worked for us since our product was based on WICED 3.5.2. That's why we have spinned off TLS proxies (NGINX), while waiting for a fix. However, it seems that neither 4.1.0 is solving the issue, so here is some investigation that may help you with debugging.

We took Wireshark traces for the following scenarios:

1) Connected MQTT.fx app directly to Azure IoT Hub (OK)

2) Connected WICED's secure_mqtt app directly to Azure IoT Hub (Not OK)

3) Connected WICED's secure_mqtt app through NGINX proxy (OK)

After looking into the wireshark traces, we could see that there is a one major difference between our NGINX proxies and Azure IoT Hub. Along with the "Server Hello" message, Azure IoT Hub is also sending "Client Certificate Request" to the client specifying that a client cert is requested.

However, the MQTT authentication in Azure IoT Hub is not based client certificates, but rather on credentials. In such a case, the client is not expected to send any cert. This is where the trace from MQTT.fx are useful. What that app did to deal with this issue was to simply answer, with no certificates. In fact, according to RFC5246:

If no suitable certificate is available, the client MUST send a certificate message containing no certificates.

Unfortunately, WICED's approach is a bit different. What we observed was that the app got stuck in a call to function ssl_handshake_client_async() while processing state SSL_CLIENT_CERTIFICATE. Eventually the app crashed due to a simple watchdog, as bdide_1722426 described in this unanswered question.

Sadly, I cannot dive deeper and understand why ssl_handshare_client_async fails. This is where I need some help. In order to provide some proof, below you can find attached the .pcapng files containing the traces of the aforementioned scenarios.

I am really looking forward to a reply from some representative of Cypress. This has been a big issue for a long time.

Thanks in advance,

Stavros.

Hi,

I manage to get "access token" through "avs_authorization" in SDK 5.2.

However for the next step, I need "refresh token".

Using  redirection form which is "main.html" in the SDK ,seems only generating access token.

The following picture is the access token I got through the redirection form in the SDK but there is no information about

"refresh token" in this form.

Does anyone know how to get refresh token?

Thanks,

Soohwan.

Are there any available measurements on reference boards with maximum power save options enabled for this ? I'm basically trying to figure out what is the best achievable low power current draw, while still maintaining a connection to the server.

I've read AN104, it mentions 'sleep mode may be 10's of microamps or less' and then in chapter 4.2.4 concludes with 'minimum sleep current is approx 500 microamps'. This is not measured with TCP connection however, and that's a fairly wide swing as well. Anything better defined on any specific reference boards would be welcome. CYW4343W measurements would be ideal, but anything else running Wiced would be fine, too.

Also, CYW4343W mentions support for 'power-save multipoll', where can i read more about how is that exposed or implemented in the chip ?