Bad_TcpMessageTooLarge When Connecting to Edge OPC-UA server

[fshriver]

Hi,

So we're trying to figure out deploying Ignition Edge via Balena. We have a situation where we have the official Ignition Docker image running as one container, and then another container we'd like to pull specific status tags from the Edge OPC-UA server via the internal bridge interface Balena provides. However, when we try to spin up the two containers, we see the following issue:

The following is the error logged during one of these events:

io.netty.handler.codec.DecoderException: UaException: status=Bad_TcpMessageTooLarge, message=max message length exceeded (16777639 > 4128)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:499)
	at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:426)
	at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:393)
	at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:376)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:301)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)
	at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)
	at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:813)
	at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.eclipse.milo.opcua.stack.core.UaException: max message length exceeded (16777639 > 4128)
	at org.eclipse.milo.opcua.stack.core.channel.headers.HeaderDecoder.getMessageLength(HeaderDecoder.java:39)
	at org.eclipse.milo.opcua.stack.server.transport.uasc.UascServerHelloHandler.decode(UascServerHelloHandler.java:102)
	at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)

There are no issues when we have Edge and the program running in the same instance (so they both have access to localhost), in that situation we're able to connect to the OPC-UA server no problem. But Ignition really doesn't seem to like Balena's bridge interface; we try to bind the endpoint to Balena's internal service name and it will reject it. Is this a known issue/is there a workaround?

[pturmel]

Does the bridge interface show an MTU (max transmission unit) size on the operating system side? If not (or not reasonable), can one be forced?

[Kevin.Herron]

I don’t know what Balena is, but I’ve seen this error before when something that isn’t an OPC UA client tries to connect and send messages to the Ignition OPC UA server.

[fshriver]

Balena is an IoT device container deployment service (Core Concepts - Balena Documentation). They're built on Docker, so we are using the Docker version of Ignition (Docker Image - Ignition User Manual 8.1 - Ignition Documentation). And we're trying to use the asyncua library (GitHub - FreeOpcUa/opcua-asyncio: OPC UA library for python >= 3.7) to connect to the OPC-UA server within Ignition.

I have a hunch that the issue comes from Ignition and Balena not seeing eye-to-eye on how local connections are established? Outside of a container, on a normal workstation for example, when we use asyncua to connect to an Ignition service running locally, we can talk to the OPC-UA server using localhost just fine. However, since Balena assumes you have multiple services running and uses localhost itself, what they do is set up a bridge interface with an IP address space common across all containers. Then, when a service wants to communicate with another service, they can just use the name of the service (which resolves via DNS to the service's IP address in that common bridge interface). But I think the Ignition container still strictly assumes use of localhost. Apparently SOMETHING is still getting through, if Ignition still sees the request. Any guidance that can be offered by the Docker team/person?

[Kevin.Herron]

In a "normal" docker setup changing the Bind Address to 0.0.0.0 (requires a restart to take effect) and mapping host port 62541 to container port 62541 allows a connection from UaExpert from the host using endpoint URL opc.tcp://localhost:62541/discovery.

[fshriver]

Is that under Config > OPC UA Settings? I don't see the options for bind port or bind address on my side. We're using the Edge version, btw. All I see is the following:

[Kevin.Herron]

Mmm, in older versions of Edge you needed to have the "IIoT" plugin licensed or something like that.

Starting a few versions back all of the Edge licensing got simplified and now there's just 2 versions, and I think you are allowed external client connections by default.