[BUG] TCP receiver connector fails with UTF16-BE encoding using double byte MLLP about connect HOT 7 OPEN

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

from connect.

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?

from connect.

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.

from connect.

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

from connect.

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

from connect.

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

from connect.

@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?

from connect.