FleetProvisioningSample预调配生成证书没有响应 #375
Answered
by
TwistedTwigleg
ArvinSpace
asked this question in
Q&A
-
我用的官方示例FleetProvisioningSample预置设备但是我通过IotIdentityClient#PublishCreateKeysAndCertificate发出生成证书的请求($aws/certificates/create/json)之后没有成功的响应($aws/certificates/create/json/accepted)也没有拒绝的响应($aws/certificates/create/json/rejected)启动参数：
|
Beta Was this translation helpful? Give feedback.
Answered by
TwistedTwigleg
Feb 24, 2023
Replies: 2 comments 10 replies
-
|
Hi ArvinSpace, Looking at the logs and the information provided, my guess is that the sample is trying to connect and access a resource that it is not authenticated to add, as the disconnect seems to happen right after the connect attempt, according to the logs. Looking at the Fleet-Provisioning sample, I noticed the policy you have provided is missing a few items compared to the one shown in the sample README: {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iot:Publish",
"Resource": [
"arn:aws:iot:region:account:topic/$aws/certificates/create/json",
"arn:aws:iot:region:account:topic/$aws/certificates/create-from-csr/json",
"arn:aws:iot:region:account:topic/$aws/provisioning-templates/templatename/provision/json"
]
},
{
"Effect": "Allow",
"Action": [
"iot:Receive"
],
"Resource": [
"arn:aws:iot:region:account:topic/$aws/certificates/create/json/accepted",
"arn:aws:iot:region:account:topic/$aws/certificates/create/json/rejected",
"arn:aws:iot:region:account:topic/$aws/certificates/create-from-csr/json/accepted",
"arn:aws:iot:region:account:topic/$aws/certificates/create-from-csr/json/rejected",
"arn:aws:iot:region:account:topic/$aws/provisioning-templates/templatename/provision/json/accepted",
"arn:aws:iot:region:account:topic/$aws/provisioning-templates/templatename/provision/json/rejected"
]
},
{
"Effect": "Allow",
"Action": [
"iot:Subscribe"
],
"Resource": [
"arn:aws:iot:region:account:topicfilter/$aws/certificates/create/json/accepted",
"arn:aws:iot:region:account:topicfilter/$aws/certificates/create/json/rejected",
"arn:aws:iot:region:account:topicfilter/$aws/certificates/create-from-csr/json/accepted",
"arn:aws:iot:region:account:topicfilter/$aws/certificates/create-from-csr/json/rejected",
"arn:aws:iot:region:account:topicfilter/$aws/provisioning-templates/templatename/provision/json/accepted",
"arn:aws:iot:region:account:topicfilter/$aws/provisioning-templates/templatename/provision/json/rejected"
]
},
{
"Effect": "Allow",
"Action": "iot:Connect",
"Resource": "arn:aws:iot:region:account:client/test-*"
}
]
}Can you see if adding these additional fields in the above policy to your policy helps fix the issue? If that does not fix the issue, can you try using a fully permissive policy, just to help confirm whether or not policy permissions are causing the issue. A fully permissive policy is not ideal for production use cases, but for testing to determine if the policy is causing issues it can be helpful. A fully permissive policy is shown below: {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot:*"
],
"Resource": "*"
}
]
}Thanks! |
Beta Was this translation helpful? Give feedback.
10 replies
-
|
I just ran a test and was able to run the sample successfully with a fully permissive policy using input similar to the one you provided (I had to pass Initially I was thinking it was a policy issue because the logs seemed to indicate you were not connected, however, upon further inspection, I do not believe this to be the case. The logs contain the following: (trimmed slightly to just show the important parts) As well as indicating it made successful subscribe requires: However, I noticed something additional that I had not missed on my initial reading of the logs. You mention the following (translated to English): Which I thought initially would indicate that the issue is that the connection is timing out (which I have not fully ruled out) but if the issue was the Looking at the exception again, the issue appears to be happening at line Meaning that the issue seems to be something with the TLDR: What I think may be happening is that the JSON being inputted into To this end:
I think that may help resolve the issue, or at least help narrow down what may be causing it. Another thing we could try is to modify line |
Beta Was this translation helpful? Give feedback.
-
|
不好意思，因为之前waitForKeysRequest总共只会等待1.5秒，所以我把这个方法等待总时长改成了2分钟，但是依然没有响应。 还有其他地方的代码也改了一点，主要是加一些打印日志，导致与示例原始代码行数不对应，日志报错信息误导你了，抱歉。 我现在用最原始的示例代码，发现出现的异常堆栈信息如下： 所以据我了解，不是 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the clarification and updated log output! I agree that, in light of this new information, it does not appear currently to be an issue with the parsing of |
Beta Was this translation helpful? Give feedback.
-
|
I've been looking into this further and been trying all sorts of things, but have been largely unsuccessful at recreating the issue. I have tried making a new Fleet Provisioning template following the sample README, trying all sorts of invalid data possibilities, and trying different policy combinations. In all but one case (more below) I would either be able to run the sample successfully without issue or I would get an error (like expected) but it would be properly reported via the The only time I got something similar to what you are seeing in this issue is if I used an IoT Policy attached to the IoT Thing that I pass the If you have a chance, can you provide the following additional information?
Thanks! I am hoping that these questions will help shed light on what is going on so we can get this sample working 🙂 |
Beta Was this translation helpful? Give feedback.
Answer selected by
jmklix
-
|
@ArvinSpace are you still having any problems getting the FleetProvisioningSample working? |
Beta Was this translation helpful? Give feedback.
-
我这边没问题了。 |
Beta Was this translation helpful? Give feedback.
-
|
Hello! Reopening this discussion to make it searchable. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been looking into this further and been trying all sorts of things, but have been largely unsuccessful at recreating the issue. I have tried making a new Fleet Provisioning template following the sample README, trying all sorts of invalid data possibilities, and trying different policy combinations. In all but one case (more below) I would either be able to run the sample successfully without issue or I would get an error (like expected) but it would be properly reported via the
RejectedThingRequestcallback.The only time I got something similar to what you are seeing in this issue is if I used an IoT Policy attached to the IoT Thing that I pass the
--certand--keyto that mirrors …