Hi,
i’m running the AWS IDT MQTT cases, it always failed as AWS cloud respond an alert message[1:0], mbedtls_ssl_handle_message_type() returned -30848 (-0x7880).
@aggarg thanks for your reply.
i have enabled the mqtt log:
991 13497 [RunTests_task] [DEBUG] Client ID for MQTT for MQTT connection={idt-6737131878841795756}
994 13507 [RunTests_task] [DEBUG] Encoded size for length 99 is 1 bytes.
995 13510 [RunTests_task] [DEBUG] CONNECT packet remaining length=99 and packet size=101.
996 13514 [RunTests_task] [DEBUG] CONNECT packet size is 101 and remaining length is 99.
997 13518 [RunTests_task] [DEBUG] Encoded size for length 99 is 1 bytes.
998 13521 [RunTests_task] [DEBUG] Length of serialized CONNECT packet is 101.
1037 13693 [RunTests_task] [DEBUG] BytesSent=101, BytesRemaining=0
1038 13696 [RunTests_task] [DEBUG] Successfully sent packet at time 27386.
1039 13699 [RunTests_task] [DEBUG] Sent 101 bytes of CONNECT packet.
i found cliend had sent the “Hello world” with test topic to server. While when receving the response, serve gracefully close the connection, so client get the alert message.
Which policy do you specify ? I used the IDT, I think the tester framework will automatically creat the resouce for testing, right ? i see the log when the test is starting:
Are these the complete logs you get or are there more? This seems like you are not getting the CONNACK - can you try increasing the time you wait for CONNACK?
@aggarg yes, it’s complete logs for mqtt . it didn’t recive the CONNAK, you can see the my first log, the ssl just receive the alert message immediately .
i double the CONNACK_RECV_TIMEOUT_MS, it reported same error. i think there is nothing about the timeout. the tls can receive the close notify message soon. Do you know the scenario when AWS IOT will send close notify message? How to debug in server side?
@aggarg , in a summary, i found client can establish with AWS IOT endpoint via TLS, i can see the handshake procedure finishes successfully, but once client send any data to server, server will close the connection.
That strongly indicates some issue with your certificate (or attached policy). How did you create your device certificate? Lets first test that certificate in isolation to narrow down the problem. You can use mosquitto client for that:
@aggarg the device certificate/policy is auto-created by IDT when running the cases. you can see the related logs:
time=“2021-10-15T17:33:54+08:00” level=info msg=“Setting client credentials …”
time=“2021-10-15T17:33:54+08:00” level=info msg=“Setting ‘idt-4135510899960087841’ as thing name …”
time=“2021-10-15T17:33:54+08:00” level=info msg=“Setting iot endpoint …”
time=“2021-10-15T17:33:54+08:00” level=info msg="Test setup finished "
And I can see the random thing-name “idt-4135510899960087841” in the AWS IOT web page. i check the corresponding policy, it allow all action and * resouse.
My understanding is that because i’m running the cases under IOT Device Tester, so the device certificate and private key is auto-created by the IDT and updated in aws_clientcredential_keys.h(keyCLIENT_CERTIFICATE_PEM/keyCLIENT_PRIVATE_KEY_PEM)
And meanwhile when running the cases, i check the policy attached with the thing in the AWS IOT web page, the policy allow “" for action "iot:”, so i can’t find any problem with the certificate and policy. You can correct me if my understanding is wrong.
You are absolutely right. Looking at your logs, it seems that the SSL handshake is successful but the MQTT connection is not which seems strange given the fact that IDT is creating cert and policy. Is possible for you to capture network traffic? Also share your complete IDT config?
i’m running the IDT to qualify my own company private chip. I think it should there is nothing with the hardware because this is the problem on the application.
The issue happen again. And the we find the root cause from the error log：“Could not initialize PKCS #11. Failed to seed the DRBG” .
The root cause is we call the vDevModeKeyProvisioning() later than the SYSTEM_Init(), so some resource is not ready when we use it. @aggarg i update here