[参考译文] AM2434：EtherNet/IP LLDP 测试问题

尊敬的 Bo-Cheng：

请允许我查看我们开发团队的测试报告、并在下周早些时候回来。

尊敬的 Nilabh：

根据我们的测试、先前的问题不是发生在 v9.0.0.3上、但此版本中有一些新错误。

我们还遇到了 一些与 LLDP 无关的其他问题将需要 KUNBUS 的帮助。

我在随附的文件"9.0.0.3 issue.pdf"中总结了所有问题、并附加了 CT 日志和 Wireshark 数据。

请帮助将所有文件转发至 KUNBUS。

感谢你的帮助。

最 尊重

博诚

e2e.ti.com/.../9.0.0.3_5F00_Issues.pdf

e2e.ti.com/.../CTTLog_5F00_and_5F00_WireShark_5F00_data.zip

尊敬的 Bo-Cheng：

您能否创建几个以上的 e2e 来单独跟踪问题、因为它是在 pdf 中跟踪问题的通篇方法。 我建议创建3个 e2e：

1. BOOTP  

2. LLDP 管理—我们将在此处跟踪当前的 e2e。

3.测试封装

4. IP 地址配置

Kunbus 的初始响应：

我们知道一致性测试工具报告的错误。 我们目前的理解是一致性测试工具实现中仍然存在错误、但我们将进行验证。

警告之一是不支持新的识别 TLV。 到2024年底、这将成为强制性要求。
信息 TLV 在2022年11月至2023年4月版规范之间发生了更改、可能会针对2023年11月版再次说明。 我们将查看即将到来的2023年11月版并对其进行更改。 这是已知的、一旦 TLV 规格稳定、今年将解决此问题。

我们会随时给您回复。

尊敬的 Nilabh：

由于我们公司的管理政策、我们不容易在短时间内为每个问题重新生成这些内容。

请先将文件转发给 KUNBUS、明天我再创建3个 e2e 线程。  我们希望这些问题能够尽快澄清。  
我们担心固件仍然有一些错误、未准备好进行符合性测试、对于我们的产品计划来说也不是很好。

感谢您的理解。

我理解 Bo-Cheng、

我正在与 Kunbus 一起跟进此事。  

尊敬的 Nilabh：

您可以要求 Kunbus 更新吗？

谢谢！

博诚

尊敬的 Nilabh：

我希望这是正确的主题。 如果热一直完全关注的一切过去的两周,因为我实际上还在假期.

但有时我会与 EtherNet/IP 团队联系、并转发咨询。

此致、

马丁

BOOTP 服务问题：

1. 问)堆栈是否支持 BOOTP 服务？ 我们可以通过 CT19.1消息工具将设备更改为 BOOTP 模式，但无法通过 BOOTP 服务器在 BOOTP 模式下配置 IP。 (见下图)

   a)支持 BOOTP，但我们也可以看到一些问题。 我们将继续对此进行分析、并尽快与您联系。 我们将在即将到来的新冲刺中与此合作(从下周开始)。

2. 问)如果堆栈不支持 BOOTP 服务，它是否可以作为 Allen Bradley 驱动器拒绝模式更改并返回如下所示的错误状态代码来执行？

   a)支持 BOOTP，意味着我们不会实施建议的选项。

CT19.1一致性测试：265-LLDP 管理对象测试问题

1. 问)我们收到了有关 TLV 的3个新错误和关于意外接收到 LLDP 帧的1个错误。  它们是由固件问题还是我们错误的测试配置或设置引起的？

   a)正如 Martin 在9月7日编写的那样、此错误报告从 CT19.1开始是正常的、我们预测这是一个工具错误。 此错误可能会被暂时忽略。

CT19.1一致性测试：266-LLDP 数据表问题

1.  问)我们收到1条有关最大值的新警告。 从新接口接收到 LLDP 帧后、不会更改实例属性。 是否是固件版本9.0.0.3的已知问题？

   A)这只是一个警告、这意味着重复使用之前使用并在之后发布的实例编号。

CT19.1一致性测试：多封装测试问题

1. q)当我们连续运行5次封装测试时、我们偶尔会遇到如下图所示的错误。 我们认为可能需要修复固件错误。 注意：我们通过执行5次以太网链路测试和封装测试来获得这个问题。

   A)该错误还会在我们的一致性测试中不时报告、但需要在 Wireshark 日志中检查时间戳。 这里缺少 Wireshark 日志、您能给我们发送这篇文章吗？ 在我们的案例中,我们看到时间戳的差值低于报告的1200毫秒。 这也意味着 CT19.1符合性测试工具的问题。

无法通过 Rockwell EtherNet/IP 地址调试工具更改 IP 配置模式

1. 问)当我们使用该工具发送将 IP 配置模式更改为"Static"时、该工具会响应器件不支持 CIP、并且模式更改会失败。  我们想知道这是否也是固件问题、以及是否可以解决。

   ´s 从 Wireshark 日志中可以看到，Rockwell EtherNet/IP 地址调试工具尝试获取类属性2 (最大实例数)-我们的器件不支持的不是必需或条件属性，这就是在本例中它为什么用错误代码进行响应的原因。 ´s 似乎此工具需要支持此属性、这就是它在这之后停止请求的原因。

尊敬的 Nilabh：

请将我们的进一步问题转发给 Kunbus。

BOOTP 服务问题 ：

Q)Bootp 的哪些问题,Kunbus 已经知道?
问)问题可能会在何时得到解决。

CT19.1一致性测试：265-LLDP 管理对象测试问题

问)您在本主题中谈论 Nilabh 9月13日的回复吗？ 如果是的话,我想它是抓住了第8.6版上发生的第一个问题。 但是、在我关于9月13日的问题中、测试结果与 v9.0.0.3发生了变化。 我们总共收到如下所示的不同错误消息。 您确定它们也是由 ODVA 的错误引起的吗？
  

CT19.1一致性测试：多封装测试问题

A)我们将在本周结束前向您发送 Wireshark 数据。

 无法通过 Rockwell EtherNet/IP 地址调试工具更改 IP 配置模式

问)我们同意此属性是可选的，但其他竞争对手的产品(如 Festo)确实支持它，我认为这是使用 Rockwell 工具的正常操作。 我们认为，对于最终用户使用 Rockwell 控制器进行操作，更好地支持属性2和3。

感谢你的帮助。

最尊重

博诚    

尊敬的 Nilabh：

我们会收到 ODVA 的一些反馈。

请帮助更新 ODVA 对 Kunbus 的建议如下。

CT19.1一致性测试：265-LLDP 管理对象测试问题

[ODVA]  这些看起来像是真实的误差。 1、2和3表示您的设备不包含所需的 TLV 数据。 有关所需的 TLV、请查看第2卷第9-8章。 我以前从未见过错误4。 这意味着在 LLDP 管理对象设置为禁用传输后、测试从您的设备收到了 LLDP 数据包。

问)我们认为、ODVA 的建议是需要解决和分析这些问题。  

CT19.1一致性测试：多封装测试问题

a) ODVA 已确认这是一个 CTT 错误、可以忽略。 我们将关闭此问题、而不提供 Wireshark 数据供进一步检查。  

感谢你的帮助。

最尊重

博诚    

尊敬的 博诚：

Kunbus 的响应

在昨天的 ODVA 圆桌会议讨论中、我得到了这样的信息：自2周以来就推出了 ODVA 一致性测试(CT20)的新修订草案、这也改变了 LLDP 测试的某些部分。 我们已请求对其进行访问、然后将再次使用我们的代码执行 LLDP 测试。 我会在我们获得测试软件后立即通知您。

尊敬的 Nilabh：

你能否请 Kunbus 更详细地了解昨天圆桌讨论对 LLDP 错误的结论?

由于结论似乎与美国 ODVA 有关,我想知道为什么他们认为 CT20会解决这些错误。

此外、何时将使用 CT20进行 ODVA 的测试？

最尊重  

博诚

尊敬的 Nilabh：

请帮助我们在上周更新这些问题？

BOOTP 服务问题 ：

Q)Bootp 的哪些问题,Kunbus 已经知道?
问)问题可能会在何时得到解决。

CT19.1一致性测试：265-LLDP 管理对象测试问题

[ODVA]  这些看起来像是真实的误差。 1、2和3表示您的设备不包含所需的 TLV 数据。 有关所需的 TLV、请查看第2卷第9-8章。 我以前从未见过错误4。 这意味着在 LLDP 管理对象设置为禁用传输后、测试从您的设备收到了 LLDP 数据包。

问)我们认为、ODVA 的建议是需要解决和分析这些问题。  

问昆巴认为 CT20会解决这些问题的原因是什么?

无法通过 Rockwell EtherNet/IP 地址调试工具更改 IP 配置模式

问)我们同意此属性是可选的，但其他竞争对手的产品(如 Festo)确实支持它，我认为这是使用 Rockwell 工具的正常操作。 我们认为，对于最终用户使用 Rockwell 控制器进行操作，更好地支持属性2和3。

最尊重  

Kunbus 的响应：

我们昨天使用新的 CT20测试版执行了 LLDP 测试、它仍然报告了相同的 TLV 缺失错误消息。

我今天上午向 ODVA 提交了一份错误报告(见下文)、详细说明了为什么一致性测试实现(以及最终的 EtherNet/IP 规范)与 IEEE 802.1AB-2016标准相冲突、在我们的解释中明确指出不允许使用这些额外的 TLV。 您可以将此内容传递给 HiWin。

马丁


您好！

我们正在使用新的 EtherNet/IP CT20符合性测试运行一些初始测试、但仍收到错误报告、声称通过 LLDP 管理对象的属性1 (全局启用位设置为0、附加的 Wireshark 跟踪中的帧编号2313)禁用 LLDP 后。 禁用 LLDP 时、工程师应尝试传输关闭 LLDPDU。

该 LLDPDU 的格式在 IEEE 标准802.1AB -2016的第9.2.7.3条 mibConstrShutdownLLDPDU ()和9.1.2.2条关断 LLDPDU 中进行了详细说明。

9.2.7.3指出：

mibConstrShutdownLLDPDU()过程根据 LLDPDU 构建 SHUTDOWN LLDPDU

相关的 TLV 格式在8.2和8.5中指定。 SHUTDOWN LLDPDU 包含 仅限 为

以下项目：

a)机箱 ID 和端口 ID TLV。

b) TTL 字段设置为零时 TLV 的存活时间。

c) LLDPDU TLV 的一端是可选的。

而9.1.2.2规定：

…μ A。

如果当前配置为启用 LLDP 帧传输的端口因 LLDP 活动而被禁用、或

该接口被管理性禁用，发送状态机尝试发送最终 LLDP 关闭 LLDPDU，其中包括：

a)机箱 ID TLV。

B)端口 ID TLV。

c) TTL 字段设置为零时存活 TLV 的时间。

D)可选 LLDPDU TLV 的末端。

关闭 LLDPDU 不包含任何其他可选 TLV 并且、如果可能的话、应该在接口被禁用前发送。

这与一致性测试(也包括 CT19和 CT19.1)相冲突此外、要求 将系统功能 TLV、管理地址 TLV 和 CIP 识别 TLV 作为关断 LLDPDU 的一部分包含。 根据 IEEE 标准802.1AB -2016中的表8-1、这些 TLV 是可选的、因此不应包含在关断 LLDPDU 中。

我们将其解释为一致性测试实现不正确地不区分 正常 LLDPDU (9.1.2.1)和 关断 LLDPDU (9.1.2.2)。

尊敬的 Nilabh：

您能向 Kunbus 请求 TI 对其问题的反馈吗？  

我们非常感谢您的支持。

最尊重

博诚

尊敬的 Bo-Cheng：

这些问题正被提交给 ODVA、因为某些 LLDP 帧处理与 IEEE 规范相冲突。 Kunbus 目前正在等待 ODVA 的响应

尚不能

Nilabh、我们是否有专门的 TS 票？ 我们今天上午收到了最后一期 CT20、并将进行重新测试。

是的、Martin、有一个是 Mike 创建的、但我无法访问它、

尊敬的 Nilabh：

如何测试 CT20？

您是否可以要求 Kunbus 进行测试更新以及下一版本何时发布？

谢谢！

尊敬的 Bo-Cheng、尊敬的 Nilabh：

我还没有收到自己执行 CT20的最后更新代码(希望今天能获得)、但我被告知现在所有 LLDP 问题都已解决。

马丁

谢谢 Martin、很高兴听到问题已经解决。 可用后请分享 CT20结果。

尊敬的 Nilabh、Martin：

在 v9.0.0.3上、在测试"LLDP 管理对象"测试用例时、我收到如下图所示的新 STC 错误。

我是否需要更改 CT20的任何 STC 设置？  

您是否还能 soc 与我们共享".CD"文件？

非常感谢

e2e.ti.com/.../CT20-STC-error.zip

尊敬的 Nilabh、Martin：

ODVA 已经告诉我们如何通过修改 STC 设置来解决这个问题。 STC 错误问题可以标记为已解决。