Ethereal-dev: Re: [Ethereal-dev] Problem with get_host_ipaddr in addr_resolv.c for win32
Francisco Alcoba (TS/EEM) wrote:
When configuring a display filter in win32, something like "ip.addr eq 400.1.1.1"
is accepted. This is because it uses get_host_ipaddr to check for the correctness
of the IP address; this, in turn, uses inet_aton -the inet_aton in adns- which is
broken, it always returns TRUE -this is, I think, because it checks the return value
of gethostbyaddr against INADDR_ANY, instead of INADDR_NONE; I have reported this
to the asdns people-.
However, if I use a correct version of inet_aton, it will return FALSE,
and then get_host_ipaddr will execute gethostbyname, which has timeout problems
in win32 because of NetBios resolution. Is there a way out of this problem -as,
for instance, not trying to resolv host names in display filters, would this be
acceptable?
Not trying to resolve host names in display filters would, obviously,
not be acceptable at all. People have better things to do with their
time than run nslookup, or whatever, to do the resolution of host names
manually.
To deal with the broken inet_aton(), we should perhaps always arrange to
use our own inet_aton() if ADNS is being used and it has a broken
inet_aton(). (We already have our own inet_aton(), which the configure
script uses on systems that lack inet_aton(); the configure script
should also check for a broken inet_aton(), just as it checks for a
broken inet_pton(). On Windows, with an MSVC++ build, we can presumably
just forcibly build with our own inet_aton() if we're building with ADNS
until an ADNS release without the bug is released, at which point we
should require that release.)
To deal with the "gethostbyname()" timeouts, perhaps we should use ADNS
to resolve names in "get_host_ipaddr()" if ADNS is configured and enabled.
