search

nextgenhealthcare / connect

The swiss army knife of healthcare integration.
Other
929 stars 280 forks source link

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

Open cmongolang opened 10 months ago

cmongolang commented 10 months ago

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 receiver-double_Byte MLLP_Appears_correct_but_FAils MLLP_Appears_correct_but_FAils_end capture_UTF16-BE-_default_MLLP.zip UTF16 Test-channel_Group.zip

Environment (please complete the following information):

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

pacmano1 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

cmongolang commented 10 months ago

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

ab-mg-23 commented 10 months ago

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 commented 9 months ago

@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 commented 9 months ago

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