On Thu, May 20, 2004 at 05:57:13PM -0400, Brad Wilson wrote:
> One of the features that I like in another sniffer is the ability to edit
> addresses in the summary pane.
>
> Let's say I am looking in the summary pane at src ip of 10.0.0.1 and I
> knew that was my client. I could secondary click on the address and say
> edit address to reflect the name to be shown throughout the rest of the
> capture to be "client"
That'd really be editing the address <-> name mapping database, not
editing the cell in the summary pane - that functionality should be
general functionality, not something tied only to the summary pane,
although a context-menu item for adding a new item, corresponding to the
address under the mouse in the summary pane *or* the detail pane, to the
mapping database, or editing an existing item for that address
(depending on whether the address is present in the database or not),
should also be present.
I'd see
1) a new menu-bar item "Addresses", with "Edit", "Save", and
"Load" options (or perhaps with different names), where:
"Edit" pops up a dialog box with a list of addresses and
names, with options to add new entries, delete existing
entries, and modify existing entries;
"Save" lets you save the address list to a file - the
format I'd see for the file would be a text file with
each line containing an address type (e.g., "IP" or "ip"
or "IPv4" or "ipv4" for IPv4 addresses, "IPv6" or "ipv6"
for IPv6 addresses, etc. - that'd allow it to also
support IPX, Fibre Channel, MAC, etc. addresses);
"Load" would let you load one of those files;
and there might also be "Export" and "Import" to write out
and read in files in "/etc/hosts" format (which would only
handle IPv4 and IPv6 addresses), Microsoft Network Monitor
format (which appears to handle MAC, IP, and IPX addresses),
and perhaps other formats for other network analyzers;
2) context-menu items to quickly set up the "add" and "edit"
options for "Addresses->Edit", filling in the address.
Not all of those need to be implemented initially, but we should at
least make sure we leave room to implement them.
> These defined names could then be used in display filters.
That'd involve making the display filter code look up names in the
address <-> name mapping database before looking them up with
"gethostbyname()".
> Any chance this could be done?
Yes, it could - doing all of the above would take longer, obviously, but
we already have an API for adding new entries to the host-to-IP-address
mapping database ("add_host_name()"), which could at least handle IPv4
(we'd have to add IPv6 APIs, although at that point it might be useful
to generalize the "epan/resolv.c" code to handle multiple AT_ values
with APIs that take an AT_ value as an argument).