Wireshark-users: [Wireshark-users] Statistics grouped by port?

From: Brad Johnson <bjohnson@xxxxxxxxxxxxxx>
Date: Tue, 6 Feb 2007 15:41:08 -0500 (EST)

Hello everyone - longtime Ethereal/Wireshark user, first time poster.

I'm banging my head against a wall here. I've always been thrilled with
Wireshark's in-depth statistical analysis and ways of looking at
connections. That being said, I have something very simple I want to do
and can't figure out how to do it.

Wireshark will group packets by "TCP endpoints", in other words
pairings of IP addresses and TCP destination ports. It will tell me how
many packets and bytes went IP address X on port Y. That's great
and all, but what I want to know is how many packets and bytes went to
port Y REGARDLESS of the IP. So basically a list like:

TCP.DSTPORT       COUNT      BYTES
80                9234       142352
25                448        342344
443               85         99834

and so on. I have a large packet dump of all the traffic on my network
from a short period of time, and I want to see which destination ports the
traffic was going to the most so I can do a little traffic profiling. This
seems like such a common thing that people would want to do - as advanced
as some of Wireshark's capabilities are, I find it hard to believe that it
doesn't do it. It's basically like the "Endpoints" capability but removing
the IP addresses so I don't have to manually total up the lines where the
destination port matches.

The "Protocol Hierarchy" is close, but it just seems to dump a lot of
packets it doesn't know what to do with under "Data", so that doesn't
really help me.

If Wireshark doesn't do it, are there any tools that do? I could probably
use something like Snort/BASE to import the dump file into a SQL
database and then do a SELECT tcp.dstport, COUNT(tcp.dstport) FROM dump
GROUP BY tcp.dstport, but that's a bit of a pain - especially with a large
dump file. I'm hoping Wireshark or another light-weight tool can do it
without the need for parsing the data into a SQL database first.

Thanks to anyone who can help!

Brad Johnson