CIPSafety and Bad CRCs

asked 2022-01-25 16:09:45 +0000

updated 2022-01-26 13:34:20 +0000

Hi,

I'm using Wireshark to capture the CIPSafety packets between an Allen-Bradley PLC and a valve control board. After a little while Wireshark shows all of the packets from the PLC as having CRC-S5 incorrect. If the target thought the CRC was bad I would expect it to drop the connection but it doesn't. This makes me think there might be something wrong in the Wireshark CRC verification or maybe I have something configured wrong?

I tried upgrading to the latest release of Wireshark (3.6.1) but I still get the same error.

I have a capture showing the problem but I can't upload due to my newbie karma. You can download it from here: https://drive.google.com/file/d/1eX3H...

Here's a raw packet dump of one of the messages that shows the CRC error in Wireshark:

0000: 00 a0 91 2f 0d 71 5c 88 16 b9 84 ef 08 00 45 ac

0010: 00 35 96 fc 00 00 40 11 5e 9e c0 a8 01 25 c0 a8

0020: 01 fc 08 ae 08 ae 00 21 eb af 02 00 02 80 08 00

0030: 82 00 ad 80 fc 5b 00 00 b1 00 07 00 01 87 66 44

0040: c2 04 64

Has anyone else seen this? Any idea what's wrong?

Thanks, Phil

edit retag flag offensive close merge delete

Comments

You can upload your capture file to a public share and then post a link to it back here.

grahamb ( 2022-01-25 16:52:44 +0000 )edit

Good point! Here is the link: https://drive.google.com/file/d/1eX3H...

prittenhouse ( 2022-01-25 18:17:35 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2022-01-26 19:52:42 +0000

daulis
1 ●1

It's a known issue. I logged this a couple years ago: https://gitlab.com/wireshark/wireshar...

I started refactoring that area to clean things up, specifically to help with the actual fix of that problem. But, I never finished it. I'll try to revisit this, when I get a little more time.

edit flag offensive delete link

Comments

Thanks, it's good to know it's not a problem on our end :-)

prittenhouse ( 2022-01-27 13:43:43 +0000 )edit

I fixed this, so it will be in the next major Wireshark release (4.0)

daulis ( 2022-04-22 02:01:05 +0000 )edit

add a comment

answered 2022-01-26 16:12:44 +0000

Chuckc
2858 ●5 ●567 ●19

updated 2022-01-26 20:02:27 +0000

Update: known issue (14939 - CIP Safety: CRC check is incorrect when timestamp rolls over to zero)

There has been work in this area but maybe needs more:
3818 - CIP Safety: Update CRC S5 Logic

The supplied capture can be trimmed with cip.connection == 1

cipsafety.crc_s5.status == "Bad" occurs when the timestamp rolls (cipsafety.timestamp == 0) to exactly 0. It rolls several times before this but not with a timestamp of 0.
(coincidence ?)

frame.number == 211809 (Good)
No. Time    Source  Destination Length  Protocol    Total Length    CRC S5 Status   Timestamp   CIP Connection Index    Info
211809  163.544275  192.168.1.37    192.168.1.252   67  CIP Safety  53  Good    65490   1   Connection: ID=0x80AD0082, SEQ=0000023521, O->T

frame.number == 211817 (Bad)
211817  163.550496  192.168.1.37    192.168.1.252   67  CIP Safety  53  Bad 0   1   Connection: ID=0x80AD0082, SEQ=0000023522, O->T

edit flag offensive delete link

Comments

Thanks! Much appreciated

prittenhouse ( 2022-01-27 13:44:53 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

CIPSafety and Bad CRCs

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

CIPSafety and Bad CRCs edit

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

CIPSafety and Bad CRCs