reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] resip, ares, and IPv6

You might want to check with the c-ares team regarding IPv6 server support, and whether there are any special tricks to getting it to work. Please don't interpret this as me telling you to go away (on the contrary, I'd love for you to report back any findings) -- I just don't think we have the expertise to help you. 

/a

On 5/12/11 1:39 PM, David Stuart wrote:

Hi All,

Sadly even after moving everything to c-ares it seems that c-ares has a
similar (in fact identical) deficiency.

Basically I disable IPv4 and enable IPv6, and have a single statically
provisioned DNS server on IPv6. c-ares reports that there is 1 server,
but oddly enough it gives me the IPv4 server (though it is disabled),
and no mention of the IPv6 DNS server.

Looking at the code it's not clear to me where it's supposed to read the
configuration, since I don't see the same MS "IP Helper" approach taken
as resip-ares.

The loopback stuff I think can resolve well enough, by comparing to the
sentinel values which c-ares sets things to (but again, I don't see
where for IPv6 c-ares is setting up the ::1 value in this case).



On 11-05-12 12:16 PM, Scott Godin wrote:

That flag is used in AresDns.cxx - the piece of code in Dave's email
contains the "read" access to this variable.  The comments on the code
fragment Dave pasted in explains the use.  I added the flag to be able to
detect scenarios where the ares user may have provided 127.0.0.1 as the DNS
servers, instead of ares just using loopback because no DNS servers were
provided.

Scott


On Thu, May 12, 2011 at 11:32 AM, Adam Roach<adam@xxxxxxxxxxx>  wrote:


On 5/12/11 10:07 AM, David Stuart wrote:


There's some code there that goes like this (and I
hope this isn't one of our local patches, but if it is, oh well):


I think it is. I did a grep over the public resip tree, and find no
references to "default_localhost_server" outside of ares_init.c and
ares_private.h.


  And of course, c-ares has no concept of "default_localhost_server"

(whatever that is).


The really odd thing is that it appears to be a write-only variable. None
of the ares code ever attempts to read it. I've copied Scott Godin on this
message, since he's the one who added the variable to the ares code; perhaps
he can explain what's going on here. :)

In any case, the resip ares code basically has logic that says "if there
are no configured nameservers, then configure a single nameserver, and set
it to INADDR_LOOPBACK." If it does that, it also sets
default_localhost_server to 1.

I don't know what c-ares would do in this case. If it has the same kind of
behavior (no servers == use loopback), then your approach of checking for
127/8 (note: 127/8, not 127.0.0.1) or ::1 is probably correct. On the other
hand, if it doesn't have the "no servers == use loopback" logic, then you'd
want to check for "mChannel->nservers == 0" instead. You'll probably have to
read the c-ares code (or play around with it) to see which approach is
correct.

/a

  #ifdef WIN32

    // For windows OSs it is uncommon to run a local DNS server.
Therefore if there
    // are no defined DNS servers in windows networking and ARES just
returned the
    // loopback address (ie. default localhost server / named)
    // then put resip DNS resolution into hostfile lookup only mode
    if(mChannel->nservers == 1&&
       mChannel->servers[0].default_localhost_server)
    {
       // enable hostfile only lookup mode
       mHostFileLookupOnlyMode = true;
    }
    else
    {
       // disable hostfile only lookup mode
       mHostFileLookupOnlyMode = false;
    }
#endif


So, any advice as to how to clear this hurdle would be appreciated.
Should I look at the addr and try to compare it to 127.0.0.1 or ::1 ?

Is this even the right place to ask about c-ares?

David


On 11-05-11 12:08 PM, Adam Roach wrote:


On 5/11/11 10:39 AM, David Stuart wrote:


OK, sounds reasonable.

Does anyone recall why resip forked ares to begin with? What am I losing
by switching over to c-ares?


The big reason for the fork is that ares had gone dead, and the original
maintaners did not respond to emails. Resip had to "fork" the dead code
just to fix bugs and add features. It's the same reason c-ares ended up
forking ares, although they've clearly had different enhancements added
since the fork.

Here is Brad's list of features that resip-ares had but c-ares did not.
This refers to c-ares 1.5.3, and I know that Brad was working with the
c-ares team to get some features added, so this might not be completely
accurate any longer:

On 11/22/08, Brad Spencer wrote:


I have identified a set of "obvious" features that resiprocate depends
on simply by looking at the API differences between contrib/ares and
c-ares.  I have not searched for embedded behavioural changes that may
have been made to contrib/ares without API changes.  However,
especially if c-ares vs contrib/ares were to remain a choice at
configuration time, I think this is okay, at least as a starting point
because c-ares "works".

The attached patch will allow resiprocate to be configured against the
trunk version of c-ares (1.5.3 + patches).  Of course, it still allows
resiprocate to be configured to use contrib/ares as well.  With this
patch against resiprocate-1.4.1, the following features are missing
only when using c-ares:

   1. TryServersOfNextNetworkUponRcode3

     I've read the mailing list history on item 7, and I'm still
     digesting that.  It seems to be only supported on Windows in the
     current contrib/ares source, though.

   2. AfterSocketCreationFuncPtr

     I haven't been able to find much information about the purpose of
     the AfterSocketCreationFuncPtr feature, except I found some note
     about it being related to QoS.

     Is there a reason only UDP sockets from ares are identified via
     this function?  If I can supply the reasons this is important for
     QoS, and we can figure out what to do about TCP, there's probably a
     good argument to be made for adding an analogue of this to c-ares.

   3. DNS servers with IPv6 addresses themselves

     contrib/ares can have IPv4 and IPv6 addresses of DNS_servers_
     configured (via the additionalNameservers argument and via built-in
     config parsing), while c-ares can only contact IPv4 addressed DNS
     servers at the moment.  Note that this has nothing to do with AAAA
     record lookups, which work fine when using c-ares.

     This seems like a good candidate for a new c-ares feature, and I
     will ask about it on the c-ares list and report back.

  After some quick poking around, I think #2 has been added to c-ares (as

of 1.6) and integrated into resip's c-ares support; and I think #3 is
fixed in c-ares (as of 1.7.1) but is not yet integrated.

Derek MacDonald also pointed out that resip-ares had added some features
to multi-lan failover support when hosts have multiple configured
interfaces. I think that's what #1 in the list above means, but I can't
recall.

Byron Campbell noted, back in 2008, that c-ares is substantially faster
than the resip version (it can do about twice as many DNS transactions
per second).

/a