 |
| Dogs can sniff hundreds of times better than humans; Sajiv, our boxer is no exception |
What is a sniffer? It is s a passive software application
that listens to network communications and captures the raw frames that are
exchanged and interprets the communication protocol that is used. In the case
of a DICOM communication, we are looking for the TCP/IP packets and DICOM
application level protocol. A sniffer is an essential tool for network and
infrastructure engineers, however, not all commercial sniffers have a DICOM
plug-in that allows for DICOM protocol interpretation. Wireshark, which used to
be called Ethereal, is an open source, free tool and does have the DICOM plug-in
as part of the basic software package.
Because a sniffer is a passive device, there is no noticeable
interaction with the devices that are to be diagnosed. Therefore, it is a great
tool to be used when there are non-reproducible issues or errors. For example,
imagine that a modality errs when sending an image to the PACS, but when you send
the same image from another device, such as a workstation or another modality,
there are no problems. And, even worse, the error might occur only once every
hour or so. Another scenario might be that the error code is not easily
interpreted, e.g. it might display something like “communication error” or
“DICOM error.” In another scenario, there could be a finger-pointing contest
going on between two vendors, each arguing that the problem lies with the other
party, and you are in the middle trying to find out who actually causes the
problem.
The nice feature of the DICOM sniffer is that it shows the
actual data going across, i.e. it provides hard evidence of what is exchanged,
including the timing, as it provides a timestamp as well. That means that it
also can be used to troubleshoot performance issues. For example, if there is a
lot of noise on the communication line causing multiple resends of corrupted
packets, or if it takes a long time for an application to reply back to a DICOM
command, this overhead is recorded and visible.
Where to run or install the sniffer could be a little bit
tricky. The best location would be to have the software run on a dedicated
diagnostic computer, e.g. a service laptop, which would connect to an active
listening port at a router or switch. A trick one could also apply is to have a
simple hub that you connect to the sender or receiver network cable and to your
laptop. However, these solutions often require approval and/or cooperation from
your IT department. Worst case, you might ask them to capture the session on
their own network sniffer and share the capture file with you to do the
analysis. Another possibility would be to run the sniffer at the source or
destination where it can be set up to listen to the sending or receiving
network adapter. The latter might
require cooperation of your vendor and/or PACS administrator.
Configuring the sniffer, capturing the file, analyzing and
saving the file is relatively easy, see the short video demo. After the analysis and/or
validation using some of the open source validation tools, one can share the
results, including the capture file with the vendors or integration engineers
so they can fix the problem or create a work-around.
In conclusion, a DICOM sniffer is an invaluable tool for troubleshooting;
especially in cases when there is limited access to log files at either the
source or destination of the exchange that has trouble. It is particularly
useful for semi-random or not easily reproducible errors, which is an essential
part of a PACS administrator’s set of tools and tricks.
