[Bug]: EIP only working with variables with an odd character count (in second path segment)

[luedi128]

What happened?

We have a Rockwell function block that is offering the following variables, that we want to read out.

The following request with eight variables showed that only one of them is working - the other caused INTERNAL_ERROR responses from the Rockwell PLC.

  readRequestBuilder = plcConnection.readRequestBuilder();
  readRequestBuilder.addTagAddress("v1", "xxx1.timestamp_xxxxxxx_OFF");   // ok - working
  readRequestBuilder.addTagAddress("v2", "xxx1.timestamp_xxxxxxx_ON"); // INTERNAL_ERROR

We have had a look at the CIP packages on network level and it looks like the size of the second path segment was wrongly calculated - the following part of the CIP with slot/address are not recognized as a valid part of CIP protocol in wireshark (screenshot attached).

For testing we renamed the last variable by adding an additional character at the end (in the FB and in the java code) e.g. xxx1.timestamp_xxxxxxx_ONN then everything worked fine. We have this situations with other variables as well (8 variables in our test - only have of them (the once with an even character count) are working - the others result in INTERNAL_ERRORs)

We have been able to fix the problem by changing org.apache.plc4x.java.eip.base.protocol.EipProtocolLogic.class in line 692 to:
newSegment = new DataSegment(new AnsiExtendedSymbolSegment(identifier, (identifier.length() % 2 == 0) ? null : (short) 0));
More or less copy & paste from line 696/697.

From out point of view this is a bug in the path segment length calculation only affecting path variables with an odd character count (or second path segments with an odd character count).

Tested on a Rockwell 1769-L18ER/B LOGIX5318ER.

Version

v0.12.0

Programming Languages

• plc4j
• plc4go
• plc4c
• plc4net

Protocols

• AB-Ethernet
• ADS /AMS
• BACnet/IP
• CANopen
• DeltaV
• DF1
• EtherNet/IP
• Firmata
• KNXnet/IP
• Modbus
• OPC-UA
• S7

[luedi128]

Wireshark screenshot.