HL7 Sniffer Revisited
Ron Sweeney on 2009-11-02 22:58:54 UTC
I actually had to use this so I took it out and cleaned it up a little bit… also checking out the gist embed functionality.
IKVM creates C# 'Bizarro' version of LightHL7Lib
Ron Sweeney on 2007-07-29 10:39:00 UTC
&t_Here’s how to convert Litherlands (or any other JAVA library to C# for use in your applications)._
Go get IKVM , and unzip it to c:ikvm on your Winders Box.
Go get LightHL7Lib and you might as well get IntegrateLib from
NULE.ORG .
Compile Mike’s stuff from within NetBeans to get your pipin’ hot LightHL7Lib.jar and your IntegrateClientLib.jar.
Put both of those .jars in c:ikbmin.
Run this command first for just the HL7Light Client Lib:
First, bask in the glory of your LightHL7Lib.dll for inclusion in your new C# project. Then include that .dll for use with Integrate like below…
Then, include the .dlls you created, plus the IKVM .dlls in your project and you are up and running! Cool eh?
;a href=”http://www.clubpacswestmi.net/HL7Lightcsharp2.png”>
woot!!!
Troubleshooting DICOM with Ethereal
Ron Sweeney on 2005-11-26 10:18:05 UTC
Getting down and dirty with DICOM on the wire can be helpful in spotting problems between modalities and systems, and also be an educational plight into DICOM communications. When you are troubleshooting connections nothing beats a raw look at what is going on in the network, despite what the shells and GUIS are telling you. Tcpdump and Ethereal provide this visibility.
This tutorial will be split into two parts. One, a simple look into the use of tcpdump and patching tcpdump to become DICOM “aware.� Secondly, take a look at using the industry standard, Open Source, network analysis tool Ethereal.
Part One: Meet tcpdump and modify it to your needs
In its simplest form, you can simply type tcpdump at a command/shell prompt and it’ll start spewing traffic onto the screen on most Linux or BSD based systems. For purposes of this tutorial, we are going to take a look at simple DICOM transactions on how you can see what is going on through the use of tcpdump. But first, lets get tcpdump, and patch it with David Clunies magic ( http://www.dclunie.com/dicom-tcpdump/ ) to make it “dicom aware.â€?
Below, we are going to:
1. Grab the software 2. Grab David's patch for the software 3. patch the software 4. build and install it
Click Image to Enlarge
Easy money right? Woot!
On to actually using it…
Now I want to show you some very basic functionality of tcpdump.
Advice to you is that you get some quick background of sniffing on a network before you get started, but it should go without saying that you are going to have to be running tcpdump on a hub that is between the devices you wish to see traffic, or a spanned port on a switch that broadcasts all traffic to the port you are sniffing on.
As an example, let’s say we want to sniff the traffic from Paul Nagy and Michael Warnock’s example from Tutorial #1.
1. Setup a listener on one host (192.168.23.3):
Click Image to Enlarge
2. Get tcpdump setup between the hosts:
The following command line will give us all tcp traffic between the host 192.168.23.3 and 10.101.0.3.
Click Image to Enlarge
3. Send something to it from another host (10.101.0.3):
Click Image to Enlarge
4. Check out the network dump
Click Image to Enlarge
The dump on the left is our “patched� version of tcpdump showing the output. We captured the entire conversation of the FreeBSD laptop, 10.101.0.3 sending images to the inferior Micorosoft Windows DICOM listener, 192.168.23.3. In case you were wondering what you would see without it being patched, I ran the dump concurrently with the unpatched version on the right.
As you can see, you have plenty of information telling you about the transfer of the images to the receiving host. You can clearly see tcp responses, AETITLES, ports, SOP Class information, SCP and SCU roles and even header information.
Thank you David!
Part Two: Using Ethereal to analyze DICOM
Ethereal has become a staple Open Source Network Analysis Tool. Ethereal is used by network professionals around the world for troubleshooting, analysis, software and protocol development, and education. It runs on all popular computing platforms, including Unix, Linux, and Windows.
I am going to quickly show you how to use Ethereal to take a peak at your DICOM transactions, and how to use it guage the performance of your PACS.
Ethereal without a whole lot of customization can get the information you want, if you know what you are looking for. Just drop it between devices on a tap or hub, span a port on a switch, get your capture and start the analysis. However, this is where the dissectors come in handy. The DICOM dissector for Ethereal was written by Richard Coe to get a more concise look at the DICOM communication by applying filters or colorization to your captures, rather than sifting through enormous amounts of data to see what you may need to see. The illustration below shows an example of how to set up colorization in Ethereal for use in PACS. If you would like a sample of the xml configuration file to import into Etheral click here.
Click Image to Enlarge
Once you have the Display filters all set, you can now quickly get to the “meat and potatoes� of the DICOM communication and get to work at inspecting the data. Simply applying the display filter on your current capture and look for the colorizations. Below shows a simple capture, with the dissector applied. Notice that you can quickly see the complete DICOM store operation in its entirety for review.
Click Image to Enlarge
Another very useful function of Ethereal is the ability to look at network traffic in time-sequence fashion and provide information about the speed and performance of the network connections in question. Take a look at the throughput and trace graphs generated by two transactions. Each transaction was sent from the same SCU, with the exact same study, but sending to two different SCP servers. A dcm4jboss (http://dcm4che.sourceforge.net/ ) archive running on a Windows based PC and Osirix( http://homepage.mac.com/rossetantoine/osirix/Index2.html ) running on a MAC respectively. Very quickly we can make a deduction that the transaction to the Osirix SCP maintained a higher throughput for the transaction than the Windows based dcm4jboss SCP. Visually we can see subtle “stepping� in the trace graph with dcm4jboss, whereas we see a gradual and smooth representation of the data transmission to the Osirix box. As a general rule of thumb, “stepping� in trace graphs represent periods of time where transmission is not occurring and waiting for host response on either side.
Click Image to Enlarge
To re-iterate these functions again, take a look at the following graph. This was a transfer of a 100MB CT study, over a wireless connection, and tunnelled through ssh. What you want to pay attention to in the graphs you generate on transfers of large data is that the frames over time go gradually upward. It would be problematic if the transfer looked a lot like stairs with horizontal stalls, this is an indication that perhaps the window size is not large enough, and the window is filling up causing the sender to have to stop and wait before sending any more. However the case in the below graph looks pretty good (considering the transport!).
Click Image to Enlarge
Another nice feature is the throughput graph, which shows where in your data stream is transferring the most data. In the throughput graph below, you can see the average transfer rate was about 5MB/s over the entire 150 second transfer.
Click Image to Enlarge
Authors: Ron Sweeney on 12/10/2004
References: tcpdump ( http://www.tcpdump.org )
Ethereal ( http://www.ethereal.com )
David Clunie ( http://www.dclunie.com )
