OTA2 Issues with AWS Presigned URL

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
spdodd
Level 1
Level 1
5 sign-ins First reply posted First question asked

I am currently working a project that requires OTA functionality.  I am currently at a point where I have increased the sizes of the following buffers to account for the length of presigned URLs:

- WICED_OTA2_HTTP_QUERY_SIZE
- WICED_OTA2_HOST_NAME
- WICED_OTA2_FILE_PATH

Updating via OTA 2 has been tested via a locally hosted web server (non HTTPS) with long (2k) URLs.  This works as intended and ensures that the length itself is not resulting in any issues downloading the image.

The device has been loaded with the Starfield signer used to generate the signing information used in the presigned URLs using wiced_tls_init_root_ca_certificates(starfield_cert) prior to initializing OTA2, which should be significant for verifying the URLs.  However, when attempting to download via a presigned url, I get the following output (private info redacted):

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

0047 00:02:20.488 OTA2: OTA2_EVENT_WORKER_START_DOWNLOAD!
0048 00:02:20.493 wiced_ota2_service_get_the_update() start!
0049 00:02:20.499 wiced_ota2_service_get_the_update() Use the ota2 list count:5!
0050 00:02:20.506 wiced_ota2_service_network_switchto_ota2_ap() already connected to: XXXXXXXX
OTA access point connect success!
0051 00:02:20.517 Connect to: host:XXXXXXXXXXXXX.s3.us-east-2.amazonaws.com path:/OTA2_image_file.bin?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEAEaCXVzLWVhc3QtMiJHMEUCIQCcDTpP%2FgiQLzTjrRDDB5IkgekIXi7oeuWgpNXEpsiqtAIgcoNPiTDJ2weMhjX1eYsGpM9ZpN%2FLRqUCvJMtYz%2BqnbEq3QIIehACGgw2MTY0MTg2NjAwMTMiDOjAPtjf54GP2Krxzyq6Apn64H88uzj%2FaXhrHfYYrzs7VdgN%2F1zj6eEk%2F61p2j0RXtu83VzwNnMQOYA4Wh3JfBrpAqMfLeM3UvgFdSyU8ORikTjWcdL5Jcewa%2Bh0Ekse%2BQcLSPSYYUdNNloHds5Sewxd3Ib1PJW5frXwV1bp0A9%2FLjGlAeS5MMaQAPODeM0cpmKsvefG6Z9CR7pqjFXGyRPMpmROxZqqzq7qB7sile%2BHihl7pMWzJIosEsW4vUyDUpq2dRC3lK%2FB8IaVbhHGJ7Lg0h6ZGJ2olz5RsvNLylxlwyz0qI5JemrkGM02tBkTFYmLzJRRC1zGwW63CQTITQRNSjWhcabgnJglXuGHK%2FHyRZwjpDSBNGFugH3aaQj8WJp1hCGotJ439owjqy3BPTCvWcMV2VDKMvwk32rCvGA9r3KOI71Ti4dxMPTDq4QGOr8BsY2EB7Gi3qQ4NuORTmtjH3wTT5FC1cXr8RvrXRitUjOFA5QxtFkVvb4UVkP3AL3hOSGvVJZOBZQAiyGNrqSMl%2Bw9xcqbq6PKkjBJzMKo3f4sD9tat4JE1JFI6WeG87sX7fbnaExSb9sHvbPxQOJCNNpcU%2Bo%2BR9vkIPtD71RCU4fSdjP10BNezdo0kmMcsqs5KeKiUEbwyHdgFYfaVV95C2xS96xyL339eZn2W004mKAnqoae3fOcav3YJvptkVA%0052 00:02:20.616 Try 0 Connecting to XXXXXXXXXXXXX.s3.us-east-2.amazonaws.com 52.219.97.146 : 443 !
0053 00:02:20.653 Connected to 52.219.97.146 : 443 !
OTA server connect success!
0054 00:02:20.662 Send query for OTA file: [GET /OTA2_image_file.bin?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEAEaCXVzLWVhc3QtMiJHMEUCIQCcDTpP%2FgiQLzTjrRDDB5IkgekIXi7oeuWgpNXEpsiqtAIgcoNPiTDJ2weMhjX1eYsGpM9ZpN%2FLRqUCvJMtYz%2BqnbEq3QIIehACGgw2MTY0MTg2NjAwMTMiDOjAPtjf54GP2Krxzyq6Apn64H88uzj%2FaXhrHfYYrzs7VdgN%2F1zj6eEk%2F61p2j0RXtu83VzwNnMQOYA4Wh3JfBrpAqMfLeM3UvgFdSyU8ORikTjWcdL5Jcewa%2Bh0Ekse%2BQcLSPSYYUdNNloHds5Sewxd3Ib1PJW5frXwV1bp0A9%2FLjGlAeS5MMaQAPODeM0cpmKsvefG6Z9CR7pqjFXGyRPMpmROxZqqzq7qB7sile%2BHihl7pMWzJIosEsW4vUyDUpq2dRC3lK%2FB8IaVbhHGJ7Lg0h6ZGJ2olz5RsvNLylxlwyz0qI5JemrkGM02tBkTFYmLzJRRC1zGwW63CQTITQRNSjWhcabgnJglXuGHK%2FHyRZwjpDSBNGFugH3aaQj8WJp1hCGotJ439owjqy3BPTCvWcMV2VDKMvwk32rCvGA9r3KOI71Ti4dxMPTDq4QGOr8BsY2EB7Gi3qQ4NuORTmtjH3wTT5FC1cXr8RvrXRitUjOFA5QxtFkVvb4UVkP3AL3hOSGvVJZOBZQAiyGNrqSMl%2Bw9xcqbq6PKkjBJzMKo3f4sD9tat4JE1JFI6WeG87sX7fbnaExSb9sHvbPxQOJCNNpcU%2Bo%2BR9vkIPtD71RCU4fSdjP10BNezdo0kmMcsqs5KeKiUEbwyHdgFYfaVV95C2xS96xyL339eZn2W004mKAnqoae3fOcav3YJvptkVA%3D&X-Amz-Algorithm=AWS4-HMAC-SHA2560055 00:02:21.750 ota2_get_OTA_file() wiced_tcp_receive() 2 timeout!
0056 00:02:22.755 ota2_get_OTA_file() wiced_tcp_receive() 2 timeout!
0057 00:02:23.760 ota2_get_OTA_file() wiced_tcp_receive() 2 timeout!
0058 00:02:24.765 ota2_get_OTA_file() wiced_tcp_receive() 2 timeout!
0059 00:02:24.770 ota2_get_OTA() wiced_ota2_write_data() Timed out received:0 of 0!
0060 00:02:24.778
ota2_get_OTA_file() Exiting 2
0061 00:02:24.782 wiced_ota2_service_get_the_update() wiced_ota2_service_wget_update(header) failed!
OTA update error!
0062 00:02:24.821 wiced_ota2_service_get_the_update() ota2_service_connect() failed (list)!
OTA server connect error!
0063 00:02:24.832 wiced_ota2_service_network_switchto_default_ap() already connected to: XXXXXXXX
OTA update complete!
0064 00:02:24.842 OTA2: wiced_ota2_service_get_the_update() FAILED check if timers started!
0065 00:02:24.850 OTA2: wiced_ota2_service_get_the_update() FAILED set flag START_RETRY_TIMER!
OTA update check!

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

It seems to me that verification of the presigned URL is failing at some level, but I am struggling to see where.  This issue holds true with the standard OTA2 example, with the prementioned buffers increased to accommodate the URL in wiced_ota2_service.h .  Wondering if anyone has any ideas here, or any previous experience using AWS presigned URLs on the WICED platform.  Any ideas are greatly apprecieated.

0 Likes
1 Solution
Aditi_B
Moderator
Moderator
Moderator
500 replies posted 5 questions asked 250 replies posted

Hi,

The problem is with the receive first as the timeout is being observed in the logs. Even in the previous response, I see socket being closed

0025 00:03:14.815 ota2_get_OTA_file() wiced_tcp_receive() 7014 socket_closed!

Can you check if you see the same issue with LwIP?

Thanks

Aditi

 

View solution in original post

0 Likes
3 Replies
Aditi_B
Moderator
Moderator
Moderator
500 replies posted 5 questions asked 250 replies posted

Hi,

What's the platform being used in your use case? From the logs, it seems that it's returning a timeout error from this function - wiced_tcp_receive() and the error is being returned from the file "wiced_ota2_service.c" at line 816.

Location: 43xxx_Wi-Fi\libraries\daemons\ota2_service\wiced_ota2_service.c

Here, the timeout macro passed to the function wiced_tcp_receive is "WICED_OTA2_TCP_RECEIVE_TIMEOUT_MS" which is set to 1000 in the same file as above.

You can try increasing this macro and let us know if this solves the issue. Also, which network stack are you using? Is it the default NetX_Duo or LwIP?

Thanks

Aditi

0 Likes
spdodd
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hey Aditi,

Thank you for the response.  This is using the default NetX_Duo lib as opposed to LwIP.  

Increasing the timeout up to 10000ms or so still results in a timeout, but out of curiosity I pushed it all the way up to one minute and get the following output:
----------------------------------------------------------------------------------------------------------------------------------------------------
0017 00:02:16.688 Send query for OTA file: [GET /OTA2_image_file.bin?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEF8aCXVzLWVhc3QtMiJIMEYCIQC8YkAnHZNMNLjWmb%2FlAhehVFtcqp5J65GZz8McETCKTQIhAKv7t%2BWsu6M5%2F8BNM1EcXX2MLcbYth0bZwpf51chRNW1KuYCCNj%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEQAhoMNjE2NDE4NjYwMDEzIgx7Lyq1yUucOI%2Bej5wqugJ%2BRKXdD571CgRn9SmRuDPo4eiJ7346BCm1BK0DZgBUNb0sdkJnkmU13tcQTSHQvbMDqc3AC7z%2FyyjjTHupGkwKzyGEJtUlJDTwquTEIpTMJyBjyyBYziOTp%2FyITtXLv6ar4FU4VGLhZ20NAO8e6o5xVtIBeME0WxkaXL%2B9dr4vAsI7p3EJAxYs7kcwBT2YqdRe%2Bbwzi0%2F5LHzjaYE92viPHIQtd5dlRLi17L5CBRX310EuGmzkR%2ByP8gBdb6UE4f3DpX%2FE3dDrH8LHDb0dCbgc1LzU3jFFjOOWm%2BCTY%2FaByYSl0ge15gIupvP8y1zJQWvoN73GG4%2Fq33h9cntej1s%2BzCgo7KN2aWwlkVigu5hGSgl9LOoKnj9R3xuCWdP0d0Bg%2BZ8aC%2F4WtGBM6J45prvntTVSX47BeMeTuDCLmMCEBjq%2BAS0WC2GvGPR4KqwYjdRe%2BPBCE2p8KVtirJ74wcYE6QVGcMQ2%2FYLHboqyUX%2Bv5e9ZFWEOWOS7rq%2BwP3aH%2BeAW1KeH2zDCpftHedelwFCJkUXLwvtsU%2BLVu%2BTLMezbAQYYQPO%2FQG7AcP8UOIB%2FcuOpBl5iicAi0cImdcnE0Ihjxbv6zWzHaIFtDzYuLnLTFObYvO0qZSRaTTbBuGCYjH732YSH4jAlEgtC9XwsN%2B30018 00:03:12.813 ota2_get_OTA_file() wiced_tcp_receive() result:0 reply_packet:0x506e20
0019 00:03:12.821 http_process_response() result:4 response:0 -- continue
0020 00:03:12.827 HTTP response result:4 code: 0, continue to process (could be no header)
0021 00:03:12.835 ota2_get_OTA() http_get_body() failed, just use the data: packet_data:0x506eb4 packet_data_length:7 available_data_length:7
0022 00:03:12.848 Got data! offset:0 body:0x506eb4 length:7
0023 00:03:12.853 ota2_get_update_header() header_buffer:0x5271a4 size:0x400 (1024)
0024 00:03:12.860 dest:0x5271a4 offset:0 chunk:7 size:1024 end:0x5271ab!
0025 00:03:14.815 ota2_get_OTA_file() wiced_tcp_receive() 7014 socket_closed!
0026 00:03:14.821
ota2_get_OTA_file() Exiting 7014
0027 00:03:14.826 wiced_ota2_service_get_the_update() wiced_ota2_service_wget_update(header) failed!
OTA update error!
0028 00:03:14.865 wiced_ota2_service_get_the_update() ota2_service_connect() failed (list)!
OTA server connect error!
0029 00:03:14.875 wiced_ota2_service_network_switchto_default_ap() already connected to: XXXXXXXX
OTA update complete!
0030 00:03:14.886 OTA2: wiced_ota2_service_get_the_update() FAILED check if timers started!
0031 00:03:14.894 OTA2: wiced_ota2_service_get_the_update() FAILED set flag START_RETRY_TIMER!
----------------------------------------------------------------------------------------------------------------------------------------------------

I'm trying to trace back what is going wrong here, but am still having issues figuring out why ota2_get_update_header() is still failing.

Best,
Spencer

0 Likes
Aditi_B
Moderator
Moderator
Moderator
500 replies posted 5 questions asked 250 replies posted

Hi,

The problem is with the receive first as the timeout is being observed in the logs. Even in the previous response, I see socket being closed

0025 00:03:14.815 ota2_get_OTA_file() wiced_tcp_receive() 7014 socket_closed!

Can you check if you see the same issue with LwIP?

Thanks

Aditi

 

0 Likes