• 状态 Resolved
  • 已锁定 已锁定
  • 回复 7 回复
  • 订户 0 订户
  • 视图 276 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC3200：sl_FsOpen ()返回 SL_FS_SECURITY_allert

admin
Guru**** 2482145 points
Other Parts Discussed in Thread: CC3200

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1303606/cc3200-sl_fsopen-return-sl_fs_security_allert

器件型号：CC3200

您好！

一段时间前、我们发现 servicepack 的 OTA 有问题。 少数器件无法打开/sys/servicepack.ucf、但失败时会显示错误代码-52 (SL_FS_SECURITY_allert)。 我们已经询问过该问题(https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1167478/cc3200-cc3200-sl_fsopen-return-sl_fs_security_allert)、但我们没有对任何受影响的设备的物理访问权限来收集请求的 NWP 日志。

由于我们现在已经有这种器件、因此我想请您的支持。

我准备了简单的 FW、它使用 CC3200 SDK.e2e.ti.com/.../1423.main.c 中的修改后的 file_operation 示例重现问题

由设备生成的 log_file： e2e.ti.com/.../1423.log_5F00_file.txt

从 PIN 62收集的 NWP 日志： e2e.ti.com/.../collected_5F00_nwp_5F00_logs.zip

Br、

Łukasz ó n Antkowiak

  • 0
    TI__Guru**** 2482145 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    在您尝试更新服务包时会发生这种情况？

    由于某种原因、它在签名验证期间失败。

  • 0
    TI__Guru**** 2482145 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    是的、在我们尝试更新服务包时会发生这种情况。 所有其他设备功能似乎正常运行。

  • 0
    TI__Guru**** 2482145 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    服务包需要使用签名(以验证它是由 TI 创建的)。

  • 0
    TI__Guru**** 2482145 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    感谢您关注我们的问题。

    我们提供了签名、但我们将其提供给 sl_FsClose 函数。 流程将提前失败。

    您是说打开/sys/servicepack.ucf 进行写入时、我们不应该使用_FS_FILE_OPEN_FLAG_NO_SIGND_TEST 吗？

    我选中了以下两项：

       sl_FsOpen ("/sys/servicepack.ucf、FS_MODE_OPEN_CREATE (262144、_FS_FILE_OPEN_FLAG_COMMIT)、NULL、&servicePackFileHandle)；

    以及：

        sl_FsOpen ("/sys/servicepack.ucf、FS_MODE_OPEN_WRITE、NULL、&servicePackFileHandle)；

    两种情况的结果均为-52。

  • 0
    TI__Guru**** 2482145 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    似乎使用错误的凭据创建了文件(对于服务包、它应该是： _FS_FILE_OPEN_FLAG_COMMIT|_FS_FILE_OPEN_FLAG_FILE_SECURE|_FS_FILE_OWN_TEST|_FS_FILE_PUBLIC_WRITE)或自上次写入以来文件系统已损坏(当文件被写入文件系统时、文件系统也会存储其签名、但文件和签名在某种程度上不匹配)。

    尝试开始刷新(即删除服务 包文件并使用上述标志创建该文件)、然后尝试打开以重新写入。

  • 0
    TI__Guru**** 2482145 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    感谢您分享我们应该使用的标志。

    我尝试实现一种方法、让错误地创建了文件的器件删除服务包文件并再次创建它。 但是、在第一个参数中接收"/sys/servicepack.ucf "、在第二个参数中接收"0"的 sl_FsDel 返回-50、该返回的值似乎与无效令牌相关：
    (来自 fs.h)

    #define SL_FS_ERR_TOKEN_IS_NOT_VALID                         (-50)

    我的假设是、之前的代码创建了带有错误标志的文件、因此我们丢失了可用于删除该文件的令牌。 是否有办法可以覆盖不知道令牌的文件？

  • 0
    TI__Guru**** 2482145 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您无法将其删除、 但您应该能够在没有令牌的情况下重写它(它应该是使用"公共写入"标志创建的、允许覆盖它(请注意、我们使用"降级保护"机制、因此您只能使用更新的 SP、这也是您无法删除它的原因)。