On Mon, Mar 06, 2000 at 02:09:29PM +0100, Juan Toledo wrote:
> I've been thinking more on what etherape really is, and definitely it
> shouldn't need
> to deal with packet capture. It should accecpt a stream of information
> from which
> it could select what defines a node, and what a link, and simply draw
> the diagram.
>
> We have agreed on ethereal being the one capturing and dissecting the
> traffic.
Well, dissecting, yes.
What really needs to happen is the creation of a packet capturing
daemon. We've talked about it on ethereal-dev for remote capturing
purposes. It would be a daemon that understoodd RMON I & II, and perhaps
our own special syntax for capture filters (based on Ethereal's display
filters).
But besides its utility for remote captures, it would also be ideal for
local captures. Why? We could make Ethereal runnable as a non-root user,
and have the capture daemon (wiretapd?) run as root. The daemon
would need to authenticate the user and send the captured data to the
client process in encrypted form.
Once we have a capture daemon, any process running as a user that
is allowed to capture packets (controllable by Unix group membership, or
via PAM for those platforms that use it). Ethereal, etherape, and many
other programs would then be clients to this new daemon, and would all
be runnable as non-root users.
> Now, I realize that this developments will not happen overnight, and
> I'm going to further develop etherape using pcap in the meantime.
>
> I'm thinking of a structure like this:
>
> guint8 *l2_addr; /* normally ethernet addresses */
> guint8 *l3_addr; /* normally ip addresses */
> guint8 *l4_addr; /* normally tcp or udp ports */
> ...
>
> And then any combination of this addresses would be the key
> to define a node.
Why a combination? If you're communicating with IP addresses that
are not on your local LAN segment, then the l2_addr will be
your local router, while the l3_addr will be the remote IP address.
--gilbert