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?
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)
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 ...
Are you able to share a capture file?
If you test with the sample file mentioned above, what are the results?
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
Is one end of the connection using port 7000?
It is. I'm guessing you would have identified the issue sooner if I'd mentioned that to begin with. Apologies
Comments