Dnp3 fails integrity poll and read analog/binary inputs

exception caught: io.netty.handler.codec.DecoderException: header CRC check failed
I see this message repeatedly in the diagnostics logs every second for the field device I have issues with as well as “fragment timer expired”
It seems that due to this CRC exception, integrity polls and reads of analog/binary inputs by the OPC server fail. In Designer, when I browse for tags on the device the Points folder is empty.

Looking at packet capture, it looks like DNP3 read input requests are met with responses all the same as field devices that are able to have their data points queried in Designer. In all the responses I can see the data objects being returned.

I’m not sure, but the occurrence of the CRC exception seems to be correlated with the number of data points configured on the field device. The issue device has 27 analog points and 13 binary points, which is more than the other working devices. I did not get this exception when the device had fewer data points configured, and the data points would show up in Designer as well.

Can you open a support ticket and send us the packet capture?

As a trial version user without a license can I get support that way?

I don’t know. If you upload a packet capture somewhere I’ll take a look anyway.

If the CRC exception is legit then it’s not really surprising that nothing works. I mostly want to see if there’s a bug causing it to fail when it shouldn’t.

Can you also go to the logs page in the Ignition gateway (Status section, Logs) and export/download the logs and send those in as well?

Would it be fine to just email to support@inductiveautomation.com?

Sure. I saw your Wireshark capture. For the device you said had the CRC exception it looks like you started the Wireshark capture after the integrity poll happened.

Start the capture, then edit/save the device in the Ignition gateway, then after enough time has passed stop the capture and get the log export.

I don’t fully understand what’s going wrong yet but Wireshark also shows it as a malformed packet, which isn’t usually a good sign:

Did you ever find a resolution to this issue?