c-ares development and related discussions ()

Daniel Stenberg | 12 May 2013 15:55

RELEASE: c-ares 1.10.0

Hi friends!

Almost eleven months since the previous release, I'm glad to announce a brand 
new c-ares tarball uploaded to the site: http://c-ares.haxx.se/

c-ares version 1.10.0

Changes:

  o Added ares_create_query(), to be used instead of ares_mkquery()
  o ares_inet_ntop() and ares_inet_pton() are now recognized c-ares functions

Bug fixes:

  o include the ares_parse_soa_reply.* files in the tarball
  o read_udp_packets: bail out loop on bad sockets
  o get_DNS_AdaptersAddresses: fix IPv6 parsing
  o adig: perror() doesn't work for socket errors on windows
  o ares_parse_aaaa_reply: fix memory leak
  o setup_once.h: HP-UX <sys/socket.h> issue workaround
  o configure: several fixes
  o config-dos.h: define strerror() to strerror_s_() for High-C
  o config-dos.h: define HAVE_CLOSE_S for MSDOS/Watt-32
  o ares_build.h.dist: enhance non-configure GCC ABI detection logic
  o ares.h: stricter CARES_EXTERN linkage decorations logic
  o ares_cancel(): cancel requests safely
  o protocol parsing: check input data stricter
  o library init: be recursive, reference count inits/cleanups
  o ares_parse_txt_reply: return a ares_txt_reply node for each sub-string
  o ares_set_servers_csv: fixed IPv6 address parsing

(Continue reading)

headers

Timothy J Fontaine | 9 May 2013 00:27

ares_set_servers_csv and compressed IPv6 string

When passing in a compressed IPv6 string like "2001:4860:4860::8888" to ares_set_servers_csv everything to the right of the first ":" in "::" is stripped and interpreted as part of the port for the entry.

Is the intended behavior to require an IPv6 address in uncompressed notation, or is this merely a bug?

On a tangent, is there any interest in actually supporting specifying the port to be used? Conceptually I like the idea, but in practice I can't imagine many people using it.

headers

Patrick Valsecchi | 2 May 2013 08:25

Fixing a few errors and warning detected by coverity

Hi,

A colleague ran Coverity (a static analysis tool) against c-ares and 
fixed a few reported errors and warnings.

Please have a look at the attached patch.

Thanks.

Attachment (caresCoverity.diff): text/x-diff, 40 KiB

headers

Alex Loukissas | 1 May 2013 19:44

Patch to build current head (3f0ec47) on msvc11

Hi folks,

I'm a newcomer in the c-ares project and wanted to build it on my msvc11 (Visual C++ 2012), but I was failing to do so using the instructions in https://github.com/bagder/c-ares/blob/master/Makefile.msvc

Since I figured out the issue, I thought I'd share the patch with you. Feel free to use it.

Thanks

Alex

--
Alex Loukissas
Member of Technical Staff - Maginatics, Inc.
www.maginatics.com

Attachment (c-ares_msvc11.patch): application/octet-stream, 926 bytes

headers

Patrick Valsecchi | 26 Apr 2013 09:47

Proposal for unittests

Hi,

In attachment, you'll find a small prototype of a unittest suite for 
c-ares. I didn't integrate it with the autotools stuff, since I don't 
know it (we use cmake). For the moment, it is only testing the 
ares_parse_txt_reply function.

I've used the simplest C testing framework I've found (CuTest) and I've 
fixed it a bit to remove a few memory leaks that were detected by valgrind.

What do you all think? Is the direction I'm taking OK with you?

Thanks and CU

Attachment (draftTests.tar.gz): application/gzip, 5674 bytes

headers

Jakub Hrozek | 23 Apr 2013 13:33

soname

Hi,

I was notified[1] by another developer that the SONAME of libcares is
always reported as 2.0.0 despite the latest versions having a larger API.

For example on my RHEL5 test box the c-ares version is quite old but
still the soname is reported as 2.0.0:
# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.8 (Tikanga)
# rpm -qf /usr/lib64/libcares.so
c-ares-devel-1.6.0-5.el5
# objdump -p /usr/lib64/libcares.so | grep SONAME
SONAME      libcares.so.2
# ls /usr/lib64/libcares.so*
/usr/lib64/libcares.so  /usr/lib64/libcares.so.2 /usr/lib64/libcares.so.2.0.0

On Fedora 18 we are using pretty much the latest c-ares, but the SONAME
is still the same:
# cat /etc/redhat-release 
Fedora release 18 (Spherical Cow)
# rpm -qf /usr/lib64/libcares.so
c-ares-devel-1.9.1-2.fc18.x86_64
# objdump -p /usr/lib64/libcares.so | grep SONAME
SONAME               libcares.so.2
# ls /usr/lib64/libcares.so*
/usr/lib64/libcares.so  /usr/lib64/libcares.so.2
/usr/lib64/libcares.so.2.0.0

Even the version in git in Makefile.am is 2.0.0

Are there any plans to bump the soname to reflect the API additions?

Thank you,
    Jakub

[1] https://bugzilla.redhat.com/show_bug.cgi?id=950045

headers

ayush jain | 22 Apr 2013 07:32

Parsing of 'Additional Records' in SRV response

Hi ,

I was just going through the c-ares API 'ares_parse_srv_reply' and was wondering why it doesn't parse the 'additional record' section present in the SRV response.

As in a multi-threaded architecture where you may want to minimize the overall number of DNS queries per second for better performance, usage of Additional Records can significantly reduce the need of 'A' queries or reading the entries from /etc/hosts depending on the /etc/nsswitch.conf file.

Any suggestions and/or comments are most welcome

Regards,

_Ayush

headers

Patrick Valsecchi | 19 Apr 2013 14:40

DNS servers on windows

Hi,

I have a lot of trouble using c-ares on one of my windows boxes.

The machine has two interfaces:
1) configured with a static IP address and it has DNS in automatic mode, but doesn't find any.
2) configured by DHCP and it receives a valid DNS interface

My problem is that windows (at least 7), in all it's glory, invents DNS addesses for my first interface with 3 addresses taken from an outdated draft RFC [1]. And for some reasons, it shows them multiple times when GetAdaptersAddresses is called.

So I end up with 13 DNS server addresses:

fec0:0:0:ffff::1
fec0:0:0:ffff::2
fec0:0:0:ffff::3
10.104.48.2 <- my actual server
fec0:0:0:ffff::1
fec0:0:0:ffff::2
fec0:0:0:ffff::3
10.104.48.2
fec0:0:0:ffff::1
fec0:0:0:ffff::2
fec0:0:0:ffff::3

c-ares doesn't behave very well with such setup. At each query, it will start over with the first server, wait for a timeout of 5 seconds and then try the second one, ... . So I have to wait 15s for each query to complete.

My first suggestion would be to apply this patch in order to remember the last good server and start from this one afterwards:
diff --git a/c-ares/ares_process.c b/c-ares/ares_process.c
--- a/c-ares/ares_process.c
+++ b/c-ares/ares_process.c
<at> <at> -622,6 +622,8 <at> <at>
         }
     }

+ if (channel->rotate != 1)
+      channel->last_server = whichserver;
   end_query(channel, query, ARES_SUCCESS, abuf, alen);
}

Then I'd suggest to sort the servers in the ares_channel and put the fec0:: ones at the end.

What do you think?

[1] http://tools.ietf.org/id/draft-ietf-ipngwg-dns-discovery-03.txt

headers

Patrick Valsecchi | 15 Apr 2013 10:29

ares_parse_txt_reply's output is not usable for DNS-SD

Hi,

I'm using c-ares for doing DNS-SD. For that, I need to interpret TXT records formatted as specified in the DNS-SD spec [1]. Unfortunately, the ares_parse_txt_reply function just concatenates the sub-strings of the TXT record I get into a single string, loosing the information of the various key/value pairs contained in the TXT record.

To fix that, I see two solutions:

1) provide a second function that parses the TXT records that doesn't parse the length+value sub-strings and lets the caller do this part of the parsing.

2) change ares_parse_txt_reply to return another ares_txt_reply node for each sub-string.

I'd be happy to provide a patch for either solution.

While I'm writing to this mailing list, I've seen some discussions in the archives about doing an implementation for mDNS. What is the status on that?

Thanks for this nice library and have a nice day.

[1] http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd-11#section-6.1

headers

Daniel Stenberg | 10 Apr 2013 08:59

Really fix memory leak when parsing AAAA replies. (#10) (fwd)

FYI

-- 

  / daniel.haxx.se

---------- Forwarded message ----------
Date: Wed, 10 Apr 2013 05:43:07
From: psaab <notifications@...>
To: bagder/c-ares <c-ares@...>
Subject: [c-ares] Really fix memory leak when parsing AAAA replies. (#10)

bffd67f16a8f42fe6dbf79ab2e39d92eea05c8a6
You can merge this Pull Request by running:

   git pull https://github.com/psaab/c-ares master

Or you can view, comment on it, or merge it online at:

   https://github.com/bagder/c-ares/pull/10

-- Commit Summary --

   * Plug memory leak similar to ares_parse_a_reply.c in commit

-- File Changes --

     M ares_parse_aaaa_reply.c (2)

-- Patch Links --

https://github.com/bagder/c-ares/pull/10.patch
https://github.com/bagder/c-ares/pull/10.diff

headers

Gisle Vanem | 3 Apr 2013 10:56

[Patch] ares_strcasecmp.h

I think it would be best to decorate the following functions properly
in case they are to be exported from cares.dll:

--- Git-latest\ares_strcasecmp.h   Wed Jan 09 13:58:03 2013
+++ ares_strcasecmp.h        Thu Mar 10 22:31:33 2013
 <at>  <at>  -17,14 +17,15  <at>  <at> 
  * without express or implied warranty.
  */

+#include "ares.h"
 #include "ares_setup.h"

 #ifndef HAVE_STRCASECMP
-extern int ares_strcasecmp(const char *a, const char *b);
+CARES_EXTERN int ares_strcasecmp(const char *a, const char *b);
 #endif

 #ifndef HAVE_STRNCASECMP
-extern int ares_strncasecmp(const char *a, const char *b, size_t n);
+CARES_EXTERN int ares_strncasecmp(const char *a, const char *b, size_t n);
 #endif

 #endif /* HEADER_CARES_STRCASECMP_H */

---------

All the a*.c samples could be using these functions.

--gv

19	May 2013
61	April 2013
22	March 2013
14	February 2013
3	January 2013
3	December 2012
2	November 2012
6	October 2012
7	September 2012
29	August 2012
11	July 2012
36	June 2012
11	May 2012
37	April 2012
2	March 2012
8	February 2012
15	January 2012
6	November 2011
6	October 2011
8	September 2011
23	August 2011
8	July 2011
23	June 2011
28	May 2011
2	April 2011
42	March 2011
38	February 2011
1	January 2011
24	December 2010
10	November 2010
1	October 2010
6	September 2010
12	August 2010
35	July 2010
18	June 2010
19	May 2010
26	April 2010
30	March 2010
12	February 2010
10	January 2010
12	December 2009
46	November 2009
45	October 2009
13	September 2009
19	August 2009
12	July 2009
11	June 2009
47	May 2009
2	April 2009
17	March 2009
6	February 2009
17	January 2009
30	December 2008
56	November 2008
13	October 2008
12	September 2008
36	August 2008
21	July 2008
22	June 2008
20	May 2008

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31