ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] manual address resolution is broken

From: Ed Beroset <beroset@xxxxxxxxxxxxxx>
Date: Mon, 27 May 2013 10:50:47 -0400
Ed Beroset wrote:
Today I was analyzing some capture files and wanted to use manual
name resolution to make things a little to interpret, but I found out
that manual name resolution no longer works.  The bug has already
been reported
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8462 and a patch
submitted, but I'm not sure that patch is the right way to resolve
things since it basically undoes (incompletely) a deliberate change
that was done some months ago:
http://anonsvn.wireshark.org/viewvc?view=revision&revision=45511

In my particular case, I have multiple capture files of traffic
between the same two points and so it would actually be convenient in
my case for the manual address resolution to persist between capture
files.  On this particular machine, I have root privileges, and so
could edit the hosts file, but we can't count on that for most
people.

Before I change the code, I think it would be useful to agree on
desired behavior first.  At the moment, it's clearly broken because
right after a manual name is entered, it's erased again by the call
to host_name_lookup_cleanup() in epan/packet.c before the resolution
is invoked again.  Here are three possible options:

1. have manually entered host names persist for the duration that
Wireshark is running 2. have them persist only until another capture
is begun or capture file entered 3. have a name resolution table
that's stored as a persistent setting per configuration profile

Variations might include: for option 2 dialog that asks, if there is
a non-empty list, whether to keep or dump the names; or for option 1,
have a manual means to dump all manually entered host names.

My inclination would be for option 2 be the default, but with option
1 being available as a configuration checkbox.  What say you all?

Since I hadn't received any comments on this, I'm just going to code it the way I suggested and submit the patch.

Ed