Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 52115: /trunk/epan/ /trunk/epan/: ad
From: Anders Broman <[email protected]>
Date: Thu, 26 Feb 2015 09:57:09 +0000
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Gerald Combs
Sent: den 26 februari 2015 01:12
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 52115: /trunk/epan/ /trunk/epan/: addr_resolv.c

On 2/25/15 2:59 PM, Jeff Morriss wrote:
> On 09/17/13 00:55, [email protected] wrote:
>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=5211
>> 5
>>
>> User: etxrab
>> Date: 2013/09/16 09:55 PM
>>
>> Log:
>>   Don't call gethostbyaddr() we have already read the local hosts 
>> file, settle for that.
>>
>> Directory: /trunk/epan/
>>    Changes    Path             Action
>>    +0 -30     addr_resolv.c    Modified
> 
> Hmmm, this change means that on systems without C-ARES or GNU ADNS, 
> external name resolution does not work at all (even for stuff that's 
> in /etc/hosts).
> 
> Any objection to reverting this?
> 
> Or if we really want to kill off gethostbyaddr() we should disable 
> "Use external name resolver" when we don't have an asynchronous name 
> resolver (to make it obvious to the user s/he has a system where we 
> don't want to do name resolutions).
>
>No objection here, although reverting should include switching to getaddrinfo. I haven't looked at it that closely but we might be to add dns.c and make asynchronous resolution always-on:
>
>http://25thandclement.com/~william/projects/dns.c.html

No objection here either - at the time - as far as I remember - I thought it was a duplication of something done earlier... Reading the hosts file twice(on windows?)?

Regards
Anders
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe