[Dshield] Traffic comparison - looking for tools

gentuxx gentuxx at gmail.com
Thu Jun 2 05:17:21 GMT 2005


On Wed, 2005-06-01 at 12:58 -0600, Josh Tolley wrote:
> Hi, all -
> 
> I'm trying to track down a problem with a client-server application 
> where the app quits responding periodically. After some investigation, 
> it appears the problem might be caused by dropped packets, though since 
> the communication is TCP, and TCP is supposed to handle that kind of 
> thing, I can't be too sure. I'd like to set up a sniffer at the client's 
> site and one at the server, and just compare to see if what gets sent 
> matches what is received.
> 
> So a couple of questions:
> 
> 1) Is there a better way? If the problem is due to lost packets, and if 
> the packets are being lost in some malfunctioning/congested router 
> somewhere, I can't count on getting ICMP messages about them, so I can't 
> look at that. I can't think of too many other options.
> 
> 2) Any suggestions as to software I can use to compare these two traffic 
> streams? My first thought was just load both client- and server-side 
> captures in Ethereal, look for connections that were reported as having 
> frozen, find the corresponding stream in the other capture, and see if 
> all the packets that the client sent actually got there. This will 
> definitely be time-consuming, but I don't know of other options.
> 
> I'd appreciate any suggestions that can be given. I'm getting the 
> distinct impression, just because of the sheer amount of work I think 
> I'm setting myself up for, that there must be an easier way I'm just 
> missing. Thanks...
> 

As for tools, (t)ethereal and/or tcpdump is going to be you're best bet
(as far as I know).  Personally, I would output the dump to text (or
redirect if using tcpdump) and write something in perl to parse the
results.  The sequence numbers should be your key to matching packets.
Also, if you output in text, you can merge(cat)->sort->uniq (or some
combination thereof) on a *nix box and you should have a fairly readable
sequence of packets to try to decipher the problem.

-- 
gentux
echo "hfouvyAdpy/ofu" | perl -pe 's/(.)/chr(ord($1)-1)/ge'

gentux's gpg fingerprint ==> 34CE 2E97 40C7 EF6E EC40  9795 2D81 924A
6996 0993
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.dshield.org/pipermail/list/attachments/20050602/a5846fbe/attachment.bin


More information about the list mailing list