BadTcpMessageTypeInvalid

BadReverse connect

What you actually see

A server configured for reverse connect logs repeated rejections from the client address and stops retrying, while the client shows an unexpected message on its listener port.

Why it happens

• The client does not support reverse connectIn reverse connect the server dials the client and sends a ReverseHello, and the client answers with the normal Hello on the same socket. A client that does not implement this returns BadTcpMessageTypeInvalid, and per specification the server must then abort auto-reconnect.
• The client is deliberately telling the server to stopBecause the specification requires the server to abort on this code, clients can use it intentionally as a stop signal - for example when they no longer want reverse connections from that server. Seeing it is therefore not always a defect.
• Something other than an OPC UA client is on the portThe server dialled a client listener - commonly 65300 - and reached an HTTP service, a health checker or a load balancer probe instead. The bytes are not a valid UACP message, so the type check fails.
• Message types sent out of order on the handshakeA Hello arriving on an established channel, or a MSG frame before the Acknowledge, is refused this way. Hand-written or partially implemented transport code hits this first.
• Transport mismatch on the URLPointing opc.tcp at a WebSocket or HTTPS listener - for example 4843 rather than 4840 - delivers UACP bytes into a framing that does not expect them. Reverse connect is supported for opc.tcp only in OPC Publisher, for instance.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Confirm the client actually supports reverse connectCheck the client's documentation and configuration for a reverse-connect listener. If it has none, the server's outbound attempts can never work; use a normal outbound client connection or a gateway that does support it.
2. Verify the listener port and what is on itOn the client host, ss -ltnp for the reverse-connect port - 65300 is a common choice, and OPC Publisher listens on 4840 by default with --rcp to change it. Make sure no other service holds that port.
3. Match the endpoint URL exactlyThe endpoint URL in the ReverseHello must match exactly the URL used to create the client. If the server uses a short hostname, do not configure the FQDN on the client side either.
4. Expect the secure-connect two-stepTo connect securely the client must call GetEndpoints to fetch the server certificate, and doing so closes the channel. It must then wait for the server's next ReverseHello before connecting with the cached security information. Naive implementations look like they connect and immediately drop - that is normal, not a fault.
5. Register per server and endpoint on one listenerOne client-side listener port can serve many servers; clients register per serverUri and endpointUrl. A LISTENING socket that persists after a session is established is expected behaviour, not a leak.

Where it shows up, by tool and stack

What it looks like in the log

Reverse connect to 10.30.1.8:65300 rejected with BadTcpMessageTypeInvalid; aborting automatic reconnect
Received unexpected message type on established channel; expected MSG
ReverseHello sent to client listener; waiting for Hello

Confirm the fix

Confirm the client answers the ReverseHello with a Hello and that a secure channel and session follow. For a secure connection, expect one endpoint-fetch cycle to close the channel before the next ReverseHello succeeds.

Stop it happening again

Choose clients with documented reverse-connect support before designing around it, pin the listener port in the firewall rules, and store the server's advertised endpoint URL as the client's configured URL verbatim.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.