- Mais recentes
- Mais votos
- Mais comentários
Hi CK. I have this particular board. Yes, the WiFi socket connection is being closed unexpectedly. What have you setup in IoT Core? I suspect the issue is probably in the cloud configuration. Is the device certificate registered and activated? Do you have an IoT policy attached to it that permits connection? Could you perhaps share the policy here?
I'm not clear what instructions you're following from the name "Connect to AWS IoT - STM32-B-L475E-IOT01A". Can you please paste the link?
UPDATE: the logs show that a new cert/key is being auto provisioned after 180s. These values will be used in preference to the values configured in aws_clientcredential_keys.h. Therefore the device is attempting connection with a different certificate than the one that has been registered in IoT Core. Hence the failure. I tested the demo on my board - it works fine and does not do the auto provisioning by default. Please check your build settings (as detailed in the comments) and re-build your binary.
Conteúdo relevante
- AWS OFICIALAtualizada há 6 meses
- AWS OFICIALAtualizada há 3 meses
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 7 meses
Hi, Greg_B, Thank you for your comment. I actually followed below. https://ap-northeast-1.console.aws.amazon.com/iot/home?region=ap-northeast-1#/freertos/clone/Connect_to_AWS_IoT_-_STM32-B-L475E-IOT01A/predefined I think my device certificate is ok. I attached very simple policy as below. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:", "Resource": "" } ] } If you need further information, please let me know. Thanking you, CK
Thanks CK. Some asterisks are missing, but I think that might just be a re:Post formatting issue. So I think it's good.
I just noticed the "Waiting for 180 seconds before generating key-pair" line in the log. This indicates developer mode provisioning is enabled (meaning you have
keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR
set to 1). What option did you use? Option 1 or option 2 (or maybe a bit of both)? https://docs.aws.amazon.com/freertos/latest/userguide/dev-mode-key-provisioning.htmlHi, Greg_B, I followed Option 1. I imported private key from AWS IoT and configure aws_clienetcredential_keys.h by CertificateConfigurator. Also, I checked the file: aws_dev_mode_key_provisioning.c, as below. #define keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR 0 I think it remains as default setting, not choosing option 2. I'm not sure why the message indicates as if option 2 is chosen. Pls let me know if any other setting is required. Regards, CK
Hi CK. Please see here: https://github.com/aws/amazon-freertos/blob/747f07402a744ec839ed9950e841142408abd6b0/demos/dev_mode_key_provisioning/src/aws_dev_mode_key_provisioning.c#L1188-L1217 This is why I said what I said. Can you please also check the value of
pkcs11configIMPORT_PRIVATE_KEYS_SUPPORTED
. It should be 1.Based on the logs, the code is also built with
USE_OFFLOAD_SSL
. This means the key and certificate are stored in the WiFi module (via PKCS11). See here: https://github.com/aws/amazon-freertos/blob/747f07402a744ec839ed9950e841142408abd6b0/demos/dev_mode_key_provisioning/src/aws_dev_mode_key_provisioning.c#L1320It should use the key and cert from aws_clientcredential_keys.h when configured. However, automatic provisioning is seemingly occurring after 180s and this overwrites the key and cert in the WiFi module. So they don't match the cert in IoT Core when you try to connect.