Chris Wilson wrote:
It does not necessarily have to be 24/7. To implement bandwidth usage
alarms, it would have to be, and I guess that is the "network
monitoring" scenario. However, I'm also thinking about a tool that can
be run when you discover that there is a bandwidth problem, to help you
find out what it is, and then shut down until it's needed again. This is
probably the way that every packet sniffer is used.
Ack (not for me personally, but I understand the scenario)
It would also be good to support continuous monitoring. I think it would
make Ethereal more stable to have it manage its memory usage so that it
does not grow indefinitely while capturing. Somebody else suggested the
idea of capturing to an in-memory ring buffer, and it's already
supported to capture to ring buffers on disk, and capture indefinitely.
If Ethereal leaks memory due to session tracking, it defeats the point
of these features.
Agreed, but finding and fixing all these places might be quite difficult
and a *lot* of effort (... in a million lines of code). If you want to
you're free to provide patches ...
After thinking about it again, it boils down to:
Currently, Ethereal presents the details on the screen and can provide
you with more general information in the Statistics menu (which is very
hard to find for a newbie - and sometimes even me :-)
When I understand you correct, you suggest to bring some "basic network
facts" (top talkers, ...) more up to the front of the GUI for everyone
to see.
Yes, and make it very easy to use these lists as filters, to graph by
them, to show total traffic and filtered traffic in the graphs, and to
filter out local traffic.
That's probably "only" a usability task which most people would agreed
that should be improved. Hopefully no big discussion on this.
While some of your ideas sounds good at a second thought, others might
not be such a good idea anyway or really hard to implement.
Which ones?
I don't see a real point in separating ingoing and outgoing traffic in
the packet list. What is the benefit of having two packet lists splitted
into the direction. It might be an idea to specially mark the current
local address(es) in the packet list output. Or do I misunderstand you here?
You may mean to identify the ingoing / outgoing direction by the current
interface selection. There's a problem: if you change your location this
information is gone and won't be saved in the capture file. If someone
else get's the capture file this might add more confusion than
clarification. I don't know if that's more of a theoretical than a
practical problem.
How to display a bandwidth graph, if you don't know the max bandwidth of
the current interface (we currently don't have a way to get the max
throughput of an interface as libpcap doesn't include this info) and we
certainly won't have it after Ethereal is closed.
BTW: There *is* already a one click capture button in the toolbar
called: "Start a new live capture" using the same settings than before
(the third button from the left in the toolbar).
Regards, ULFL