Setting up your automation to produce wiretraces

One of the requirements that came up when we were setting up automation for our hybrid application was to get wiretraces for the activity to help in debugging along with the other logs that our application produced. The request would genuinely help our team and would increase the validity of our automation results. So I started the investigations.

The only knowledge I had was the name of the tool that I had to use and it was "Wireshark".

Here is some excerpt from Wikipedia about Wireshark:
"Wireshark is a free packet sniffer computer application. It is used for network troubleshooting, analysis, software and communications protocol development, and education. Originally named Ethereal, in May 2006 the project was renamed Wireshark due to trademark issues...."
For more details, go ahead and read: http://en.wikipedia.org/wiki/Wireshark

The workflow of our automation was that every hour the automation would be triggered. It would map a required network location and start running 3 test cases using HP Winrunner. It would note the time being taken to complete several actions and save the logs being produced by the application. After which, it would force reboot the system and then wait for the next run.

We had to fit in Wireshark within this workflow.

First Step
The first step in this direction was to find out the interface for which we will be monitoring the traffic. For this we used the following command:

wireshark.exe -d>>c:\interface.txt

This listed the Network interfaces along with their IDs. We identified the interface that we had to monitor and proceeded.

Second Step
The plan was to start running Wireshark through commandline interface and instruct it to save logs to a specific file. This was where we faced the first challenge. Though the Wireshark commandline has an option to start capturing logs, it does not provide a 'good-enough' option to stop capturing them. The only commandline options available in this regards are:

-c stop after n packets (def: infinite)
-a ... duration:NUM - stop after NUM seconds
filesize:NUM - stop this file after NUM KB
files:NUM - stop after NUM files

None of these suited our needs. We needed to be able to tell Wireshark to tell when to start and to stop when our automation was complete. Packet number, duration, file size or number of files was variable in our case and none of the options listed above could be reliable for us.

The method that we adopted to get across this limitation was a bit crude but worked perfectly. We setup Wireshark to capture for 3600 seconds (1 hour). After our automation had completed, we would simply kill Wireshark through commandline using the following command:

taskkill /im wireshark.exe /f

and copy the traces to a network resource.

Third Step
One 'nice-to-have' option would have been to have an embedded timestamp within the name of the wiretrace log file so that whenever we would want to analyze the log for a particular run, we would only need to look at the timestamp and know which one to look at. Since we had the automation running 24 times in a day, it would also mean that we would have a unique log file for each run.

For this, I tricked wireshark into believing that I was capturing output into a ringbuffer*. W.R.T. Wireshark, it means that after saving n number of bytes in a file, it would move to the next file and store n number of bytes in that. And so on. In this case, wireshark embeds time-stamp in the name of each ringbuffer file.

We used the following command line option to set this up:

-b duration:3600 -w c:\wiretraces\wiretrace

where -b is the duration for which 1 buffer file will be used
and -w is the common name for all buffer files in one capture.

As our automation would complete within an hour, it never went beyond one buffer file and at the end we had a buffer file with the following name:

wiretrace_00001_20090613083111

which was exactly what I wanted.

Fourth Step
The Fourth and the last challenge with this was the huge size of the trace logs. Typically, wireshark would capture all ports and protocols, which resulted in a huge amount of data that we did not need. We only needed to capture the http traffic. For this we had to set up a capture filter from the command line. Wireshark accepts the filter in 'libpcap filter syntax'. To get a suitable filter string, you can launch Wireshark and go to Capture->Capture Filters.

For HTTP, the value of the capture filter is HTTP TCP Port (80), for which the corresponding string is "tcp port http" in libpcap filter syntax. Wireshark command line option -f can be used to specify this.

The final command line option that we arrived at is:

wireshark.exe -i 2 -f "tcp port http" -k -b duration:3600 -w c:\wiretraces\wiretrace

where -i us the ID of the interface to monitor
-f is the capture filter in the libpcap filter syntax
-k instructs wireshark to start capturing immediately
-b duration:3600 intructs wireshark to capture in a ringbuffer and to move to the next file in the buffer after every 1 hour
-w is used to specify the base name of the output file

Happy Wiretracing!!!


*A circular buffer or ring buffer is a data structure that uses a single, fixed-size buffer as if it were connected end-to-end. This structure lends itself easily to buffering data streams.