[BUG] TCP receiver connector fails with UTF16-BE encoding using double byte MLLP

[cmongolang]

Describe the bug TCP receiver connector fails to receive UTF16-BE data when the MLLP start / end sequence is double byte.

To Reproduce

1. Create a sending connector with outgoing encoding UTF16-BE
2. set MLLP start sequence to 0x 00 0b ; end sequence to 0x 001C 000D
3. create a receiving connector with same encoding and MLLP settings
4. Send an HL7 message between the two connectors

Expected behavior The message should be interpreted as UTF16-BE

Actual behavior A blank message is received, and an error is recorded "Unable to parse, message is null or too short: " Screenshots capture_UTF16-BE-_default_MLLP.zip UTF16 Test-channel_Group.zip

Environment (please complete the following information):

• OS: Windows server
• Java Distribution/Version Seen on Java 11 and 21
• Connect Version 4.4.2

Additional context Double byte MLLP is required for Draeger Infinity Gateway unicode (UTF-16) HL7 interfaces It also fails using TCP transmission mode.

[pacmano1]

I thought MLLP simply does not support multi-byte start and end delimiters, although the message itself can be UTF-16. Are you saying if you send an UTF-16 message with standard single byte delimiters it fails?

[cmongolang]

With default MLLP settings, start and end sequence are sent as single byte and it works tested as above (Mirth to Mirth). However the software I'm connecting to uses double Byte MLLP when Unicode option is activated.

[pacmano1]

Got a link to that software documentation? Got a wireshark capture of the gateway itself? Curious.

[cmongolang]

Captured_ORU_Draeger_Unicode.zip Here is a capture between Draeger sim tools running in unicode mode.

[ab-mg-23]

What ends up happening is Mirth is seeing the packet as two messages, one an empty message, 00 0b 00 and the other as a malformed message 4d 00 53 .... I was initially confused because it looked like Mirth was getting UTF-16LE and I couldn't figure out why it appeared to be dropping 00 0b 00.

The FrameStreamHandler isn't properly checking the endBytesBuffer is actually the same size as the endOfMessageBytes before comparing them. In this case Mirth sees 00 0b as the start frame correctly. However, since 00 is the next byte in the stream it causes the following loop to always be true. The first byte of the end frame will be 00 but the buffer isn't a full 4 bytes. https://github.com/nextgenhealthcare/connect/blob/b38b2a1d1369f20a1164c0cac10652cfa9c7a442/server/src/com/mirth/connect/model/transmission/framemode/FrameStreamHandler.java#L162C10-L179

[lmillergithub]

@cmongolang We were successful in using the UTF-16LE where the nulls are after the start and end characters. Is it possible to use that instead of UTF-16BE with Draeger Infinity Gateway?

[lmillergithub]

We have found a solution for this problem. I will let you know when we are able to publish it.