Hi Ulf,
On Mon, 2006-04-10 at 01:49 +0200, Ulf Lamping wrote:
> Don't wanted to discourage you in improving the current Ethereal state
> of ease of use. I've spend more than the last two years to have the
> basic GUI code behave better :-)
OK, thanks, I was beginning to suspect that I would not get any support
at all from this list.
> What I meant would be hard is to bring Ethereal into a shape so it would
> work well for monitoring purposes.
>
> Ethereal currently:
>
> - dissects incoming packets up to the last byte (if it knows the
> protocol well :-), while a monitoring / measurement tool will only
> dissect a packet up to the interesting point (performance)
> - keeps session related information so it will consume memory until it
> crashes (and this might happen soon on a very busy network)
>
> So it would be very hard to convert Ethereal into a 24/7 monitoring tool
> like MRTG.
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.
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.
> Improving the existing graph windows and their usage is a completely
> different thing. Improving them seems to be a very good idea to me :-)
OK, great.
> Improving the current functionality seems to be a good idea (much better
> than forking).
I was hoping that somebody would say that, as I didn't really fancy
maintaining my own fork and repeatedly merging patches, etc.
> But don't underestimate the time you'll need to do the GTK changes!
I wish I could use wxWidgets - I'm quite familiar with its framework. I
guess I will have to learn GTK before I can make useful changes to the
UI.
> Well, that's true. Some of them are open source, some are Linux only,
> some are ...
... some are outrageously expensive, some are plain ugly (like ntop),
some are evil, some are Turkish... :-)
> 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.
> 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?
> P.S: As Lego suggested, ntop provides the information about the
> *current* network load. It won't provide info about a capture file done
> by someone else earlier. So no real help here.
I'm not too worried about saved capture files. I think it's a very minor
use for novice system administrators compared to what's going on on
their network right now.
See also my reply to Lego about ntop: it's a real pig to use for this
purpose as well, probably worse than Ethereal, which can at least show
you the raw data if you don't understand the reports and summaries, or
they don't give you enough information.
Cheers, Chris.
--
___ __ _
/ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |
