Wrapper Log: Subscription transfer failed

This is for Ignition 8.1.2

I am seeing a lot of entries in my wrapper log file of

INFO | jvm 1 | 2023/03/18 00:47:00 | I [c.i.i.g.o.c.c.OpcUaConnection ] [04:46:59]: Subscription transfer failed, id=2426678631, status=StatusCode{name=Bad_UserAccessDenied, value=0x801F0000, quality=bad} connection-name=ASC06LS

As well as things like

INFO | jvm 1 | 2023/03/18 00:47:00 | I [c.i.i.g.o.c.c.OpcUaSubscriptionModel] [04:47:00]: ResendData for subscriptionId=2 failed: StatusCode{name=Bad_MethodInvalid, value=0x80750000, quality=bad} connection-name=ASC33LS

What do these sorts of entries imply? I tried searching for an explanation but I seemed to have failed at that.

I suspect that something bad is happening, but I'd to narrow down where I should be looking.

These are separate failures.

The first is happening after a reconnect when we try to transfer the old subscriptions to the new session. The server is rejecting the request with Bad_UserAccessDenied... not uncommon if you are connected anonymously, and if you have configured credentials then it's up to the server if it's allowed. This is ultimately fine because we just create a new subscription if the transfer fails. It's not uncommon for this to fail as many servers don't support it or can't complete the transfer because the connection was lost while it was restarted or something.

The other message means at some point the server delivered notifications with a gap in the sequence number, we tried to recover them using the Republish mechanism, that failed, we then called the ResendData method to get current values for all MonitoredItems, and that also failed, because it looks like this server may not support it.

1 Like

OK .. all of these connections are to Rx3i PLCs with no credentials and implicit trust of the out of date certificates installed on them :roll_eyes:

In both cases would it be fair to say that one possible reason could be network issues?

I'm not sure if this entry also plays into that, or if it is another issue altogether:

INFO | jvm 1 | 2023/03/18 04:04:34 | E [o.e.m.o.s.c.t.u.UascClientMessageHandler] [08:04:34]: [remote=/172.25.9.20:4840] Exception caught: An existing connection was forcibly closed by the remote host
INFO | jvm 1 | 2023/03/18 04:04:34 | java.io.IOException: An existing connection was forcibly closed by the remote host

Could be a network issue, could be that someone did a program or configuration change or "download" to the PLC and that causes the server to restart.

That is also entirely possible. As I shouldn't see continual downloads, so I'm going to have to do some log analysis to see if I can figure out a pattern.

If the connections are unsecured, or can be modified to be unsecured, then a long running Wireshark capture to go along with the logs may help.

Yeah, but my Wireshark cable won't stretch to China :rofl:

But that is something to keep in mind for when a FE is on site.

1 Like