ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: [Ethereal-dev] Issues in network name resolution

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Francisco Alcoba (ML/EEM)" <francisco.alcoba@xxxxxxxxxxxx>
Date: Tue, 31 Aug 2004 16:39:59 +0200
Hi,

I have found a number of issues with the network name resolution on Windows. They are different but somehow relate to each other:

1) When using asynchronous DNS -which is fantastic- we lose the "hosts" file translations. My usual work with ethereal is in labs with my only NIC attached to a mirroring port, so DNS is out ouf the question, but "hosts" is very useful. So I have borrowed some code from prefs.c and written a patch for reading the file -which I have been able to test only in Windows 2000-. This includes read_hosts_file, host_name_lookup_init and MAXIPV4ADDLEN

2) The functions use inet_aton, so I've found what I think is a bug with it: there are currently two versions of that function in Windows with ADNS: the one in epan\inet_aton.c and the one in ADNS. Moreover, the ADNS one -that is apparently the one that gets used -seems broken, it always returns TRUE. I think this is because it checks the return of gethostbyaddr against INADDR_ANY, while the return value for failed requests is INADDR_NONE; I've told this to the ADNS people but, just as a workaround, and since I don't know how to force the linker to use the one in epan, I have included a local definition

3) As a result of this, the inet_aton in get_host_ipaddr returns FALSE when checking something that is not an IPv4 address. And then the function falls back to "hp = gethostbyname(host);". So you'll get the problem with Windows trying to resolve the name via NetBios and timing out -or any machine not having complete DNS resolution; I don't think ADNS would do here-. Since get_host_ipaddr gets called in real time when you are writing display filters, that means that for a filter like "ip.addr eq 111.111.111.111" you'll have timeout in 1, 11, 111, 111., 111.1 etc. This is hard to accept, but I'm not sure of which is the second best. As a sort of workaround I have included a search in host_table for the string. I know this is not a good idea, host_table is not optimized for searching host names, and moreover this will work only for names that have already been included there -like the ones in the hosts file, in my case-, but I don't know how to improve it without having the tim!
 eout problem. I have tested it in a Pentium 4 at 1.8 Ghz with 2000 entries with similar names in hosts, and it works fine, but I understand this is not by any means the slowest of machines.

I've attached the addr_resolv.c that includes all of this and a comparison -by an editor, I'm still trying to come to terms with diff- against the one in today's tarball. I do think that the patch for point 1 could be helpful, but I think points 2 and 3 will require some decisions by the developers.

 <<addr_resolv.c>>  <<addr_resolv.diff>> 

Best regards,

  Francisco

Attachment: addr_resolv.c
Description: Binary data

Attachment: addr_resolv.diff
Description: Binary data