cloud_send fail AWS_IOT with nRF9160

RE: cloud_send fail AWS_IOT with nRF9160

Farhang — Thu, 28 Jan 2021 22:43:29 GMT

Ukhan I did resolve all my issues. Can you confirm you've followed this guide to create a thing in IoT core, Activate the certificate and ensure policy is attached to the thing.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/aws_fota/README.html#creating-a-thing-in-aws-iot

If all of the above is correct and you have internet connection on your modem, you should get the MQTT_EVT_CONNACK event.

You can enable debug level logging by replacing

CONFIG_CLOUD_CLIENT_LOG_LEVEL_INF=y

with

CONFIG_CLOUD_CLIENT_LOG_LEVEL_DBG=y

in your cloud_client/prj.conf.

I added debug logs to every case in subsys/net/lib/aws_iot/src/aws_iot.c

switch (mqtt_evt->type)

so I know what's going on.

Also your error shows an error to do with the shadow name. AWS recently added the notion of "unnamed" and "named" shadows and they have different Topics so you may want to read abou that. I also found aws_iot.c of NCS includes a full "Client ID" whereas AWS only asks for a shadow with "thing name", the format of the topic is as follows:

$aws/things/thingName/shadow

So i ended up changing the sprintf() where cliend_id_buf is populated so it can build the topic strings, so that it doens't use CONFIG_AWS_IOT_CLIENT_ID_STATIC but uses a new config I added

CONFIG_AWS_IOT_THING_NAME that reflects only the ThingName not the full client_ID or what AWS calls Amazon Resource Name

Heidi do you have any comments on this discrepancy between Device shadow MQTT topic format that AWS requires and what is specified in aws_iot.c of NCS?

RE: cloud_send fail AWS_IOT with nRF9160

Ukhan — Thu, 21 Jan 2021 01:36:12 GMT

Hi Farhang,

Could you resolve the issue? If yes can you please share how?

I have tried with 1nce and iBasis sims and am stuck at the same point.

On port 8333, MQTTEVT reports -128 i.e "Socket is not connected".
I tried a different port (443), it doesn't return an error, but the connection isn't stable yet.

In AWS cloudwatch logs I can see this:

RE: cloud_send fail AWS_IOT with nRF9160

Farhang — Tue, 07 Apr 2020 05:51:25 GMT

OK the POLLHUP error was fixed by using an alternate port, 8443 or 443 both work with the SIM Card I have, 8883 which is the default setting of NCS sample cloud_client, results in an immediate hang up.

https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-rest-api.html

From:

https://aws.amazon.com/about-aws/whats-new/2018/02/aws-iot-core-now-supports-mqtt-connections-with-certificate-based-client-authentication-on-port-443/

"Corporate firewalls and home routers often block inbound and outbound traffic on all ports except port 443 by default, which is the standard port for HTTPS (i.e. internet) traffic. This is done as a security measure to limit the attack surface for possible cyber attacks."

Not sure why 8883 is blocked, perhaps my SIM MNO/MVNO is blocking traffic on 8883.

Also as Heidi pointed out, certs should be programmed as follows:

"You need the thing certificate (*-certificate.pem.crt), the private key (*.private.pem.key), and the root CA (choose the Amazon Root CA 1, AmazonRootCA1.pem)."

The Thing certificate is the client certificate and the root CA is the CA certificate.

I am now able to connect reliably to AWS IoT, however publishing the sample message (i.e. btn1 trigger), causes the following error:

cloud_send failed, error: -128

Will update this post when I find the solution.

RE: cloud_send fail AWS_IOT with nRF9160

Heidi — Mon, 06 Apr 2020 11:56:20 GMT

Hi!

[quote user="farhangj"]The other thing I'm wondering about is whether or not i have to remove footer and header from.private key/certs before copy pasting into Link monitor-> cert manager?[/quote]

No, keep the header and footer when copy-pasting.

I just tested with the JSON file that nRF Connect for Cloud generates for you, by dragging and dropping it into the Certificates Manager and the header and footer are included.

RE: cloud_send fail AWS_IOT with nRF9160

Farhang — Fri, 03 Apr 2020 17:00:52 GMT

I sent you the requested traces in a DM. Let me know if there are any missing peices. Thank you!

RE: cloud_send fail AWS_IOT with nRF9160

Heidi — Thu, 02 Apr 2020 08:20:22 GMT

Hi! I'm glad you were able to connect.

[quote user="farhangj"]RE your comment about Kconfig, i have checked out the latest commit on the dev branch of NCS and things my be different than the latest release. AWS_IOT_SEC_TAG is definitely in Kconfig not prj.conf now, and so are so many other settings the documentation calls for.[/quote]

Yes, configurations are always defined in the Kconfig files, but it is the convention that when setting or changing them from their default value you add them to the prj.conf file of your application like this, for example:

AWS_IOT_SEC_TAG=45

The reason to do it like that is so you can have different values for this config for different applications using it.

If you're getting POLLHUP, could you take a modem trace for me so I can take a closer look? This tutorial shows you how to take a modem trace. And remember to include the log output from when you took the trace.

Best regards,

Heidi

RE: cloud_send fail AWS_IOT with nRF9160

Farhang — Thu, 02 Apr 2020 08:13:36 GMT

The other thing I'm wondering about is whether or not i have to remove footer and header from.private key/certs before copy pasting into Link monitor-> cert manager?

It did not complain when i copy pasted entire contents of each file into each corresponding field and updated my modem.

If the cert manager is not meant to work with an entire cert/key file contents and just the body, it will mess things up.

Thoughts?

RE: cloud_send fail AWS_IOT with nRF9160

Farhang — Thu, 02 Apr 2020 07:43:25 GMT

Heidi,

This was extremely helpful thank you. I am now one step closer to getting some data into AWS.

The error was in cert programming, I was not using AmazonCA1. So thanks for clarifying that.

Now my device does connect to AWS IoT server, ping is OK, however in the cloud_client app after connect and ping, the polls flags are checked. No incoming data (i wasn't expecting any either) but the POLLHUP flag is set. I changed the code to try and connect again if POLLHUP was set. it does that for a couple of times until it hangs at mqtt_connect and doesn't return.

From AWS IoT Core Monitor i can tell my device successfully connected.

Perhaps the problem now is that my device is connecting but there's no outgoing data so AWS hangs up? Or do you think it could still be authentication related?

I wish there was a more comprehensive demo/tutorial on this cloud_client with AWS IOT. All I want to do is to demo that i can get some data from nRF160 into amazon.. a table or dynamoDB.

Tomorrow i will focus on creating the DynamoDB and creating a rule so MQTT messages with a known topic are routed to the DB. And will change the example message to something with a proper topic.

RE your comment about Kconfig, i have checked out the latest commit on the dev branch of NCS and things my be different than the latest release. AWS_IOT_SEC_TAG is definitely in Kconfig not prj.conf now, and so are so many other settings the documentation calls for.

I am writing this past midnight and from my phone. Forgot to respond earlier.. so sorry about the scattered thoughts, I will be more precise in my next response.

RE: cloud_send fail AWS_IOT with nRF9160

Heidi — Wed, 01 Apr 2020 11:08:12 GMT

Hi!

So when looking up error codes from NCS, you need to know if the sample is using Newlib or not, which you can see from the prj.conf file. The Cloud Client sample that you are using, uses Newlib, because the NEWLIB_LIBC configuration is enabled here.

When this is the case, you need to refer to the newlib error codes found here.

This is different from the default minimal C implementation which uses error codes found here.

The error file you referred to (nrf_errno.h) is used directly by bsdlib but is then translated to one of the two files I linked to above when returned from the application. So only refer to the nrf_errno.h file if you're debugging and seeing returning error codes from directly inside bsdlib.

When that's said, it looks like cloud_send is returning ENOTCONN 128 /*Socket is not connected*/, mqtt_connect is returning ETIMEDOUT 116 */Connection timed out*/ and cloud_connect is returning ECHILD 10 */No children*/.

I think you are correct in your analysis that the problem is your credentials when trying to connect to AWS.

[quote user=""][/quote]

Also I changed the AWS_IOT_BROKER_HOST_NAME to something like:

xyzabcefgblah-xxx.iot.us-west-2.amazonaws.com

"1. In the AWS IoT console, navigate to IoT core -> Manage -> things and click on the entry for the thing, created during the steps of Creating a thing in AWS IoT.
2. Navigate to interact, find the Rest API Endpoint and set the configurable option CONFIG_AWS_IOT_BROKER_HOST_NAME to this address."

Is that address the Rest API Endpoint?

[quote user=""]I gave that a random security tag number and I changed the aws_io/KConfig to reflect the AWS_IOT_SEC_TAG.[/quote]

Not sure what you meant by this. You don't have to change anything in the KConfig file located in \ncs\nrf\subsys\net\lib\aws_iot\KConfig. Set the AWS_IOT_SEC_TAG in the prj.conf file of the application you are running and remember to use the same number when flashing the certificates to the modem via LTE Link Monitor. Just make sure not to use the same security tag as the nRF Cloud certificates use: 16842753.

Have you seen this documentation on how to create a thing in AWS IoT? Step 9 describes which certificate you need for which category.

"You need the thing certificate (*-certificate.pem.crt), the private key (*.private.pem.key), and the root CA (choose the Amazon Root CA 1, AmazonRootCA1.pem)."

The Thing certificate is the client certificate and the root CA is the CA certificate.

[quote user=""]Also changed AWS_IOT_CLIENT_ID_STATIC to the name I gave my "thing" on AWS IOT CORE.[/quote]

See this documentation, specifically, step 3 where it asks you to set the AWS_IOT_CLIENTID_STATIC config to the name of the thing you created in the AWS IoT Console.

Sorry about the messy format. I hope I answered all of your questions. Let me know if this works for you!

Best regards,

Heidi