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.
> At packet decoding, the XX:XX:XX:XX:XX:XX is replaced by
> <logical_name> if found in the system wide or per-user ethers
> files else by <vendor_string>_XX:XX:XX if the manufacturer is
> known. If the -n option is set no resolving is performed.
> When an option window will be available, the switch between
> these tree representations can be easily controlled (if the
> routines are well written ;-)
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. 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.
--gilbert
--
Gilbert Ramirez Voice: +1 210 358 4032
Technical Services Fax: +1 210 358 1122
University Health System San Antonio, Texas, USA
