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: Tue, 28 May 2013 20:32:15 -0400
Anders Broman wrote:

Ed Beroset wrote:
My inclination would be for option 2 be the default, but with option
1 being available as a configuration checkbox.
Yes this sounds like the thing to do for me to, regarding address resolution there has been discussions of a rewrite using "normal" hash tables
And options not to dump NRB:s
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7380
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8349

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8462

So with this bug report I already knew about, that's three different ones with different aspects, ideas, problems and goals. As I understand it, there are potentially four different (potential) sources for name resolution. They are 1) a named hosts file (not necessarily the system hosts file) 2) whatever is behind OS gethostbyaddr() call 3) NRB in capture file and 4) manually entered names.

For name resolution, I'm thinking that it might be useful to allow the user to select both the order for resolution and whether each is used or not. Just to make it even more complex, it may be desirable for the user to dump some but not all of the names when a new capture file is loaded. For example, one might reasonably wish to dump the previous NRB names, but keep the manually entered ones.

There should probably also be some kind of options for saving as well. Specifically, it might be useful to allow the user to save a combined hosts file (which could include names resolved via any of the methods listed above) and/or save to an NRB or strip all of it out of the NRB.

Also, I think Evan Huus's comment about changing to use glib hash tables is a good one, and would propose to incorporate that as well.

Too complex? Did I miss anything? I think it's better to decide the behavior first and then code it, so thanks very much for your comments.

Ed