• 状态
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 108 视图
  • 用户 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.

[参考译文] AM6421：符合性测试期间 EtherNet/IP 协议栈返回&quot；无效属性值&quot；在 SET_ATTRIBUTLE_SINGLE 上 (CT22-EN)

admin
Guru**** 2874300 points

Other Parts Discussed in Thread: AM6421

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1628750/am6421-ethernet-ip-stack-returns-invalid-attribute-value-on-set_attribute_single-during-conformance-tests-ct22-en

器件型号： AM6421

我们使用 2026年02月09日 的 Ind Comms SDK 2025.00.01.02 测试版本、观察到 AM6421 系统 (CDF800-E1) 上进行 CT22-EN 测试失败。 CT 工具发送请求 Set_Attribute_Single（服务 0x10、 类 0xf5：TCP/IP 对象、实例 1、属性 5：接口配置）、设备以状态 0x09“无效属性值“（请参阅附加的 Wireshark 日志帧 377 和 378）进行应答。 这会导致多个测试失败、例如 “Error response is unexpected attr 5、SRV Code x10“。

CT 工具发送的电报似乎正常（也通过 Wireshark 和 Copilot 验证）。 在处理此类请求的回调函数中、我可以正确解释 CT 工具发送的数据、并且看不到任何可疑的数据。

通过对我们的实现和 Ind Comms SDK 中 EtherNet/IP 的更新示例进行比较、并没有发现任何相关差异（此外，Copilot 也找不到任何可疑的信息）。
我逐步从回调函数中删除了逻辑、但测试仍然失败。

由于回调函数 （参考设计中的“void device_profile_CFG_callback “）是 void、因此我不知道在这种情况下我们如何影响堆栈行为以触发“无效属性值“应答。  

在测试期间、我观察到禁用器件 viea“EI_API_ADP_setHwSettings (p_adapter、true、false)“的可配置性确实会导致测试通过、堆栈返回成功。 不过、这不是我们的用例。
在您的示例中、不使用此函数、但我假设默认也可以通过软件进行配置。

请支持我们确定此问题的根本原因。
在 Ind Comms SDK 2025.00.01.02 的测试阶段、您是否观察到类似的情况？
堆栈如何准确地评估来自 CT 工具的请求、以及我们如何影响堆栈行为（例如在回调函数中）？
我们还可以在最后调查什么以确定根本问题？

 

我们使用的一致性测试工具是 CT22-EN (PUB0047R25-CT22EN-20251118.zip)、我们的 R5 应用是使用 Ind Comms SDK 2025.00.01.02（2026 年 2 月 9 日）构建的。

 

与 Pourya Eskandari 进行简短讨论：
他怀疑 PC 的配置可能是错误的、特别是指向发送网关 IP 0.0.0.0 的 CT 工具的请求、这可能会导致堆栈行为。  
我们发现了两台 PC 的问题、两者都没有配置网关（与设备的点对点连接）。 但即使在配置网关后、CT 工具仍会在其请求中发送 0.0.0.0。
此外、我们认为 0.0.0.0 是有效的网关地址。

谢谢、

Sascha

CT Tool 日志： 20260318_CT22_SICK_CDF800-E1_200byte_V1.2.1.529.log 
Wireshark 日志： wireshark.zip 

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

    您好 Pourya、

    感谢您的详细回答。
    由于网关 0.0.0.0 不满足这些要求 (“无网络地址“和“相同子网“）、因此您的规则集解释了此行为。
    使用 CT 套件中的“消息工具“、我可以确认配置满足这些规则的网关地址的请求是否成功。 例如、以下 CIP 请求数据已处理：
    50 01 A8 C0 00 FF FF C8 01 A8 C0 00 00 00 00 00 00 00 00 00 00 00 00
    配置网关 0.0.0.0 的请求被拒绝时：
    50 01 A8 C0 00 FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    但是、即使在为我的网络接口配置了有效网关（但物理上不存在）后、一致性测试仍会失败、因为工具仍会发送网关地址为 0.0.0.0 的配置请求。
    在运行测试之前和之后、我验证了我的接口配置：
    以太网适配器以太网 2：
    特定于连接的 DNS 后缀。 ：
    IPv4 地址。 。 。 。 。 。 。 。 。 。 。 ：192.168.1.100
    子网掩码。 。 。 。 。 。 。 。 。 。 。 ：255.255.255.0
    IPv4 地址。 。 。 。 。 。 。 。 。 。 。 ：192.168.1.101
    子网掩码。 。 。 。 。 。 。 。 。 。 。 ：255.255.255.0
    IPv4 地址。 。 。 。 。 。 。 。 。 。 。 ：192.168.3.100
    子网掩码。 。 。 。 。 。 。 。 。 。 。 ：255.255.255.0
    默认网关。 。 。 。 。 。 。 。 。 ：192.168.1.200
    CT 测试工具配置为使用 IP 192.168.1.100。
    因此、我 不确定我们是否/如何影响此处的 CT 测试工具。 例如、我在 SOC 文件中找不到任何设置。 “你怎么知道的?“
    或者、在运行 CT22-EN 测试套件时、我们的方法/配置可能有所不同？ 例如、我们在运行测试时使用静态 IP 地址配置。
    此外、我们还不清楚为什么不接受 0.0.0.0。 这是我们的默认配置、我们的许多客户都使用此配置。 我们也找不到 ODVA EtherNet/IP 规范中的任何约束、因此我们需要假设客户将使用该 配置。

    很抱歉混用了日志、我为新的运行附加了新的一致日志、其中包含一致性测试的子集：

    e2e.ti.com/.../ct.loge2e.ti.com/.../8713.wireshark.zip

    此致、
    Sascha

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

    您好 Pourya、

    感谢您的详细回答。
    由于网关 0.0.0.0 不满足这些要求 (“无网络地址“和“相同子网“）、因此您的规则集解释了此行为。
    使用 CT 套件中的“消息工具“、我可以确认配置满足这些规则的网关地址的请求是否成功。 例如、以下 CIP 请求数据已处理：
    50 01 A8 C0 00 FF FF C8 01 A8 C0 00 00 00 00 00 00 00 00 00 00 00 00
    配置网关 0.0.0.0 的请求被拒绝时：
    50 01 A8 C0 00 FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    但是、即使在为我的网络接口配置了有效网关（但物理上不存在）后、一致性测试仍会失败、因为工具仍会发送网关地址为 0.0.0.0 的配置请求。
    在运行测试之前和之后、我验证了我的接口配置：
    以太网适配器以太网 2：
    特定于连接的 DNS 后缀。 ：
    IPv4 地址。 。 。 。 。 。 。 。 。 。 。 ：192.168.1.100
    子网掩码。 。 。 。 。 。 。 。 。 。 。 ：255.255.255.0
    IPv4 地址。 。 。 。 。 。 。 。 。 。 。 ：192.168.1.101
    子网掩码。 。 。 。 。 。 。 。 。 。 。 ：255.255.255.0
    IPv4 地址。 。 。 。 。 。 。 。 。 。 。 ：192.168.3.100
    子网掩码。 。 。 。 。 。 。 。 。 。 。 ：255.255.255.0
    默认网关。 。 。 。 。 。 。 。 。 ：192.168.1.200
    CT 测试工具配置为使用 IP 192.168.1.100。
    因此、我 不确定我们是否/如何影响此处的 CT 测试工具。 例如、我在 SOC 文件中找不到任何设置。 “你怎么知道的?“
    或者、在运行 CT22-EN 测试套件时、我们的方法/配置可能有所不同？ 例如、我们在运行测试时使用静态 IP 地址配置。
    此外、我们还不清楚为什么不接受 0.0.0.0。 这是我们的默认配置、我们的许多客户都使用此配置。 我们也找不到 ODVA EtherNet/IP 规范中的任何约束、因此我们需要假设客户将使用该配置。

    很抱歉混用了日志、我为新的运行附加了新的一致日志、其中包含一致性测试的子集：

    e2e.ti.com/.../1018.ct.loge2e.ti.com/.../1018.wireshark.zip

    此致、
    Sascha

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

    尊敬的 Sascha：

    我不确定 CT22 的内部运作机制。 和您一样、我找不到允许使用非零网关地址的 TCP/IP 对象测试的任何配置选项。 但是、由于我不能在我的最后重现此问题（CT22 始终使用非零网关地址）、我相信它可能首先通过 get-attribute 服务检索属性 5、然后使用此检索到的值作为后续请求的默认基础。

    这表明项目中 TCP/IP 对象的出厂默认值可能是差异的来源。 在 TI 的示例中、这些默认值是在 device_profile_reset.c 文件中专门配置的。


    此致、
    Pourya

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

    您好 Pourya、

    您的假设必须正确、在调整出厂默认值和网关的初始设置后、此错误不再出现。

    但我仍然认为 0.0.0.0 的网关是有效的,应该被接受。  TCP/IP 对象规范 （“CIP 网络库第 2 卷：CIP 的 Ethernet/IP Adaptation of CIP“、表 5-3.2、“设置“访问规则中的“网关地址“）中也明确提到了这一点：

    “值为 0 表示没有配置 IP 地址。 否则、IP 地址应设置为有效的 A、B 或 C 类地址、而不应设置为回送地址 (127.0.0.1)。“。

    此致、

    Sascha

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

    您好、Sascha、

    我同意您的观点、即需要调整接受 IP 配置的过滤逻辑。 我们将在下一个版本中跟踪此增强功能。
    CT22 测试中是否已解决所有错误？


    此致、
    Pourya

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

    您好 Pourya、

    非常感谢、听起来非常棒！
    该版本仍将于 4 月发布、对吧？

    遗憾的是、我仍在调查几个 CT22 失败的情况、例如中报告的情况  1629925.

    此致、

    Sascha

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

    尊敬的 Sascha：

    你能详细说明一下,你的意思是什么“一个在 1629925 报告“?

    此致、
    Pourya

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

    尊敬的 Pourya：

    抱歉、我在我们的私人区域提出了以下请求： https://urldefense.com/v3/__https://e2e.ti.com/e2eprivate/sick/sick---indsdk/f/ti-sick-indsdk-forum/1629925/am6421-ct22-en-conformance-test-fails-non-zero-encapsulation-inactivity-timeout__;！!BXYwEpu2!tKEPZrpryjGSy28xnWtTh8274NdCDRNgmGJiNUnq7BBcU5JwI2D6Vwg34ucitJkkF-NnU3SyRgywrl_rjvYFlAIH$</s>！ ！

    此致、

    Sascha