Integrity check / Checksum ?

[buffyslays]

Hi Thomas and community, two questions:

1. What is the purpose of checking the IntegrityId?

UInt32 reqIntegCheck = (UInt32)request.SequenceNumber + request.IntegrityId;
if (response.IntegrityId != reqIntegCheck)

Is the reason simply just to make sure the response is the correct response to the request? Or is there another reason we do this?

2. Do you know how to know if the controller's database has changed? I don't see a checksum request in your code, do you know if there is one? Or any other way to check? We need to know if anything has changed on the controller so that we know when to do another download/browse. It does not make sense in our case to redownload the tags and the tag information on each read or write.

Any info or advice is appreciated!

[thomas-v2]

For 1:
I just use it as additional check if all the previous data processing was correct, because the number of zero bytes between this field and the start of the trailer isn't always the same. Sometimes 4 or 5 bytes, I haven't found out why and when theres this difference. In Wireshark I fill when I'm at the end of processing the difference between the length in the header and the current position with the "Data unknown" to know when the trailer starts. I think it has nothing to do with any kind of integrity, I don't know why I've choosen this name. But the field was always in the protocol, even in the first generation of 1200 controller which hadn't any kind of authentication or digital signature.

For 2:
It should be possible to read the attribute ID 2479, which represents a change counter, for the object ID of the plc program (NativeObjects_thePLCProgram_Rid). As far as I know, the value should be incremented on every program change.

The protocol allows to create a CRC checksum for the symbol. For now I enter the value 0 into this field, means there's no checksum check in the plc. Otherwise the plc does check the CRC and you will get a read / write error if the value doesn't match. The CRC is calculated from the complete symbol path, with some specific value as delimiter. The latest version also adds the value for the datatype into the calculation, but that was not always the case as far as I can remember. But I guess that all TLS supporting controllers use the same calculation. For the CRC calculation the same generator polynom as in the Profisafe protocol is used.