PACS Administrator Tools and Tricks of the Trade: Using a DICOM Sniffer



Dogs can sniff hundreds of times
better than humans;
Sajiv, our boxer is no exception

A DICOM sniffer is an essential tool to troubleshoot DICOM connectivity issues for any PACS administrator, service, integration and biomed engineer. It is not something that one needs to use on a daily basis, but for the trickier and difficult-to-diagnose issues.

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.