samples/net/aws_iot sample strange behavior using nRF9160

RE: samples/net/aws_iot sample strange behavior using nRF9160

soutys — Mon, 06 Jan 2025 15:37:36 GMT

Anyway, the problem has been solved by changing the value of `MQTT_HELPER_PAYLOAD_BUFFER_LEN` to 4096. It was just misleading that `NRF_MODEM_LIB` sets it to 2048 by default.

Thanks for help!

RE: samples/net/aws_iot sample strange behavior using nRF9160

Hakon — Mon, 06 Jan 2025 15:14:09 GMT

[quote user="soutys"]That's why I don't understand the connection between this Kconfig option and the modem's TLS buffer size.[/quote]

Ok, I assume the default value is set because of the TLS buffer limit when using modem TLS stack. I don't think changing to offloaded sockets does anything to the default value of this config.

RE: samples/net/aws_iot sample strange behavior using nRF9160

soutys — Tue, 31 Dec 2024 09:14:09 GMT

But the application uses offloaded sockets (e.g. we're uploading certs to the modem using nrfcredstore). The MQTT_HELPER_PAYLOAD_BUFFER_LEN increases the buffer on the application (cpu) side. This has resolved our problems regarding incoming messages' size. That's why I don't understand the connection between this Kconfig option and the modem's TLS buffer size.

RE: samples/net/aws_iot sample strange behavior using nRF9160

Hakon — Wed, 18 Dec 2024 12:22:21 GMT

[quote user="soutys"]The question is - why the default value is set to 2048 if NRF_MODEM_LIB is set, and why not 4096 then?[/quote]

For TLS, the modem limit is 2KB. But using mbedTLS stack instead will increase the available buffer size.

RE: samples/net/aws_iot sample strange behavior using nRF9160

soutys — Thu, 12 Dec 2024 12:59:45 GMT

Okay, turns out, even though MQTT_HELPER_PAYLOAD_BUFFER_LEN default value is 2048 if NRF_MODEM_LIB, it is still configurable. So setting it to 4096 solved my problems (I think). The question is - why the default value is set to 2048 if NRF_MODEM_LIB is set, and why not 4096 then?

RE: samples/net/aws_iot sample strange behavior using nRF9160

soutys — Thu, 12 Dec 2024 11:22:02 GMT

Trying to reproduce it on a nrf9160 DK board, I've created a new device with the default Classic Shadow. To my surprise, after flashing the app with the proper certificates, it worked. Wireshark also showed no problems with the connection. I've decided to run modem trace on my custom board and I saw a lot of "Encrypted Alert" messages (followed by TCP's RST messages). Unfortunately they couldn't be decrypted because of using the ECDH key exchange.

Then I've tried to connect my custom device to AWS using certs and device name of the nrf9160 DK I've created earlier. To my another surprise - it also worked well. After very long investigation I've discovered that the shadow length is "my enemy" (my shadows have a lot of values, so they're kinda long). I've decided to remove Classic Shadow and add it once again - after that a new error logs appeared. Using offloaded sockets on nrf9160, we have a 2048 B buffer available. BUT the messages sent by the server (topic: $aws/things/<thing_name>/shadow/get/accepted) were too long for the device (ERR: mgtt_helper: Incoming MQTT message too long for payload buffer). Turns out the incoming messages were > 2100 B long (they were containing also the metadata with timestamps...), so they were dropped and the device were continuously disconnecting and connecting again.

So - the reason of such behavior is not large enough buffer of nrf91 modem (2kB). Is there a way to increase this value (on the ncs/zephyr side), so the device concatenate bigger messages and successfully decrypts them? One of the solutions is to remove sending "metadata" on "get/accepted" topics (configured by AWS IoT rules) so the messages are shrank from >2KB to ~700B. But what if "someone" wants to use the received metadata? Is there a possibility to receive bigger messages?

Thanks in advance!

RE: samples/net/aws_iot sample strange behavior using nRF9160

Hakon — Thu, 05 Dec 2024 11:36:31 GMT

Do you have a DK available? Perhaps you can try reproducing it on a DK, write the certificates and do all the step again to make sure it reproduces. Also you can try to capture modem trace to see if it will show anything.

RE: samples/net/aws_iot sample strange behavior using nRF9160

soutys — Mon, 02 Dec 2024 11:29:05 GMT

Yes, we have proper policies to publish etc. In fact, I've ensured this by adding a new policy that "allows everything on everything" in case my previous policies were invalid. Still no change.

RE: samples/net/aws_iot sample strange behavior using nRF9160

Hakon — Mon, 02 Dec 2024 10:25:57 GMT

How is the MQTT endpoint set up? Do you have permission to publish? Are there any policies?

RE: samples/net/aws_iot sample strange behavior using nRF9160

soutys — Sun, 01 Dec 2024 14:30:10 GMT

Nothing, actually. We're just reading the shadow data, no jobs or commands are being used.

RE: samples/net/aws_iot sample strange behavior using nRF9160

Hakon — Fri, 29 Nov 2024 11:58:17 GMT

Hello,

can you provide more details on what you are doing on the AWS side?