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.
Hi Nilabh
Please help to foward the following LLDP conformance test problems to KUNBUS team.
The test cases are "LLDP Management Object" and the "LLDP Data Table".
7268.Log and Wireshark files.zip
Best regard
Bo-Cheng
Hi Bo-Cheng,
Let me check the Test report from our dev team and get back by early next week.
Hi Nilabh,
By our test, the previous questions are not happened on V9.0.0.3, but we got some new errors in this version.
We also meet some other problems not about the LLDP will need KUNBUS's help.
I wrapped up all issues in the attached file "9.0.0.3 issue.pdf", and also attached the CT log and Wireshark data.
Please help to forward all of files to KUNBUS.
Thank you for the help.
Best regard
Bo-Cheng
Hi Bo-Cheng,
Could you please create few more e2e to track issues seperately, as it is a over head to track issues in pdf. I would recommend creating 3 e2e:
1. BOOTP
2. LLDP Management- This current e2e we will track here.
3. Test Encapsulation
4. IP address configuration
Initial response from Kunbus:
we know of errors reported by the conformance test tool. Our current interpretation is that there are still errors in the conformance test tool implementation, but we will verify.
One of the warnings is that the new Identification TLV is not supported. This will become mandatory towards end of 2024.
The Information TLV changed between the November 2022 and April 2023 Edition of the specification, and may get clarified again for the November 2023 edition. We will look at the upcoming November 2023 edition and change it. This is known and will be addressed this year, once the TLV specification is stable.
We will review anyway and get back to you.
Hi Nilabh,
It's not easy for us to regenerate those contents for each question in a short time due to our company's menagement policy.
Please forward the files to KUNBUS first, and I will create another 3 e2e threads tomorrow. We hope those problems can be clearfied as soon as possible.
We worried about the firmware still have some bugs and not ready for the conformance test, and it's not cool for our product schedule.
Thank you for the understanding.
Hi Nilabh,
I hope that this is the correct thread. If have hot been fully following everything the last two weeks, as I'm an actually still in holidays.
Occasionally I am however in contact with the EtherNet/IP team and also forward the inquiries.
Best regards,
Martin
BOOTP service question:
Q) Does the stack support BOOTP service? We can change the device to the BOOTP mode by CT19.1 Message tool but can’t config the IP under BOOTP mode by BOOTP server. (See below figure)
A) BOOTP is supported, but we can also see some issues. We will continue analyzing this and come back to you as soon as possible. We are going to work with this on our new coming sprint (starting next week).
Q) If the stack doesn’t support BOOTP service, could it be performed as Allen Bradley drives reject mode change and return error state code like below?
A) BOOTP is supported, means we will not implement proposed option.
CT19.1 Conformance Test: 265-LLDP Management Object Test problems
Q) We got 3 new errors about TLV and 1 error about unexpected LLDP frame received. Are they caused by firmware problems or our wrong test configuration or setting?
A) As was written by Martin on September 7th this error report is normal from CT19.1 and we predict that is a bug of tool. This error could be temporarily ignored.
CT19.1 Conformance Test: 266-LLDP Data Table question
Q) We got 1 new warning about the max. instance attribute didn’t be changed after receiving a LLDP frame from a new interface. Is it a known issue of firmware version 9.0.0.3?
A) This is just a warning and it means that is reusing the instance number which was used previously and released afterwards.
CT19.1 Conformance Test: multiple encapsulation test problem
Q) When we run 5 times of encapsulation test continuously, we occasionally get an error as the figure below. We think it may be a firmware bug need to be fix. Note: We get this issue by doing the EthernetLink test 5 times with encapsulation test.
A) That error is reported from time to time also on our conformance tests, but needs to be checked in the Wireshark log for timestamps. Here the Wireshark log is missing, can you be so kind of sending us this? In our case we saw that delta of timestamps is bellow of reported 1200ms. Means again problem of CT19.1 conformance test tool.
Can’t change the IP configuration mode by Rockwell EtherNet/IP Address Commissioning Tool
Q) When we use the tool to send the request to change the IP configuration mode to “Static”, the tool responds the device don’t support CIP and the mode change fail. We wonder if it’s also a firmware issue, and if it could be fixed.
A) From Wireshark log is visible that Rockwell EtherNet/IP Address Commissioning Tool tries to get the class attribute 2 (Max Instance) - not required or conditional attribute, which is not supported by our device, that´s why it responds with an error code in this case. But seems that this tool requires this attribute to be supported and that´s why it stops requesting after this.
Hi Nilabh,
Please help forwarding our futher questions to Kunbus.
BOOTP service question:
Q) What are issues of BOOTP that Kunbus already know?
Q) When the issues are expected could be fixed.
CT19.1 Conformance Test: 265-LLDP Management Object Test problems
Q) Are you talking about the Nilabh's reply on Sep.13 in this thread? If it is, I think it was takling about the very 1st question happened on v8.6. However in my question on Sep.13, the test result has changed with v9.0.0.3. We got totaly different error messages as below. Are you sure they are also caused by the ODVA's bugs?
CT19.1 Conformance Test: multiple encapsulation test problem
A) We will send you the WireShark data before the end of this week.
Can’t change the IP configuration mode by Rockwell EtherNet/IP Address Commissioning Tool
Q) We agree this attribute is optional, but other competitor's protucts(like Festo) do support it and I think it's a normal operation with rockwell tools. We think the attribute 2 and 3 are better be supported for end users' operation with Rockwell controller.
Thank you for the help.
Best regard
Bo-Cheng
Hi Nilabh,
We get some feedbacks from ODVA.
Please help to update the ODVA's advices to Kunbus as below.
CT19.1 Conformance Test: 265-LLDP Management Object Test problems
[ODVA] These look like real errors. #1, 2, and 3 mean that your device is not including the required TLV data. Check out Vol 2 Chapter 9-8 for required TLVs. Error 4 I have never seen before. It means that the test received an LLDP packet from your device after LLDP Management Object was set to disable transmission.
Q) We think as ODVA's advice these issues need to be fixed and analyzed.
CT19.1 Conformance Test: multiple encapsulation test problem
A) ODVA has confirmed this is a CTT bug and can be ignored. We will close this issue and not offer the WireShark data for further examination.
Thank you for the help.
Best regard
Bo-Cheng
Hi Bo-Cheng
Response from Kunbus
in the ODVA roundtable discussion yesterday I got the information that there is a new draft revision of the ODVA Conformance Test (CT20) available since 2 weeks that also changes some parts of the LLDP test. We requested access to it and then will perform the LLDP tests with our code again. I keep you informed as soon as we get the test software.
Hi Nilabh,
Could you ask Kunbus for more detail about the conclusion on yesterday's roundtable discussion to the LLDP errors?
Because the conclusion seems confilct with ODVA USA, I wonder why they think the CT20 will solve these errors.
Moreover, when the CT20 will be used on ODVA's test?
Best regard
Bo-Cheng
Hi Nilabh,
Please help to update these issues on last week?
BOOTP service question:
Q) What are issues of BOOTP that Kunbus already know?
Q) When the issues are expected could be fixed.
CT19.1 Conformance Test: 265-LLDP Management Object Test problems
[ODVA] These look like real errors. #1, 2, and 3 mean that your device is not including the required TLV data. Check out Vol 2 Chapter 9-8 for required TLVs. Error 4 I have never seen before. It means that the test received an LLDP packet from your device after LLDP Management Object was set to disable transmission.
Q) We think as ODVA's advice these issues need to be fixed and analyzed.
Q) We wonder what are reasons that the Kunbus think the CT20 will solve these problems?
Can’t change the IP configuration mode by Rockwell EtherNet/IP Address Commissioning Tool
Q) We agree this attribute is optional, but other competitor's protucts(like Festo) do support it and I think it's a normal operation with rockwell tools. We think the attribute 2 and 3 are better be supported for end users' operation with Rockwell controller.
Best regard
Response from Kunbus:
we performed the LLDP test yesterday with the new CT20 beta and it still reports the same error messages on missing TLVs.
I submitted an error report (see below) to ODVA this morning detailing why the conformance test implementation (and at the end the EtherNet/IP specification) conflicts with the IEEE 802.1AB-2016 standard, which in our interpretation clearly states that those additional TLVs are not allowed. You may pass this on to HiWin.
Martin
Hi,
we were running some initial tests with the new EtherNet/IP CT20 conformance test and still get error reports claiming that after disabling LLDP via Attribute 1 of the LLDP Management Object (Global Enable bit set to 0, frame number 2313 in the attached Wireshark trace). On disabling LLDP the agent should attempt to transmit a Shutdown LLDPDU.
The format of this LLDPDU is detailed in clauses 9.2.7.3 mibConstrShutdownLLDPDU() and 9.1.2.2 Shutdown LLDPDUs of IEEE Std 802.1AB-2016.
9.2.7.3 states:
The mibConstrShutdownLLDPDU() procedure constructs a shutdown LLDPDU according to the LLDPDU
and the associated TLV formats specified in 8.2 and 8.5. The shutdown LLDPDU contains only the
following items:
a) The Chassis ID and Port ID TLVs.
b) The Time To Live TLV with the TTL field set to zero.
c) Optionally, an End Of LLDPDU TLV.
whereas 9.1.2.2 states:
….
In the event a port, currently configured with LLDP frame transmission enabled, either becomes disabled for LLDP activity, or
the interface is administratively disabled, the transmit state machine attempts to send a final LLDP shutdown LLDPDU with:
a) The Chassis ID TLV.
b) The Port ID TLV.
c) The Time To Live TLV with the TTL field set to zero.
d) Optionally, an End Of LLDPDU TLV.
The shutdown LLDPDU does not include any other optional TLVs and, if possible, should be transmitted before the interface is disabled.
This conflicts with the conformance test (also CT19 and CT19.1) additionally requires the System Capability TLV, the Management Address TLV, and the CIP Identification TLV to be included as part of the Shutdown LLDPDU. Those TLVs are optional according to Table 8-1 in IEEE Std 802.1AB-2016, and thus, shall not be included in the Shutdown LLDPDU.
We interpret this as the conformance test implementation(s) incorrectly does not distinguish between Normal LLDPDUs (9.1.2.1) and Shutdown LLDPDUs (9.1.2.2) in the LLDP behavior test.
Hi Nilabh,
Could you ask Kunbus for TI's feedback to their question?
We are very appreciated for your support.
Best regard
Bo-Cheng
Hi Bo-Cheng,
These questions are being asked to ODVA, as some of the LLDP frame handling are conflicting with IEEE spec. Kunbus is currently waiting for ODVA's response
Nilabh, do we have a dedicated TS ticket for that? We receive the final CT20 release this morning and will do a retesting.
Yes Martin, There is one created by Mike, but I do not have access to that,
Hi Nilabh,
How's about the test of CT20?
Could you ask Kunbus for test update and when the next version will be released?
Thank you
Hi Bo-Cheng, hi Nilabh,
I haven't received the last updated code (hopefully will get it today) to perform CT20 myself, but I've been told that all LLDP issues are solved now.
Martin
Thanks Martin, Good to hear that issues are resolved. Please share the ct20 results once available.
Hi Nilabh, Martin,
On V9.0.0.3, I get a new STC error as the figure below when testing the "LLDP management object" test case.
Do I need to change any STC setting for CT20?
Can you also share the ".soc" file with us?
Thank you so much
Hi Nilabh, Martin,
ODVA already tell us how to solve the issue by modifying the STC setting. The STC error issue can be marked as resolved.