Gilbert Ramirez Jr. wrote:
>
> As Laurent Deniel said:
> >
> > At ethereal startup, the hash tables are filled with the content
> > of these files. Filling the manufacturer hash table with the whole
> > file at startup is not a problem (not so big). I think that for
> > the ethers files, it is not an issue but if I am wrong, I can
> > update the hash table only on demand (as TCP/UDP ports) (i.e.
> > a getethbyaddr that will parse the ethers files like
> > getservbyport when an address is not already in the hash table).
>
> It sounds reasonable to keep them as text files.
Does it mean that I should implement the second solution ?
>
> If I may make one suggestion. Yes, I like _either_ the name or the numeric
> representation in the information window. BUT, I like to have both in the
> protocol dissection tree.
I agree.
> That is, if '-n' is used, no name resolution is
> used at all. But if '-n' is not used, then in the protocol analysis, we'd
> have someething like:
>
> Source address: 129.111.5.41 (verdict.uthscsa.edu)
>
> or...
>
> Source address: verdict.uthscsa.edu (129.111.5.41)
>
> We'd just have to make sure that all the dissect_* routines are consistent
> as to what is in the parentheses.
>
Yes.
A code like this :
add_item_to_tree(ip_tree, offset + 12, 4, "Source address: %s (%s)",
ip_to_str((guint8 *)&iph.ip_src),
get_hostname(iph.ip_src));
will display :
129.111.5.41 (verdict.uthscsa.edu) -n non set
or 129.111.5.41 (129.111.5.41) -n set (or name not found)
If the second line is not appropriate, we have to test the g_resolving_actif
flag (directly or with a new macro or function call) in all the code ...
Laurent.
--
Laurent DENIEL | E-mail: deniel@xxxxxxxxxxx
Paris, FRANCE | deniel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
| WWW : http://www.worldnet.fr/~deniel
All above opinions are personal, unless stated otherwise.
