# Bad\_TcpMessageTooLarge When Connecting to Edge OPC-UA server **URL:** \ **Category:** Ignition\ **Created:** [December 26, 2023, 5:24am UTC](https://forum.inductiveautomation.com/t/bad-tcpmessagetoolarge-when-connecting-to-edge-opc-ua-server/83509 "2023-12-26T05:24:17Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![fshriver](https://avatars.discourse-cdn.com/v4/letter/f/db5fbb/32.png) [@fshriver](https://forum.inductiveautomation.com/u/fshriver)\ **Post date:** [December 26, 2023, 5:24am UTC](https://forum.inductiveautomation.com/t/bad-tcpmessagetoolarge-when-connecting-to-edge-opc-ua-server/83509/1 "2023-12-26T05:24:17Z")
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: ![Screen Shot 2023-12-25 at 21.06.16](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/a/fa2135893454fae175ddc1b5228cdf88ff388116.png) The following is the error logged during one of these events: ```auto 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? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 26, 2023, 12:51pm UTC](https://forum.inductiveautomation.com/t/bad-tcpmessagetoolarge-when-connecting-to-edge-opc-ua-server/83509/2 "2023-12-26T12:51:23Z")
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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [December 26, 2023, 1:11pm UTC](https://forum.inductiveautomation.com/t/bad-tcpmessagetoolarge-when-connecting-to-edge-opc-ua-server/83509/3 "2023-12-26T13:11:34Z")
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. ---
**Author:** ![fshriver](https://avatars.discourse-cdn.com/v4/letter/f/db5fbb/32.png) [@fshriver](https://forum.inductiveautomation.com/u/fshriver)\ **Post date:** [December 26, 2023, 3:18pm UTC](https://forum.inductiveautomation.com/t/bad-tcpmessagetoolarge-when-connecting-to-edge-opc-ua-server/83509/4 "2023-12-26T15:18:03Z")
Balena is an IoT device container deployment service ([Core Concepts - Balena Documentation](https://docs.balena.io/learn/welcome/primer/)). They're built on Docker, so we are using the Docker version of Ignition ([Docker Image - Ignition User Manual 8.1 - Ignition Documentation](https://docs.inductiveautomation.com/display/DOC81/Docker+Image)). And we're trying to use the `asyncua` library ([GitHub - FreeOpcUa/opcua-asyncio: OPC UA library for python \>= 3.7](https://github.com/FreeOpcUa/opcua-asyncio)) 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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [December 26, 2023, 3:32pm UTC](https://forum.inductiveautomation.com/t/bad-tcpmessagetoolarge-when-connecting-to-edge-opc-ua-server/83509/5 "2023-12-26T15:32:05Z")
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`. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/8/28827c49882efc2cdf280b4b9c1f95332dd135df.png) ---
**Author:** ![fshriver](https://avatars.discourse-cdn.com/v4/letter/f/db5fbb/32.png) [@fshriver](https://forum.inductiveautomation.com/u/fshriver)\ **Post date:** [December 26, 2023, 3:48pm UTC](https://forum.inductiveautomation.com/t/bad-tcpmessagetoolarge-when-connecting-to-edge-opc-ua-server/83509/6 "2023-12-26T15:48:10Z")
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: ![Screen Shot 2023-12-26 at 09.47.52](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/2/425f90e60c1b0af6c43834f4c4aa57fbbb85689f.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [December 26, 2023, 4:03pm UTC](https://forum.inductiveautomation.com/t/bad-tcpmessagetoolarge-when-connecting-to-edge-opc-ua-server/83509/7 "2023-12-26T16:03:31Z")
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.