Ethereal-dev: RE: [Ethereal-dev] Problem with get_host_ipaddr in addr_resolv.c for win32
Guy Harris Wrote
> But "gethostbyname()" timeouts should occur for NetBIOS name
> resolutions
> only if either
>
> 1) you're using WINS and your WINS server is down
>
> or
>
> 2) you're not using WINS.
>
> The main NetBIOS problems are with "gethostbyaddr()", as there's no
> NetBIOS Name Server query that supplies an address and asks
> for the name
It seems that it is not exactly like that. According to the explanation in
http://www.winnetmag.com/Windows/Article/ArticleID/113/113.html
only positive WINS responses stop the process. If it gets a negative one -which it will probably do if you try to resolve 400.1.1.1 - then the PC broadcasts three times, with 0.7 seconds delay for the resolution. That makes about 2 seconds; if you are writing "ip.addr eq 400.1.1.1", ethereal will try to resolv 400., then 400.1, then 400.1. ... and stop 2 seconds per attempt. If you try to filter "ip.addr eq snoopy" and snoopy is a real host name, you still have to wait for the timeout for s, sn, sno...
One possible workaround migth be to only try resolution after a name separator is written (space, parentheses, etc); the negative consequence would be that "ip.addr eq snoopy" would be rejected, while "ip.addr eq snoopy " would be accepted, and this seems very anti-intuitive.
One point to consider is that name resolution is really not working at all now for Windows in filters. This is because inet_aton always answers true, even for names, but then the check in addr_resolv rejects the address if it is not in an xxx.xxx.xxx.xxx format. So right now "ip.addr eq snoopy" is rejected. Maybe people using windows are simply not using host names in ethereal because name resolution was not practical before adns came to resque.
So, if I modify configure.in so that it looks for the broken version of inet_aton and replaces it with ethereal's, the net result would be worse than the present situation.
