4

For our project, a protocol is specified for communication between an embedded linux device and a PLC/HMI. This protocol includes CRC checking.

However, the communication is now done over TCP (TCP protocol includes CRC), so my question is whether or not a CRC on top of TCP has any meaning ?

9
  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
    – gnat
    Commented Sep 20, 2018 at 10:09
  • Ok, perhaps this is not the forum to ask this type of question...
    – drC1Ron
    Commented Sep 20, 2018 at 10:10
  • 1
    @RonnyLandsverk This sort of question is fine here. It would help to let us know what the CRC in the protocol is checking. TCP error checking will check that you received what you sent. What it can't do is check that it's what you meant to send. Is it possible that the higher protocol is checking something else other than the raw bytes entering and leaving the socket? If that's all it's doing then I agree, it's probably superfluous.
    – Alex
    Commented Sep 20, 2018 at 10:24
  • From your post it sounds like it is a legacy feature - a protocol which was used on a different link (RS485) was moved to TCP. In this case I would just bite the bullet to simplify handling on the PLC/HMI
    – jaskij
    Commented Sep 20, 2018 at 10:39
  • 1
    Also, TCP error checking protects only against error that originated on the wire. It's at least conceivable that whatever corruption of your data you fear happens outside the network, perhaps in the circuitry of your network card r in RAM.
    – Kilian Foth
    Commented Sep 20, 2018 at 11:23

2 Answers 2

Reset to default
2

You can get rid of your own CRC if its less than 48 bits:

TCP provides reliable and error-checked transport service. The error check is double:

As both calculations are using independent algorithms, the odds that an error remains undetected is less than 1/2^48. This calculation is based on the probabilities for the CRC32 and the checksum and the fact that CRC32 detects 100% of the most probable transmission errors.

So unless your legacy CRC is more than 48 bits long (e.g. CRC-64), maintaining it would have no benefit compared to the old situation without TCP.

Layering principle

The layering of the OSI model can be used to guide the design, without necessarily having to enter into probabilistic debates. The principle is that each layer is responsible for something, and relies on the guarantees offered by the lower levels.

So if your application no longer has to manage the lower levels of the transport (network, datalink), then you can get rid of the error checks already performed in these layers.

Checking for the higher levels of the protocol stack could add value. So checking the correct data format and encoding (presentation layer), ensuring the integrity using cryptographic means (presentation layer) or performing application domain specific verifications would still be relevant.

2
  • 1
    "Guarantee" is a bit strong. You can still be unlucky and get an erroneous packet but with a correct CRC. Whether you need stronger protection or not depends on your domain, are you operating a nuclear power system or streaming cat videos?
    – whatsisname
    Commented Sep 20, 2018 at 17:20
  • @whatsisname you are of course right: with bad luck you may very well end up with 2 errors that may neutralise. But I prudently mentioned "the guarantee that you try to achieve", i.e the same guarantees of the CRC that Ronny's app is currently offering. In fact the TCP guarantee is already higher since at ethernet/wifi layer a CRC is checked, and on TCP level a checksum using another algorithm is used.
    – Christophe
    Commented Sep 20, 2018 at 17:30
1

The TCP checksum does not catch all errors because it is too small. It will catch most errors aber every few GBs or TBs of data sent there might be undetected corruption. The corruption will lead to different data that maps to the same CRC by coincidence.

Broken TCP data happens in practice from time to time. I guess it's rarely noticed because people expect network stuff to randomly fail sometimes. Also, random corruption is always one-off and hard to root cause.

In my opinion this is a design flaw in TCP. It causes all higher layers to either accept very rare corruption or do their own checking.

Some people will be surprised by this fact because TCP is often touted as corruption free. Not the case.

Your additional CRC might well prevent some errors. If you want really no errors at all you need a stronger checksum still (probably a cryptographic hash).

6
  • 1
    You're welcome to say it's a design flaw, but everything has trade offs. The current system works quite well enough for most communications on the internet.
    – whatsisname
    Commented Sep 20, 2018 at 17:21
  • The TCP packet has a simple checksum, yes. But it is embedded in an IP packet, which has another checksum. And which is itself embedded in an Ethernet or 802.11 wifi frame that has CRCs. This means that the whole data transferred will be CRC checked. Conclusion: TCP is not flawed, it just relies on other controls done at are lower level.
    – Christophe
    Commented Sep 20, 2018 at 18:16
  • Adding a CRC would hence make no sense. However adding a cryptographic hash could make sense because cryptography is at OSI presentation level (so higher in the protocol stack than transport). However it would be better to use it in a signature, therewith ensuring protection not only against error but intentional tampering would be a pity.
    – Christophe
    Commented Sep 20, 2018 at 18:26
  • 1
    Another CRC can make sense if it is larger or has a different polynomial. There are many kinds of CRC. See stackoverflow.com/a/3830272/122718. @Christophe
    – usr
    Commented Sep 20, 2018 at 20:11
  • Sure, but what are the odds ? The probability for an error to get undetected by a CRC32 is 1/2^32. The probability for an error to get undetected with the TCP checksum is 1/2^16. As the two calculations are independent, the probability for an error to get twice undetected is (1/2^32)*(1/2^16)=1/2^48. This figure has to be compared with the error detection rate of the sole CRC calculated previously. Was it a CRC-64 ? And is the cost of the additional calculation worth the increased error detection ?
    – Christophe
    Commented Sep 20, 2018 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.