CC3220: BUG in OTA_lib archive parser. In rare cases ota.cmd read incomplete

Arnout Diels

Part Number: CC3220

Hi,

When testing some more OTA examples and adding a some more files to my tar file, I ran into a errors during OTA upgrade.
Parts of the cmd.ota line were being misinterpreted as files:

OTALIB: [_BundleCmdFile_Parse] bundle cmd file=/cert/key.pem, sig_len=0, SHA_256_Digets=ba6fbc6cf312ed3afe103ec2d504f6d6560c351e5cab34b6ec3ed8748f82ffc5, cert=, secured=0, bundle=0
OTALIB: [_BundleCmdFile_Parse] bundle cmd file=/cert/otacert.der, sig_len=0, SHA_256_Digets=7431e5f4c3c1ce4690774f0b61e05440883ba9a01ed00ba6abd7806ed3b118cf, cert=, secured=0, bundle=0
Doing-OTA-Run
OTALIB: OtaArchive_RunParseTar: parsing archive file header
OTALIB: OtaArchive_RunParseTar: skip block align RecvBufLen=1440, SkipAlignSize=96
OTALIB: OtaArchive_RunParseTar: unsupported FileType=103, FileName= "certificate":"",
"signature_base64":"",
"secured":0,
"bundle":1,
"filename":"/sys/mcuimg.b,

Strangely enough, changing (or even lowering!) the buffer size in ota.h suddenly fixed the problem.

Turns out there is a bug in the ota library..

In OtaArchive.c in the state ARCHIVE_STATE_PARSE_CMD_FILE, the cmd file is parsed, and the function _BundleCmdFile_Parse is expected to return whether the full file is parsed or not.
The function however does not always work correctly. I just so happened to have bad luck, and my buffer just was split in the worst possible place. Trying to visualize here:

As you can see, the entire json object was accidentally cut -just- after the }, and this causes the parsing function to wrongly report being done with the entire file..

The correct way of checking whether the entire ota file is parsed, is to pass it the length stored in the tar header..

Hope this gets fixed.

Kind regards,

Arnout

over 7 years ago

0 Arnout Diels over 7 years ago

Intellectual 730 points

Further looking into the code shows that there is some check for the file length, but the fact where the cut happened causes the while condition to be wrong, and to exit at the end of the function incorrectly without correctly having parsed the full file

0 Austin Tanner over 7 years ago in reply to Arnout Diels

TI__Expert 8255 points

Hi Arnout,

After changing the buffer size in ota.h, do you still see the issue: "The function however does not always work correctly. I just so happened to have bad luck, and my buffer just was split in the worst possible place."

0 Arnout Diels over 7 years ago in reply to Austin Tanner

Intellectual 730 points

Hi,

When I change the buffer size (tried 1500 and 1400 instead of 1440) it correctly parses the full file.

However this is not a fix, since a different tar file with different ota.cmd sizes might then still give the issue.

0 Austin Tanner over 7 years ago in reply to Arnout Diels

TI__Expert 8255 points

Hi Arnout,

Thanks for the feedback. I'll make note of this as a known issue so we can provide a fix from our end.

0 david s over 7 years ago in reply to Austin Tanner

Genius 3005 points

Hi,

Is there a fix for this issue? If not, as a workaround, how to calculate the required NET_BUF_SIZE value?

Thanks,
David

0 david s over 7 years ago in reply to Arnout Diels

Genius 3005 points

Hi Arnout,

I am facing a similar problem but I am not able to find the value for NET_BUF_SIZE that would solve the issue. How did you calculate the required NET_BUF_SIZE value?

Thanks,
David

0 Arnout Diels over 7 years ago in reply to david s

Intellectual 730 points

Hi,

What I do, is just test my ota. The chance of this happening is pretty small, and if you just change the filename length of 1 item in the tar, it is probably enough to avoid the issue. If you are really having my issue, -any- other value than the one you are using now will probably do.
If not, you might be seeing another problem.

Kind regards,
Arnout

Wi-Fi

Wi-Fi forum

CC3220: BUG in OTA_lib archive parser. In rare cases ota.cmd read incomplete