Message: "Received chunk with wrong sequence, spec says to close connection

[smueller48]

I am using a freeopcua python script (v 0.98.10) to read data from an OPCUA server. The script runs fine for hours and days, but then often stops with a message similar to this one:

opcua.ua.uaerrors._base.UaError: Received chunk: MessageChunk(Header(type:b'MSG', chunk_type:b'F', body_size:100, channel:3876308278), SequenceHeader(SequenceNumber:255538, RequestId:255489 ), SymmetricAlgorithmHeader(TokenId:104 ), 50 bytes) with wrong sequence expecting: 255536, received: 255538, spec says to close connection Protocol Error

What could the reason for this error? Is it connected to network problems (latency)? My colleagues tell me that the server is not showing problems.

How would I catch the corresponding exception in Python? My usual approach is to wait 60 seconds (in case the server got rebooted) and reinitialize the connection, but with this error, my script just hangs (a KeyboardInterrupt is however caught, so I can do 'Ctrl-C' whenever I notice that the script is hanging, and it will reestablish the connection).

Any ideas will be appreciated, I can also provide more information if needed.

Upfate: It happened again - here is the error message and traceback:

opcua.ua.uaerrors._base.UaError: Received chunk: MessageChunk(Header(type:b'MSG', chunk_type:b'F', body_size:100, channel:345215105), SequenceHeader(SequenceNumber:431413, RequestId:431414 ), SymmetricAlgorithmHeader(TokenId:173 ), 50 bytes) with wrong sequence expecting: 431411, received: 431413, spec says to close connection
Protocol Error
Traceback (most recent call last):
File "/home/muelle94/elbe_test/python/lib/python3.6/site-packages/opcua/client/ua_client.py", line 101, in _run
self._receive()
File "/home/muelle94/elbe_test/python/lib/python3.6/site-packages/opcua/client/ua_client.py", line 112, in _receive
msg = self._connection.receive_from_socket(self._socket)
File "/home/muelle94/elbe_test/python/lib/python3.6/site-packages/opcua/common/connection.py", line 338, in receive_from_socket
return self.receive_from_header_and_body(header, ua.utils.Buffer(body))
File "/home/muelle94/elbe_test/python/lib/python3.6/site-packages/opcua/common/connection.py", line 310, in receive_from_header_and_body
return self._receive(chunk)
File "/home/muelle94/elbe_test/python/lib/python3.6/site-packages/opcua/common/connection.py", line 341, in _receive
self._check_incoming_chunk(msg)
File "/home/muelle94/elbe_test/python/lib/python3.6/site-packages/opcua/common/connection.py", line 290, in _check_incoming_chunk
raise ua.UaError("Received chunk: {0} with wrong sequence expecting: {1}, received: {2}, spec says to close connection".format(chunk, self._peer_sequence_number, num))
opcua.ua.uaerrors._base.UaError: Received chunk: MessageChunk(Header(type:b'MSG', chunk_type:b'F', body_size:196, channel:345215105), SequenceHeader(SequenceNumber:431414, RequestId:431412 ), SymmetricAlgorithmHeader(TokenId:173 ), 142 bytes) with wrong sequence expecting: 431411, received: 431414, spec says to close connection

[martinkaru]

Having the same issue with an Advantech module

[martinkaru]

Found a solution.

await client.load_data_type_definitions() loads the structure of the OPC UA server.
In some cases, my OPC UA server failed to serve the certificate.
Fix: don't run await client.load_data_type_definitions()

[AndreasHeine]

somehow there are messages missing see sequencenumbers.... looks like networkissue on the first look!

[martinkaru]

The systems are in the same subnet; the connection works from the PC with other software AND I have a previous version of my solution which already uses python-opcua async and everything works (same lib versions even).
In my working solution, there is no load_data_type_definitions() - removing this command is a "fix"

Actual reason: the OPC UA server gets hung up from time-to-time - somewhat stupid/basic device.
It also hangs up when I use the official .NET tool. Clicking around in the UI, sometimes the certificate page loads, sometimes it raises an Exception.