Ask Your Question
0

HL7 not detected unless sent on port 2575

asked 2022-04-08 21:52:34 +0000

sk_sk gravatar image

Not sure when this began to happen but the hl7 protocol isn't detected unless it's being sent on port 2575 (iana registered port). This is happening on Windows and *nix. I have previously (in 2019 is when I can last verify it) been able to sniff HL7 traffic regardless of which port is being used. is this something to do with the dissector or is there a setting in Wireshark that needs applying?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-04-09 04:28:42 +0000

Chuckc gravatar image

HL7 will look for traffic on the defined port (Default: 2575 or other if set in the HL7 preference) and also has a heuristic dissector.

If another heuristic dissector eats the packet first then the HL7 dissector doesn't get a shot at it.
I can recreate this by enabling the dissector for rdmnet_tcp which is disabled by default.
packet-acn.c:

  heur_dissector_add("tcp", dissect_rdmnet_over_tcp_heur, "RDMnet over TCP (Broker, RPT, EPT)", "rdmnet_tcp", proto_acn, HEURISTIC_DISABLE);

If I then disable rdmnet_tcp, HL7 dissects on a non-standard port.

A quick check would be to create a new profile (which will have Default settings) then exit and restart Wireshark.
Verify that the new profile is being used (right end of status bar) and then open the capture with HL7 traffic.

(Sample capture attached to 12906: HL7 protocol support)

edit flag offensive delete link more

Comments

Thanks for the quick response! I checked the settings under Analyze > Enabled protocols There were no other heuristic dissectors enabled. I've gone through manually disabling all the protocols to try and discover which ones are having an effect on the output. I found that disabling "gryphon" meant that hl7 ack messages replying to messages sent on non-standard ports appeared however, I was not able to find a protocol that when disabled meant ADT messages sent on non-standard ports appeared. The only protocols that remain enabled are:

CC

CC.ECHO

CC.NEW

Commercial Security

Echo

Echo reply

End of Option List (EOL)

End of Options List (EOL)

Ethernet

Experimental

Extended Security

G.723

GCSNA

GLOW

GlusterFS

GNW

GOOSE

Gopher

GPEF

IPv4

Loose Source Route

Maximum segment size

MTU Probe

MTU Reply

No Operation (NOP)

No-Operation (NOP)

Quick-Start - IP

Quick-Start - TCP

Record Route

Riverbed Probe

Riverbed Transparency

Router Alert

SACK ...(more)

sk_sk gravatar imagesk_sk ( 2022-04-09 15:30:26 +0000 )edit

Are you able to share a capture file?
If you test with the sample file mentioned above, what are the results?

Chuckc gravatar imageChuckc ( 2022-04-09 15:50:08 +0000 )edit

So it turns out it was Gryphon causing the issue. I started with a fresh profile and disabled that first and all works as expected now. I think I must have been disabling and enabling too much at a time and caused other issues.

Thanks for your assistance on this

sk_sk gravatar imagesk_sk ( 2022-04-09 21:40:49 +0000 )edit

Is one end of the connection using port 7000?

Chuckc gravatar imageChuckc ( 2022-04-09 22:00:22 +0000 )edit

It is. I'm guessing you would have identified the issue sooner if I'd mentioned that to begin with. Apologies

sk_sk gravatar imagesk_sk ( 2022-04-10 07:05:32 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2022-04-08 21:52:34 +0000

Seen: 704 times

Last updated: Apr 09 '22

Related questions