dnsmasq 2.75: next patch... (No.50)

  Again one latecoming patch (DNSSEC).

Download:
http://people.ipfire.org/~mfischer/dnsmasq_275_2016_01_16
MD5: a266e4673ed7d218b0477c6b02e3ef4d

This is the compiled binary, nothing more is needed.

Copy to '/usr/sbin'
Stop 'dnsmasq' (/etc/init.d/dnsmasq stop)
Rename (don't forget backing up the *old* version!)
Start 'dnsmasq' (/etc/init.d/dnsmasq start).

Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
---
 lfs/dnsmasq                                        |   3 +-
 ...NSSEC_validation_with_private_DNS_servers.patch | 139 +++++++++++++++++++++
 2 files changed, 141 insertions(+), 1 deletion(-)
 create mode 100644 src/patches/dnsmasq/050-Complete_work_to_allow_DNSSEC_validation_with_private_DNS_servers.patch
  

I installed this package yesterday and dnsmasq broke a few minutes ago.
About 24 hours.

Strange thing: when I was using the servers you recommended
84.200.69.80, 84.200.70.40
I did not have any problems even though you have been updating very
frequently. However, I reverted to the old DNS servers
209.244.0.3 8.8.4.4
and in less than a few days (I think I did it with the 15th or 14th
update), it broke again. Those servers are, respectively,
resolver1.level3.net and one of the google ones.

Let me know if you want me to use the 84 DNS servers. Hell, I may just
decide to build my own caching DNS servers!!!

Rod

On 01/17/2016 08:30 AM, Matthias Fischer wrote:
> Again one latecoming patch (DNSSEC).
> 
> Download:
> http://people.ipfire.org/~mfischer/dnsmasq_275_2016_01_16
> MD5: a266e4673ed7d218b0477c6b02e3ef4d
> 
> This is the compiled binary, nothing more is needed.
> 
> Copy to '/usr/sbin'
> Stop 'dnsmasq' (/etc/init.d/dnsmasq stop)
> Rename (don't forget backing up the *old* version!)
> Start 'dnsmasq' (/etc/init.d/dnsmasq start).
> 
> Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
> ---
>  lfs/dnsmasq                                        |   3 +-
>  ...NSSEC_validation_with_private_DNS_servers.patch | 139 +++++++++++++++++++++
>  2 files changed, 141 insertions(+), 1 deletion(-)
>  create mode 100644 src/patches/dnsmasq/050-Complete_work_to_allow_DNSSEC_validation_with_private_DNS_servers.patch
> 
> diff --git a/lfs/dnsmasq b/lfs/dnsmasq
> index bdfb1f8..4e5951f 100644
> --- a/lfs/dnsmasq
> +++ b/lfs/dnsmasq
> @@ -1,7 +1,7 @@
>  ###############################################################################
>  #                                                                             #
>  # IPFire.org - A linux based firewall                                         #
> -# Copyright (C) 2015  Michael Tremer & Christian Schmidt                      #
> +# Copyright (C) 2016  Michael Tremer & Christian Schmidt                      #
>  #                                                                             #
>  # This program is free software: you can redistribute it and/or modify        #
>  # it under the terms of the GNU General Public License as published by        #
> @@ -122,6 +122,7 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
>  	cd $(DIR_APP) && patch -Np1 -i $(DIR_SRC)/src/patches/dnsmasq/047-Fix_bad_cache-size_calculation_when_hosts-file_read_fails.patch
>  	cd $(DIR_APP) && patch -Np1 -i $(DIR_SRC)/src/patches/dnsmasq/048-Disable_DNSSEC_for_server_domain_servers_unless_trust-anchor_provided.patch
>  	cd $(DIR_APP) && patch -Np1 -i $(DIR_SRC)/src/patches/dnsmasq/049-arp_c_tidy_up.patch
> +	cd $(DIR_APP) && patch -Np1 -i $(DIR_SRC)/src/patches/dnsmasq/050-Complete_work_to_allow_DNSSEC_validation_with_private_DNS_servers.patch
>  	cd $(DIR_APP) && patch -Np1 -i $(DIR_SRC)/src/patches/dnsmasq-Add-support-to-read-ISC-DHCP-lease-file.patch
>  
>  	cd $(DIR_APP) && sed -i src/config.h \
> diff --git a/src/patches/dnsmasq/050-Complete_work_to_allow_DNSSEC_validation_with_private_DNS_servers.patch b/src/patches/dnsmasq/050-Complete_work_to_allow_DNSSEC_validation_with_private_DNS_servers.patch
> new file mode 100644
> index 0000000..b969eee
> --- /dev/null
> +++ b/src/patches/dnsmasq/050-Complete_work_to_allow_DNSSEC_validation_with_private_DNS_servers.patch
> @@ -0,0 +1,139 @@
> +From 92be34a4077672f592d47e2991b3530305517a28 Mon Sep 17 00:00:00 2001
> +From: Simon Kelley <simon@thekelleys.org.uk>
> +Date: Sat, 16 Jan 2016 18:39:54 +0000
> +Subject: [PATCH] Complete work to allow DNSSEC validation with private DNS
> + servers.
> +
> +---
> + man/dnsmasq.8 |    5 ++++-
> + src/forward.c |   34 +++++++++++++++++++++++++++++++---
> + src/network.c |   33 +++++++++++++++++++--------------
> + 3 files changed, 54 insertions(+), 18 deletions(-)
> +
> +diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
> +index d51b10f..69acdae 100644
> +--- a/man/dnsmasq.8
> ++++ b/man/dnsmasq.8
> +@@ -405,7 +405,10 @@ xxx.internal.thekelleys.org.uk at 192.168.1.1 then giving  the flag
> + .B -S /internal.thekelleys.org.uk/192.168.1.1 
> + will send all queries for
> + internal machines to that nameserver, everything else will go to the
> +-servers in /etc/resolv.conf. An empty domain specification,
> ++servers in /etc/resolv.conf. DNSSEC validation is turned off for such
> ++private nameservers, UNLESS a
> ++.B --trust-anchor
> ++is specified for the domain in question. An empty domain specification,
> + .B // 
> + has the special meaning of "unqualified names only" ie names without any
> + dots in them. A non-standard port may be specified as 
> +diff --git a/src/forward.c b/src/forward.c
> +index 11c0d45..c48fd75 100644
> +--- a/src/forward.c
> ++++ b/src/forward.c
> +@@ -151,7 +151,7 @@ static unsigned int search_servers(time_t now, struct all_addr **addrpp, unsigne
> + 	    hostname_isequal(matchstart, serv->domain) &&
> + 	    (domainlen == 0 || namelen == domainlen || *(matchstart-1) == '.' ))
> + 	  {
> +-	    if (serv->flags & SERV_NO_REBIND)	
> ++	    if ((serv->flags & SERV_NO_REBIND) && norebind)	
> + 	      *norebind = 1;
> + 	    else
> + 	      {
> +@@ -644,7 +644,7 @@ static size_t process_reply(struct dns_header *header, time_t now, struct server
> +     return resize_packet(header, n, pheader, plen);
> +   
> +   /* Complain loudly if the upstream server is non-recursive. */
> +-  if (!(header->hb4 & HB4_RA) && RCODE(header) == NOERROR && ntohs(header->ancount) == 0 &&
> ++  if (!(header->hb4 & HB4_RA) && RCODE(header) == NOERROR &&
> +       server && !(server->flags & SERV_WARNED_RECURSIVE))
> +     {
> +       prettyprint_addr(&server->addr, daemon->namebuff);
> +@@ -923,12 +923,40 @@ void reply_query(int fd, int family, time_t now)
> + 		    status = STAT_ABANDONED;
> + 		  else
> + 		    {
> +-		      int fd;
> ++		      int fd, type;
> + 		      struct frec *next = new->next;
> ++		      char *domain;
> ++		      
> + 		      *new = *forward; /* copy everything, then overwrite */
> + 		      new->next = next;
> + 		      new->blocking_query = NULL;
> ++
> ++		      /* Find server to forward to. This will normally be the 
> ++			 same as for the original query, but may be another if
> ++			 servers for domains are involved. */		      
> ++		      if (search_servers(now, NULL, F_QUERY, daemon->keyname, &type, &domain, NULL) == 0)
> ++			{
> ++			   struct server *start = server;
> ++			   type &= ~SERV_DO_DNSSEC;
> ++			   
> ++			   while (1)
> ++			     {
> ++			       if (type == (start->flags & SERV_TYPE) &&
> ++				   (type != SERV_HAS_DOMAIN || hostname_isequal(domain, start->domain)) &&
> ++				   !(start->flags & (SERV_LITERAL_ADDRESS | SERV_LOOP)))
> ++				 {
> ++				   server = start;
> ++				   break;
> ++				 }
> ++			       
> ++			       if (!(start = start->next))
> ++				 start = daemon->servers;
> ++			       if (start == server)
> ++				 break;
> ++			     }
> ++			}
> + 		      new->sentto = server;
> ++
> + 		      new->rfd4 = NULL;
> + #ifdef HAVE_IPV6
> + 		      new->rfd6 = NULL;
> +diff --git a/src/network.c b/src/network.c
> +index 303ae50..5451c6c 100644
> +--- a/src/network.c
> ++++ b/src/network.c
> +@@ -1442,20 +1442,25 @@ void check_servers(void)
> +       if (!(serv->flags & (SERV_LITERAL_ADDRESS | SERV_NO_ADDR | SERV_USE_RESOLV | SERV_NO_REBIND)))
> + 	{
> + #ifdef HAVE_DNSSEC
> +-	  if (option_bool(OPT_DNSSEC_VALID) && (serv->flags & SERV_HAS_DOMAIN))
> +-	    {
> +-	      struct ds_config *ds;
> +-	      char *domain = serv->domain;
> +-
> +-	      /* .example.com is valid */
> +-	      while (*domain == '.')
> +-		domain++;
> +-	      
> +-	      for (ds = daemon->ds; ds; ds = ds->next)
> +-		if (ds->name[0] != 0 && hostname_isequal(domain, ds->name))
> +-		  break;
> +-
> +-	      if (!ds)
> ++	  if (option_bool(OPT_DNSSEC_VALID))
> ++	    { 
> ++	      if (serv->flags & SERV_HAS_DOMAIN)
> ++		{
> ++		  struct ds_config *ds;
> ++		  char *domain = serv->domain;
> ++		  
> ++		  /* .example.com is valid */
> ++		  while (*domain == '.')
> ++		    domain++;
> ++		  
> ++		  for (ds = daemon->ds; ds; ds = ds->next)
> ++		    if (ds->name[0] != 0 && hostname_isequal(domain, ds->name))
> ++		      break;
> ++		  
> ++		  if (!ds)
> ++		    serv->flags &= ~SERV_DO_DNSSEC;
> ++		}
> ++	      else if (serv->flags & SERV_FOR_NODOTS) 
> + 		serv->flags &= ~SERV_DO_DNSSEC;
> + 	    }
> + #endif
> +-- 
> +1.7.10.4
> +
>
  

Hi,

On 19.01.2016 08:39, R. W. Rodolico wrote:
> I installed this package yesterday and dnsmasq broke a few minutes ago.
> About 24 hours.

Worked for 24 hours and then crashed? Weird. But thinking of it, this
could be one of the reasons why its not crashing *here*. Every 24 hours
my ISP cuts the connection, and our router gets a new IP and 'dnsmasq'
restarts!

> Strange thing: when I was using the servers you recommended
> 84.200.69.80, 84.200.70.40
> I did not have any problems even though you have been updating very
> frequently. However, I reverted to the old DNS servers
> 209.244.0.3 8.8.4.4
> and in less than a few days (I think I did it with the 15th or 14th
> update), it broke again. Those servers are, respectively,
> resolver1.level3.net and one of the google ones.

So as I understand you, its related with the DNS servers you use!? With
your ISP servers, it crashes and with the german servers, it doesn't?

> Let me know if you want me to use the 84 DNS servers. Hell, I may just
> decide to build my own caching DNS servers!!!

Ok, solution found - that was easy... ;-))

But as long as I'm working on this, I'm more and more sure that these
intermediate crashes are really a combination between the DNS servers
and 'dnsmasq' itself. Sad to say, I haven't got the (C-)skills to debug
this.

Right now, I'm trying to compile 'dnsmasq' with patches 051-053: it now
crashes in 'forward.c' during compilation if I activate the
DNSSEC-option (-e 's|/\* #define HAVE_DNSSEC \*/|#define HAVE_DNSSEC|g'
\). Reason: patch No.053, I think.

In contrast, the '2.76test6'-version compiles without *any* error, if I
delete and disable *all* of our adjustments.

As Simon wrote: "Conditional combination has a nasty combinatorial
explosion. I should hack up a regression test to build all possible
variants."

But obviously this wasn't done yet. If I leave everything as it is, its
building...

Perhaps I'll try another request on the dnsmasq-list during the next
days. The last one had no effect, no answers, nothing.

Best,
Matthias
  

Matthias,

I'm willing to do whatever you want with this to try and track the
problem down. I can leave it at the current NS servers, or change them
over. I'd recommend testing by leaving it pointing to the current NS
servers for a while and see if it breaks again. Then, if it does, I'll
move to the German servers and/or build my own.

I also think there have been so many updates to this that it makes it
hard to say exactly what the problem is. I'd like to stay on one
instance of dnsmasq for the testing period so we don't introduce any
additional variables. That can be the new one you want to look at, or
the one you uploaded (dnsmasq_275_2016_01_16) on the 16th. I have all
the ones all the way back to 2015-12-18 still on my the router, so I can
switch to any of them you want, but in order to say "it is a remote name
server issue" it might be best to choose one and stick with it for a while.

As it stands now, on the 16th, I installed dnsmasq_275_2016_01_16 AND
changed the name servers all at the same time (or maybe changed the name
servers on the previous version, don't remember).

OF COURSE, a solution might be to build a cron job that restarts dnsmasq
every 12 hours or so :(

Rod

On 01/19/2016 01:59 PM, Matthias Fischer wrote:
> Hi,
> 
> On 19.01.2016 08:39, R. W. Rodolico wrote:
>> I installed this package yesterday and dnsmasq broke a few minutes ago.
>> About 24 hours.
> 
> Worked for 24 hours and then crashed? Weird. But thinking of it, this
> could be one of the reasons why its not crashing *here*. Every 24 hours
> my ISP cuts the connection, and our router gets a new IP and 'dnsmasq'
> restarts!
> 
>> Strange thing: when I was using the servers you recommended
>> 84.200.69.80, 84.200.70.40
>> I did not have any problems even though you have been updating very
>> frequently. However, I reverted to the old DNS servers
>> 209.244.0.3 8.8.4.4
>> and in less than a few days (I think I did it with the 15th or 14th
>> update), it broke again. Those servers are, respectively,
>> resolver1.level3.net and one of the google ones.
> 
> So as I understand you, its related with the DNS servers you use!? With
> your ISP servers, it crashes and with the german servers, it doesn't?
> 
>> Let me know if you want me to use the 84 DNS servers. Hell, I may just
>> decide to build my own caching DNS servers!!!
> 
> Ok, solution found - that was easy... ;-))
> 
> But as long as I'm working on this, I'm more and more sure that these
> intermediate crashes are really a combination between the DNS servers
> and 'dnsmasq' itself. Sad to say, I haven't got the (C-)skills to debug
> this.
> 
> Right now, I'm trying to compile 'dnsmasq' with patches 051-053: it now
> crashes in 'forward.c' during compilation if I activate the
> DNSSEC-option (-e 's|/\* #define HAVE_DNSSEC \*/|#define HAVE_DNSSEC|g'
> \). Reason: patch No.053, I think.
> 
> In contrast, the '2.76test6'-version compiles without *any* error, if I
> delete and disable *all* of our adjustments.
> 
> As Simon wrote: "Conditional combination has a nasty combinatorial
> explosion. I should hack up a regression test to build all possible
> variants."
> 
> But obviously this wasn't done yet. If I leave everything as it is, its
> building...
> 
> Perhaps I'll try another request on the dnsmasq-list during the next
> days. The last one had no effect, no answers, nothing.
> 
> Best,
> Matthias
>
  

The last update to dnsmasq has run fine on all of our IPFire systems 
with the Google and Level 3 DNS servers for an extended period of time. 
Could all of the issues be a conflict with the dnsmasq code and 
*certain* DNS providers? If so this seems like a much harder problem to 
fix.

Fred

-----Original Message-----
From: Matthias Fischer [mailto:matthias.fischer@ipfire.org] 
Sent: Tuesday, January 19, 2016 2:59 PM
To: development@lists.ipfire.org
Subject: Re: [PATCH] dnsmasq 2.75: next patch... (No.50)

Hi,

On 19.01.2016 08:39, R. W. Rodolico wrote:
> I installed this package yesterday and dnsmasq broke a few minutes 
ago.
> About 24 hours.

Worked for 24 hours and then crashed? Weird. But thinking of it, this 
could be one of the reasons why its not crashing *here*. Every 24 hours 
my ISP cuts the connection, and our router gets a new IP and 'dnsmasq'
restarts!

> Strange thing: when I was using the servers you recommended 
> 84.200.69.80, 84.200.70.40 I did not have any problems even though you 

> have been updating very frequently. However, I reverted to the old DNS 

> servers
> 209.244.0.3 8.8.4.4
> and in less than a few days (I think I did it with the 15th or 14th 
> update), it broke again. Those servers are, respectively, 
> resolver1.level3.net and one of the google ones.

So as I understand you, its related with the DNS servers you use!? With 
your ISP servers, it crashes and with the german servers, it doesn't?

> Let me know if you want me to use the 84 DNS servers. Hell, I may just 

> decide to build my own caching DNS servers!!!

Ok, solution found - that was easy... ;-))

But as long as I'm working on this, I'm more and more sure that these 
intermediate crashes are really a combination between the DNS servers 
and 'dnsmasq' itself. Sad to say, I haven't got the (C-)skills to debug 
this.

Right now, I'm trying to compile 'dnsmasq' with patches 051-053: it now 
crashes in 'forward.c' during compilation if I activate the 
DNSSEC-option (-e 's|/\* #define HAVE_DNSSEC \*/|#define HAVE_DNSSEC|g'
\). Reason: patch No.053, I think.

In contrast, the '2.76test6'-version compiles without *any* error, if I 
delete and disable *all* of our adjustments.

As Simon wrote: "Conditional combination has a nasty combinatorial 
explosion. I should hack up a regression test to build all possible 
variants."

But obviously this wasn't done yet. If I leave everything as it is, its 
building...

Perhaps I'll try another request on the dnsmasq-list during the next 
days. The last one had no effect, no answers, nothing.

Best,
Matthias
  

Ok. I just want to make sure this is not a local problem.

Am I the only one who is having issues? If so, then all this work has
been for nothing. I was under the impression that there were several
reports of this issue, but if I'm the only one having the problem, then
I'll rebuild the test router (my home office router) and we'll put
effort into something else.

Again, if several people are reporting it, it is something that needs to
be fixed. But if I'm the only one with the issue, then it is probably
*MY* problem, not a problem with something else.

Fred, I agree, it looks like it is a problem with dnsmaq and certain DNS
providers, but I'm using Google and Level 3 for my tests and it fails
every couple of weeks. I'm suspicious of the DNS servers which make
money off their services by putting ads up (which it appears Level 3
does. If you put an invalid domain name up, it comes up with an ad to
purchase it. I have not looked at their traffic patterns to see what it
is, but I had absolute no issues when I was using the German servers.

So, if you think this is a one off, let's get off the issue and I'll
work on *MY* problem.

Let me know.

Rod

On 01/20/2016 12:23 PM, Kienker, Fred wrote:
> The last update to dnsmasq has run fine on all of our IPFire systems 
> with the Google and Level 3 DNS servers for an extended period of time. 
> Could all of the issues be a conflict with the dnsmasq code and 
> *certain* DNS providers? If so this seems like a much harder problem to 
> fix.
> 
> Fred
> 
> -----Original Message-----
> From: Matthias Fischer [mailto:matthias.fischer@ipfire.org] 
> Sent: Tuesday, January 19, 2016 2:59 PM
> To: development@lists.ipfire.org
> Subject: Re: [PATCH] dnsmasq 2.75: next patch... (No.50)
> 
> Hi,
> 
> On 19.01.2016 08:39, R. W. Rodolico wrote:
>> I installed this package yesterday and dnsmasq broke a few minutes 
> ago.
>> About 24 hours.
> 
> Worked for 24 hours and then crashed? Weird. But thinking of it, this 
> could be one of the reasons why its not crashing *here*. Every 24 hours 
> my ISP cuts the connection, and our router gets a new IP and 'dnsmasq'
> restarts!
> 
>> Strange thing: when I was using the servers you recommended 
>> 84.200.69.80, 84.200.70.40 I did not have any problems even though you 
> 
>> have been updating very frequently. However, I reverted to the old DNS 
> 
>> servers
>> 209.244.0.3 8.8.4.4
>> and in less than a few days (I think I did it with the 15th or 14th 
>> update), it broke again. Those servers are, respectively, 
>> resolver1.level3.net and one of the google ones.
> 
> So as I understand you, its related with the DNS servers you use!? With 
> your ISP servers, it crashes and with the german servers, it doesn't?
> 
>> Let me know if you want me to use the 84 DNS servers. Hell, I may just 
> 
>> decide to build my own caching DNS servers!!!
> 
> Ok, solution found - that was easy... ;-))
> 
> But as long as I'm working on this, I'm more and more sure that these 
> intermediate crashes are really a combination between the DNS servers 
> and 'dnsmasq' itself. Sad to say, I haven't got the (C-)skills to debug 
> this.
> 
> Right now, I'm trying to compile 'dnsmasq' with patches 051-053: it now 
> crashes in 'forward.c' during compilation if I activate the 
> DNSSEC-option (-e 's|/\* #define HAVE_DNSSEC \*/|#define HAVE_DNSSEC|g'
> \). Reason: patch No.053, I think.
> 
> In contrast, the '2.76test6'-version compiles without *any* error, if I 
> delete and disable *all* of our adjustments.
> 
> As Simon wrote: "Conditional combination has a nasty combinatorial 
> explosion. I should hack up a regression test to build all possible 
> variants."
> 
> But obviously this wasn't done yet. If I leave everything as it is, its 
> building...
> 
> Perhaps I'll try another request on the dnsmasq-list during the next 
> days. The last one had no effect, no answers, nothing.
> 
> Best,
> Matthias
> 
> 
>
  

Hi,

On 19.01.2016 22:27, R. W. Rodolico wrote:
> Matthias,
> 
> I'm willing to do whatever you want with this to try and track the
> problem down. I can leave it at the current NS servers, or change them
> over. I'd recommend testing by leaving it pointing to the current NS
> servers for a while and see if it breaks again. Then, if it does, I'll
> move to the German servers and/or build my own.

Just in short:
I think you're right - this could be one possibility. If I were you, I
would choose the german servers, stay on the last published version and
see how this one is behaving.

You (and others) can ask at (any time) for the last version, no problem
- I'll keep this thing updated. Like Lauren wrote: "If you need
anything, just whistle..." ;-))

> I also think there have been so many updates to this that it makes it
> hard to say exactly what the problem is. I'd like to stay on one
> instance of dnsmasq for the testing period so we don't introduce any
> additional variables. That can be the new one you want to look at, or
> the one you uploaded (dnsmasq_275_2016_01_16) on the 16th. I have all
> the ones all the way back to 2015-12-18 still on my the router, so I can
> switch to any of them you want, but in order to say "it is a remote name
> server issue" it might be best to choose one and stick with it for a while.

ACK. The next two patches just came out (No.054 and 055), which should
fix other patches: its getting a bit tiring.

> As it stands now, on the 16th, I installed dnsmasq_275_2016_01_16 AND
> changed the name servers all at the same time (or maybe changed the name
> servers on the previous version, don't remember).

Doesn't matter. As you said: for now, stick with *one* version and test
with different nameservers. Update-patches are coming too fast at the
moment.

> OF COURSE, a solution might be to build a cron job that restarts dnsmasq
> every 12 hours or so :(

This would be the worst case for you, IMHO.

Best,
Matthias

> Rod
> 
> On 01/19/2016 01:59 PM, Matthias Fischer wrote:
>> Hi,
>> 
>> On 19.01.2016 08:39, R. W. Rodolico wrote:
>>> I installed this package yesterday and dnsmasq broke a few minutes ago.
>>> About 24 hours.
>> 
>> Worked for 24 hours and then crashed? Weird. But thinking of it, this
>> could be one of the reasons why its not crashing *here*. Every 24 hours
>> my ISP cuts the connection, and our router gets a new IP and 'dnsmasq'
>> restarts!
>> 
>>> Strange thing: when I was using the servers you recommended
>>> 84.200.69.80, 84.200.70.40
>>> I did not have any problems even though you have been updating very
>>> frequently. However, I reverted to the old DNS servers
>>> 209.244.0.3 8.8.4.4
>>> and in less than a few days (I think I did it with the 15th or 14th
>>> update), it broke again. Those servers are, respectively,
>>> resolver1.level3.net and one of the google ones.
>> 
>> So as I understand you, its related with the DNS servers you use!? With
>> your ISP servers, it crashes and with the german servers, it doesn't?
>> 
>>> Let me know if you want me to use the 84 DNS servers. Hell, I may just
>>> decide to build my own caching DNS servers!!!
>> 
>> Ok, solution found - that was easy... ;-))
>> 
>> But as long as I'm working on this, I'm more and more sure that these
>> intermediate crashes are really a combination between the DNS servers
>> and 'dnsmasq' itself. Sad to say, I haven't got the (C-)skills to debug
>> this.
>> 
>> Right now, I'm trying to compile 'dnsmasq' with patches 051-053: it now
>> crashes in 'forward.c' during compilation if I activate the
>> DNSSEC-option (-e 's|/\* #define HAVE_DNSSEC \*/|#define HAVE_DNSSEC|g'
>> \). Reason: patch No.053, I think.
>> 
>> In contrast, the '2.76test6'-version compiles without *any* error, if I
>> delete and disable *all* of our adjustments.
>> 
>> As Simon wrote: "Conditional combination has a nasty combinatorial
>> explosion. I should hack up a regression test to build all possible
>> variants."
>> 
>> But obviously this wasn't done yet. If I leave everything as it is, its
>> building...
>> 
>> Perhaps I'll try another request on the dnsmasq-list during the next
>> days. The last one had no effect, no answers, nothing.
>> 
>> Best,
>> Matthias
>> 
>
  

Hi,

On 20.01.2016 19:23, Kienker, Fred wrote:
> Could all of the issues be a conflict with the dnsmasq code and 
> *certain* DNS providers?
> ...

I have a suspicion that this is indeed the case... ;-)

Best,
Matthias
  

Hi,

I don't think that this is just *your* problem.

So far we have had random crashes of dnsmasq on random machines.
Sometimes that happens three times in a row within 10 minutes.
Sometimes that doesn't happen for a few months. We have had this with
many name servers. Some of which have been reported to "work better".
Some of which have been reported to work "worse". That also includes
8.8.8.8 and the LWL name servers.

So it is just you who is having the troubles more often than usual.
Maybe that will go away soon.

I am not fully convinced that the type of server plays a big role in
here. It might be something like the timing of the replies, etc. What
leads me to that idea is that the crashes are usually not reproducible
by a single query that goes wrong.

I can set up a recursor on the machine you set up for me. Just give it
an additional IP address and I will setup the resolver. I am
maintaining a few already, so this won't hurt at all.

Best,
-Michael

On Wed, 2016-01-20 at 12:58 -0600, R. W. Rodolico wrote:
> Ok. I just want to make sure this is not a local problem.
> 
> Am I the only one who is having issues? If so, then all this work has
> been for nothing. I was under the impression that there were several
> reports of this issue, but if I'm the only one having the problem,
> then
> I'll rebuild the test router (my home office router) and we'll put
> effort into something else.
> 
> Again, if several people are reporting it, it is something that needs
> to
> be fixed. But if I'm the only one with the issue, then it is probably
> *MY* problem, not a problem with something else.
> 
> Fred, I agree, it looks like it is a problem with dnsmaq and certain
> DNS
> providers, but I'm using Google and Level 3 for my tests and it fails
> every couple of weeks. I'm suspicious of the DNS servers which make
> money off their services by putting ads up (which it appears Level 3
> does. If you put an invalid domain name up, it comes up with an ad to
> purchase it. I have not looked at their traffic patterns to see what
> it
> is, but I had absolute no issues when I was using the German servers.
> 
> So, if you think this is a one off, let's get off the issue and I'll
> work on *MY* problem.
> 
> Let me know.
> 
> Rod
> 
> On 01/20/2016 12:23 PM, Kienker, Fred wrote:
> > The last update to dnsmasq has run fine on all of our IPFire
> > systems 
> > with the Google and Level 3 DNS servers for an extended period of
> > time. 
> > Could all of the issues be a conflict with the dnsmasq code and 
> > *certain* DNS providers? If so this seems like a much harder
> > problem to 
> > fix.
> > 
> > Fred
> > 
> > -----Original Message-----
> > From: Matthias Fischer [mailto:matthias.fischer@ipfire.org] 
> > Sent: Tuesday, January 19, 2016 2:59 PM
> > To: development@lists.ipfire.org
> > Subject: Re: [PATCH] dnsmasq 2.75: next patch... (No.50)
> > 
> > Hi,
> > 
> > On 19.01.2016 08:39, R. W. Rodolico wrote:
> > > I installed this package yesterday and dnsmasq broke a few
> > > minutes 
> > ago.
> > > About 24 hours.
> > 
> > Worked for 24 hours and then crashed? Weird. But thinking of it,
> > this 
> > could be one of the reasons why its not crashing *here*. Every 24
> > hours 
> > my ISP cuts the connection, and our router gets a new IP and
> > 'dnsmasq'
> > restarts!
> > 
> > > Strange thing: when I was using the servers you recommended 
> > > 84.200.69.80, 84.200.70.40 I did not have any problems even
> > > though you 
> > 
> > > have been updating very frequently. However, I reverted to the
> > > old DNS 
> > 
> > > servers
> > > 209.244.0.3 8.8.4.4
> > > and in less than a few days (I think I did it with the 15th or
> > > 14th 
> > > update), it broke again. Those servers are, respectively, 
> > > resolver1.level3.net and one of the google ones.
> > 
> > So as I understand you, its related with the DNS servers you use!?
> > With 
> > your ISP servers, it crashes and with the german servers, it
> > doesn't?
> > 
> > > Let me know if you want me to use the 84 DNS servers. Hell, I may
> > > just 
> > 
> > > decide to build my own caching DNS servers!!!
> > 
> > Ok, solution found - that was easy... ;-))
> > 
> > But as long as I'm working on this, I'm more and more sure that
> > these 
> > intermediate crashes are really a combination between the DNS
> > servers 
> > and 'dnsmasq' itself. Sad to say, I haven't got the (C-)skills to
> > debug 
> > this.
> > 
> > Right now, I'm trying to compile 'dnsmasq' with patches 051-053: it
> > now 
> > crashes in 'forward.c' during compilation if I activate the 
> > DNSSEC-option (-e 's|/\* #define HAVE_DNSSEC \*/|#define
> > HAVE_DNSSEC|g'
> > \). Reason: patch No.053, I think.
> > 
> > In contrast, the '2.76test6'-version compiles without *any* error,
> > if I 
> > delete and disable *all* of our adjustments.
> > 
> > As Simon wrote: "Conditional combination has a nasty combinatorial 
> > explosion. I should hack up a regression test to build all possible
> > variants."
> > 
> > But obviously this wasn't done yet. If I leave everything as it is,
> > its 
> > building...
> > 
> > Perhaps I'll try another request on the dnsmasq-list during the
> > next 
> > days. The last one had no effect, no answers, nothing.
> > 
> > Best,
> > Matthias
> > 
> > 
> > 
>
  

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, I don't know what a recursor is but you can use .194. It is
currently not being used. Is this permanent, ie do I label it as
"testing" or do you need it for a more permanent basis. If you need it
permanently, that is fine; I just need to know how to label it in our
database.

On 01/20/2016 05:51 PM, Michael Tremer wrote:
> Hi,
> 
> I don't think that this is just *your* problem.
> 
> So far we have had random crashes of dnsmasq on random machines. 
> Sometimes that happens three times in a row within 10 minutes. 
> Sometimes that doesn't happen for a few months. We have had this
> with many name servers. Some of which have been reported to "work
> better". Some of which have been reported to work "worse". That
> also includes 8.8.8.8 and the LWL name servers.
> 
> So it is just you who is having the troubles more often than
> usual. Maybe that will go away soon.
> 
> I am not fully convinced that the type of server plays a big role
> in here. It might be something like the timing of the replies, etc.
> What leads me to that idea is that the crashes are usually not
> reproducible by a single query that goes wrong.
> 
> I can set up a recursor on the machine you set up for me. Just give
> it an additional IP address and I will setup the resolver. I am 
> maintaining a few already, so this won't hurt at all.
> 
> Best, -Michael
> 
> On Wed, 2016-01-20 at 12:58 -0600, R. W. Rodolico wrote:
>> Ok. I just want to make sure this is not a local problem.
>> 
>> Am I the only one who is having issues? If so, then all this work
>> has been for nothing. I was under the impression that there were
>> several reports of this issue, but if I'm the only one having the
>> problem, then I'll rebuild the test router (my home office
>> router) and we'll put effort into something else.
>> 
>> Again, if several people are reporting it, it is something that
>> needs to be fixed. But if I'm the only one with the issue, then
>> it is probably *MY* problem, not a problem with something else.
>> 
>> Fred, I agree, it looks like it is a problem with dnsmaq and
>> certain DNS providers, but I'm using Google and Level 3 for my
>> tests and it fails every couple of weeks. I'm suspicious of the
>> DNS servers which make money off their services by putting ads up
>> (which it appears Level 3 does. If you put an invalid domain name
>> up, it comes up with an ad to purchase it. I have not looked at
>> their traffic patterns to see what it is, but I had absolute no
>> issues when I was using the German servers.
>> 
>> So, if you think this is a one off, let's get off the issue and
>> I'll work on *MY* problem.
>> 
>> Let me know.
>> 
>> Rod
>> 
>> On 01/20/2016 12:23 PM, Kienker, Fred wrote:
>>> The last update to dnsmasq has run fine on all of our IPFire 
>>> systems with the Google and Level 3 DNS servers for an extended
>>> period of time. Could all of the issues be a conflict with the
>>> dnsmasq code and *certain* DNS providers? If so this seems like
>>> a much harder problem to fix.
>>> 
>>> Fred
>>> 
>>> -----Original Message----- From: Matthias Fischer
>>> [mailto:matthias.fischer@ipfire.org] Sent: Tuesday, January 19,
>>> 2016 2:59 PM To: development@lists.ipfire.org Subject: Re:
>>> [PATCH] dnsmasq 2.75: next patch... (No.50)
>>> 
>>> Hi,
>>> 
>>> On 19.01.2016 08:39, R. W. Rodolico wrote:
>>>> I installed this package yesterday and dnsmasq broke a few 
>>>> minutes
>>> ago.
>>>> About 24 hours.
>>> 
>>> Worked for 24 hours and then crashed? Weird. But thinking of
>>> it, this could be one of the reasons why its not crashing
>>> *here*. Every 24 hours my ISP cuts the connection, and our
>>> router gets a new IP and 'dnsmasq' restarts!
>>> 
>>>> Strange thing: when I was using the servers you recommended 
>>>> 84.200.69.80, 84.200.70.40 I did not have any problems even 
>>>> though you
>>> 
>>>> have been updating very frequently. However, I reverted to
>>>> the old DNS
>>> 
>>>> servers 209.244.0.3 8.8.4.4 and in less than a few days (I
>>>> think I did it with the 15th or 14th update), it broke again.
>>>> Those servers are, respectively, resolver1.level3.net and one
>>>> of the google ones.
>>> 
>>> So as I understand you, its related with the DNS servers you
>>> use!? With your ISP servers, it crashes and with the german
>>> servers, it doesn't?
>>> 
>>>> Let me know if you want me to use the 84 DNS servers. Hell, I
>>>> may just
>>> 
>>>> decide to build my own caching DNS servers!!!
>>> 
>>> Ok, solution found - that was easy... ;-))
>>> 
>>> But as long as I'm working on this, I'm more and more sure
>>> that these intermediate crashes are really a combination
>>> between the DNS servers and 'dnsmasq' itself. Sad to say, I
>>> haven't got the (C-)skills to debug this.
>>> 
>>> Right now, I'm trying to compile 'dnsmasq' with patches
>>> 051-053: it now crashes in 'forward.c' during compilation if I
>>> activate the DNSSEC-option (-e 's|/\* #define HAVE_DNSSEC
>>> \*/|#define HAVE_DNSSEC|g' \). Reason: patch No.053, I think.
>>> 
>>> In contrast, the '2.76test6'-version compiles without *any*
>>> error, if I delete and disable *all* of our adjustments.
>>> 
>>> As Simon wrote: "Conditional combination has a nasty
>>> combinatorial explosion. I should hack up a regression test to
>>> build all possible variants."
>>> 
>>> But obviously this wasn't done yet. If I leave everything as it
>>> is, its building...
>>> 
>>> Perhaps I'll try another request on the dnsmasq-list during
>>> the next days. The last one had no effect, no answers,
>>> nothing.
>>> 
>>> Best, Matthias
>>> 
>>> 
>>> 

- -- 
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlagUvsACgkQuVY3UpYMlTSyCQCfTczs4yUYQnVp4q0SDG04JlMT
+4IAn3A0OXavE5z+nfvMB7G0xo05to+c
=3XWJ
-----END PGP SIGNATURE-----
  

Hi,

On 21.01.2016 00:51, Michael Tremer wrote:
> Hi,
> 
> I don't think that this is just *your* problem.
> 
> So far we have had random crashes of dnsmasq on random machines.
> Sometimes that happens three times in a row within 10 minutes.
> Sometimes that doesn't happen for a few months. We have had this with
> many name servers. Some of which have been reported to "work better".
> Some of which have been reported to work "worse". That also includes
> 8.8.8.8 and the LWL name servers.

Thanks - I didn't know all of these details yet.

> So it is just you who is having the troubles more often than usual.
> Maybe that will go away soon.

Keep your fingers crossed.

> I am not fully convinced that the type of server plays a big role in
> here. It might be something like the timing of the replies, etc. What
> leads me to that idea is that the crashes are usually not reproducible
> by a single query that goes wrong.

Anyway, patch No.056 came out a few minute ago: Coffee was updated, I'm
at it again, Devel is running.

> I can set up a recursor on the machine you set up for me. Just give it
> an additional IP address and I will setup the resolver. I am
> maintaining a few already, so this won't hurt at all.
> ...

@interested_testers: ;-))
One suggestion from me to make testing a bit easier, if you like, just
tell me your thoughts about this procedure:

I'll try to keep the files at http://people.ipfire.org/~mfischer/ up to
date as fast as possible. If anything goes wrong with the responsible
'dnsmasq'-version, look at my repository if there is an updated binary.
Look for "dnsmasq_[VERSION]_[DATE_BUILT]. As always: if it makes sense
for your test environment, feel free to grab it and continue testing.
Perhaps this makes the whole a bit easier for you and me. Don't ask for
the latest version, just grab it.

Having some consisting problems here, at last I'd like to ask:

With our 'dnsmasq'-lfs-config I always get the following two warnings
during compiling. This doesnt' happen while compiling the *original'
source!:

First:
***SNIP***
...
cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
-fstack-protector-all --param=ssp-buffer-size=4 -march=i586
-mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
-DVERSION='"2.75"'            -c dnsmasq.c	
dnsmasq.c: In function 'main':
dnsmasq.c:922:7: warning: implicit declaration of function
'do_script_run' [-Wimplicit-function-declaration]
       while (helper_buf_empty() && do_script_run(now));
       ^
dnsmasq.c:55:7: warning: unused variable 'did_bind' [-Wunused-variable]
   int did_bind = 0;
       ^
dnsmasq.c:54:9: warning: unused variable 'bound_device' [-Wunused-variable]
   char *bound_device = NULL;
         ^
cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
-fstack-protector-all --param=ssp-buffer-size=4 -march=i586
-mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
-DVERSION='"2.75"'            -c dhcp.c	
...
***SNAP***

Second:
***SNIP***
...
cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
-fstack-protector-all --param=ssp-buffer-size=4 -march=i586
-mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
-DVERSION='"2.75"'            -c isc.c	
isc.c: In function 'dhcp_lease_new':
isc.c:40:3: warning: ignoring return value of 'asprintf', declared with
attribute warn_unused_result [-Wunused-result]
   asprintf(&lease->fqdn, "%s.%s", hostname, daemon->domain_suffix);
   ^
cc  -o dnsmasq cache.o rfc1035.o util.o option.o forward.o network.o
dnsmasq.o dhcp.o lease.o rfc2131.o netlink.o dbus.o bpf.o helper.o
tftp.o log.o conntrack.o dhcp6.o rfc3315.o dhcp-common.o outpacket.o
radv.o slaac.o auth.o ipset.o domain.o dnssec.o blockdata.o tables.o
loop.o inotify.o poll.o rrfilter.o edns0.o arp.o isc.o -lidn
-lnettle -lhogweed   -lgmp
...
***SNAP***

Despite these warnings, the 'dnsmasq'-binary is usually built and is
running fine (here). But I'd like to get rid of these warnings and don't
know how (sorry, I'm no programmer). Asking in the 'dnsmasq'-list had no
effect, I got no answers at all.

Does anyone in here has a clue?

Best,
Matthias
  

FYI, the build from 2016-01-16 (dnsmasq_275_2016_01_16) has not had an
issue on my router since I installed it. I am 99% sure I installed it on
16 jan. AND, it is using the non-preferred DNS servers 209.244.0.3 &
8.8.4.4. I'm going to go ahead and change them to something better now.

Rod

On 01/23/2016 06:00 AM, Matthias Fischer wrote:
> Hi,
> 
> On 21.01.2016 00:51, Michael Tremer wrote:
>> Hi,
>>
>> I don't think that this is just *your* problem.
>>
>> So far we have had random crashes of dnsmasq on random machines.
>> Sometimes that happens three times in a row within 10 minutes.
>> Sometimes that doesn't happen for a few months. We have had this with
>> many name servers. Some of which have been reported to "work better".
>> Some of which have been reported to work "worse". That also includes
>> 8.8.8.8 and the LWL name servers.
> 
> Thanks - I didn't know all of these details yet.
> 
>> So it is just you who is having the troubles more often than usual.
>> Maybe that will go away soon.
> 
> Keep your fingers crossed.
> 
>> I am not fully convinced that the type of server plays a big role in
>> here. It might be something like the timing of the replies, etc. What
>> leads me to that idea is that the crashes are usually not reproducible
>> by a single query that goes wrong.
> 
> Anyway, patch No.056 came out a few minute ago: Coffee was updated, I'm
> at it again, Devel is running.
> 
>> I can set up a recursor on the machine you set up for me. Just give it
>> an additional IP address and I will setup the resolver. I am
>> maintaining a few already, so this won't hurt at all.
>> ...
> 
> @interested_testers: ;-))
> One suggestion from me to make testing a bit easier, if you like, just
> tell me your thoughts about this procedure:
> 
> I'll try to keep the files at http://people.ipfire.org/~mfischer/ up to
> date as fast as possible. If anything goes wrong with the responsible
> 'dnsmasq'-version, look at my repository if there is an updated binary.
> Look for "dnsmasq_[VERSION]_[DATE_BUILT]. As always: if it makes sense
> for your test environment, feel free to grab it and continue testing.
> Perhaps this makes the whole a bit easier for you and me. Don't ask for
> the latest version, just grab it.
> 
> Having some consisting problems here, at last I'd like to ask:
> 
> With our 'dnsmasq'-lfs-config I always get the following two warnings
> during compiling. This doesnt' happen while compiling the *original'
> source!:
> 
> First:
> ***SNIP***
> ...
> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586
> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
> -DVERSION='"2.75"'            -c dnsmasq.c	
> dnsmasq.c: In function 'main':
> dnsmasq.c:922:7: warning: implicit declaration of function
> 'do_script_run' [-Wimplicit-function-declaration]
>        while (helper_buf_empty() && do_script_run(now));
>        ^
> dnsmasq.c:55:7: warning: unused variable 'did_bind' [-Wunused-variable]
>    int did_bind = 0;
>        ^
> dnsmasq.c:54:9: warning: unused variable 'bound_device' [-Wunused-variable]
>    char *bound_device = NULL;
>          ^
> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586
> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
> -DVERSION='"2.75"'            -c dhcp.c	
> ...
> ***SNAP***
> 
> Second:
> ***SNIP***
> ...
> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586
> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
> -DVERSION='"2.75"'            -c isc.c	
> isc.c: In function 'dhcp_lease_new':
> isc.c:40:3: warning: ignoring return value of 'asprintf', declared with
> attribute warn_unused_result [-Wunused-result]
>    asprintf(&lease->fqdn, "%s.%s", hostname, daemon->domain_suffix);
>    ^
> cc  -o dnsmasq cache.o rfc1035.o util.o option.o forward.o network.o
> dnsmasq.o dhcp.o lease.o rfc2131.o netlink.o dbus.o bpf.o helper.o
> tftp.o log.o conntrack.o dhcp6.o rfc3315.o dhcp-common.o outpacket.o
> radv.o slaac.o auth.o ipset.o domain.o dnssec.o blockdata.o tables.o
> loop.o inotify.o poll.o rrfilter.o edns0.o arp.o isc.o -lidn
> -lnettle -lhogweed   -lgmp
> ...
> ***SNAP***
> 
> Despite these warnings, the 'dnsmasq'-binary is usually built and is
> running fine (here). But I'd like to get rid of these warnings and don't
> know how (sorry, I'm no programmer). Asking in the 'dnsmasq'-list had no
> effect, I got no answers at all.
> 
> Does anyone in here has a clue?
> 
> Best,
> Matthias
>
  

Hi,

On Sat, 2016-01-23 at 13:00 +0100, Matthias Fischer wrote:
> Anyway, patch No.056 came out a few minute ago: Coffee was updated,
> I'm
> at it again, Devel is running.

Will any of this be targeted to be included in C98?

> First:
> ***SNIP***
> ...
> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586
> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
> -DVERSION='"2.75"'            -c dnsmasq.c	
> dnsmasq.c: In function 'main':
> dnsmasq.c:922:7: warning: implicit declaration of function
> 'do_script_run' [-Wimplicit-function-declaration]
>        while (helper_buf_empty() && do_script_run(now));
>        ^
> dnsmasq.c:55:7: warning: unused variable 'did_bind' [-Wunused-
> variable]
>    int did_bind = 0;
>        ^
> dnsmasq.c:54:9: warning: unused variable 'bound_device' [-Wunused-
> variable]
>    char *bound_device = NULL;
>          ^
> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586
> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
> -DVERSION='"2.75"'            -c dhcp.c	
> ...
> ***SNAP***

Get in touch with Simon for this. It is nothing major. But good to
point it out.

> Second:
> ***SNIP***
> ...
> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586
> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
> -DVERSION='"2.75"'            -c isc.c	
> isc.c: In function 'dhcp_lease_new':
> isc.c:40:3: warning: ignoring return value of 'asprintf', declared
> with
> attribute warn_unused_result [-Wunused-result]
>    asprintf(&lease->fqdn, "%s.%s", hostname, daemon->domain_suffix);
>    ^
> cc  -o dnsmasq cache.o rfc1035.o util.o option.o forward.o network.o
> dnsmasq.o dhcp.o lease.o rfc2131.o netlink.o dbus.o bpf.o helper.o
> tftp.o log.o conntrack.o dhcp6.o rfc3315.o dhcp-common.o outpacket.o
> radv.o slaac.o auth.o ipset.o domain.o dnssec.o blockdata.o tables.o
> loop.o inotify.o poll.o rrfilter.o edns0.o arp.o isc.o -lidn
> -lnettle -lhogweed   -lgmp
> ...
> ***SNAP***

This is in my code. I made a patch for that:

http://git.ipfire.org/?p=people/ms/dnsmasq.git;a=commitdiff;h=bac82b4ff2f971a0227efb1a83f2b2bb1cd28764

You can also pull the entire branch from that repository to generate a
recent patch against the latest development version.

> 
> Despite these warnings, the 'dnsmasq'-binary is usually built and is
> running fine (here). But I'd like to get rid of these warnings and
> don't
> know how (sorry, I'm no programmer). Asking in the 'dnsmasq'-list had
> no
> effect, I got no answers at all.
> 
> Does anyone in here has a clue?
> 
> Best,
> Matthias
> 

-Michael
  

Hi,

On 05.02.2016 00:50, Michael Tremer wrote:
> Hi,
> 
> On Sat, 2016-01-23 at 13:00 +0100, Matthias Fischer wrote:
>> Anyway, patch No.056 came out a few minute ago: Coffee was updated,
>> I'm
>> at it again, Devel is running.
> 
> Will any of this be targeted to be included in C98?

Hard to say. The last posting from Rodolico (see above), using the build
from 2016-01-16 sounds good to me ("has not had an issue...since I
installed it"). Perhaps we got a grip on this, but its hard to tell for me.
The whole thing is still "under construction and testing", even the
patch from today (Fix breakage in ARP code...) looks important (to me).
But thats hard to judge. All I can say, every version didn't crash at
any time here. I'm still waiting for that. ;-)

>> First:
>> ***SNIP***
>> ...
>> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
>> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586
>> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
>> -DVERSION='"2.75"'            -c dnsmasq.c	
>> dnsmasq.c: In function 'main':
>> dnsmasq.c:922:7: warning: implicit declaration of function
>> 'do_script_run' [-Wimplicit-function-declaration]
>>        while (helper_buf_empty() && do_script_run(now));
>>        ^
>> dnsmasq.c:55:7: warning: unused variable 'did_bind' [-Wunused-
>> variable]
>>    int did_bind = 0;
>>        ^
>> dnsmasq.c:54:9: warning: unused variable 'bound_device' [-Wunused-
>> variable]
>>    char *bound_device = NULL;
>>          ^
>> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
>> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586
>> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
>> -DVERSION='"2.75"'            -c dhcp.c	
>> ...
>> ***SNAP***
> 
> Get in touch with Simon for this. It is nothing major. But good to
> point it out.

I did this before and got no answer. If I omit our lfs-adaptions and
switches, everythings running fine and without any compiling errors or
warnings, so I think it deals with our various options. I'll first try
to find out which option(s) exactly trigger these errors.

>> Second:
>> ***SNIP***
>> ...
>> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC
>> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586
>> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
>> -DVERSION='"2.75"'            -c isc.c	
>> isc.c: In function 'dhcp_lease_new':
>> isc.c:40:3: warning: ignoring return value of 'asprintf', declared
>> with
>> attribute warn_unused_result [-Wunused-result]
>>    asprintf(&lease->fqdn, "%s.%s", hostname, daemon->domain_suffix);
>>    ^
>> cc  -o dnsmasq cache.o rfc1035.o util.o option.o forward.o network.o
>> dnsmasq.o dhcp.o lease.o rfc2131.o netlink.o dbus.o bpf.o helper.o
>> tftp.o log.o conntrack.o dhcp6.o rfc3315.o dhcp-common.o outpacket.o
>> radv.o slaac.o auth.o ipset.o domain.o dnssec.o blockdata.o tables.o
>> loop.o inotify.o poll.o rrfilter.o edns0.o arp.o isc.o -lidn
>> -lnettle -lhogweed   -lgmp
>> ...
>> ***SNAP***
> 
> This is in my code. I made a patch for that:
> 
> http://git.ipfire.org/?p=people/ms/dnsmasq.git;a=commitdiff;h=bac82b4ff2f971a0227efb1a83f2b2bb1cd28764
> 
> You can also pull the entire branch from that repository to generate a
> recent patch against the latest development version.

I hope this was the right thing to do: I integrated this patch in the
existing 'dnsmasq-Add-support-to-read-ISC-DHCP-lease-file.patch'-file.
Warning is gone.

>> ...

Best,
Matthias
  

The 2016-01-16 build has been quite stable on a number of machines for 
me as well. That said, I did have a DNS lockup with the 
276test8_2016-01-27 on my test system so I have switched to the 
276test8_2016-02-05 build to see if it cures it.

Best regards,
Fred

-----Original Message-----
From: Matthias Fischer [mailto:matthias.fischer@ipfire.org] 
Sent: Friday, February 05, 2016 5:46 PM
To: Michael Tremer; R. W. Rodolico; development@lists.ipfire.org
Subject: Re: [PATCH] dnsmasq 2.75: next patch... (No.50)

Hi,

On 05.02.2016 00:50, Michael Tremer wrote:
> Hi,
> 
> On Sat, 2016-01-23 at 13:00 +0100, Matthias Fischer wrote:
>> Anyway, patch No.056 came out a few minute ago: Coffee was updated, 
>> I'm at it again, Devel is running.
> 
> Will any of this be targeted to be included in C98?

Hard to say. The last posting from Rodolico (see above), using the build 
from 2016-01-16 sounds good to me ("has not had an issue...since I 
installed it"). Perhaps we got a grip on this, but its hard to tell for 
me.
The whole thing is still "under construction and testing", even the 
patch from today (Fix breakage in ARP code...) looks important (to me).
But thats hard to judge. All I can say, every version didn't crash at 
any time here. I'm still waiting for that. ;-)

>> First:
>> ***SNIP***
>> ...
>> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC 
>> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586 
>> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
>> -DVERSION='"2.75"'            -c dnsmasq.c	
>> dnsmasq.c: In function 'main':
>> dnsmasq.c:922:7: warning: implicit declaration of function 
>> 'do_script_run' [-Wimplicit-function-declaration]
>>        while (helper_buf_empty() && do_script_run(now));
>>        ^
>> dnsmasq.c:55:7: warning: unused variable 'did_bind' [-Wunused- 
>> variable]
>>    int did_bind = 0;
>>        ^
>> dnsmasq.c:54:9: warning: unused variable 'bound_device' [-Wunused- 
>> variable]
>>    char *bound_device = NULL;
>>          ^
>> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC 
>> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586 
>> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
>> -DVERSION='"2.75"'            -c dhcp.c	
>> ...
>> ***SNAP***
> 
> Get in touch with Simon for this. It is nothing major. But good to 
> point it out.

I did this before and got no answer. If I omit our lfs-adaptions and 
switches, everythings running fine and without any compiling errors or 
warnings, so I think it deals with our various options. I'll first try 
to find out which option(s) exactly trigger these errors.

>> Second:
>> ***SNIP***
>> ...
>> cc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC 
>> -fstack-protector-all --param=ssp-buffer-size=4 -march=i586 
>> -mtune=generic -fomit-frame-pointer -DHAVE_ISC_READER -DNO_INOTIFY
>> -DVERSION='"2.75"'            -c isc.c	
>> isc.c: In function 'dhcp_lease_new':
>> isc.c:40:3: warning: ignoring return value of 'asprintf', declared 
>> with attribute warn_unused_result [-Wunused-result]
>>    asprintf(&lease->fqdn, "%s.%s", hostname, daemon->domain_suffix);
>>    ^
>> cc  -o dnsmasq cache.o rfc1035.o util.o option.o forward.o network.o 
>> dnsmasq.o dhcp.o lease.o rfc2131.o netlink.o dbus.o bpf.o helper.o 
>> tftp.o log.o conntrack.o dhcp6.o rfc3315.o dhcp-common.o outpacket.o 
>> radv.o slaac.o auth.o ipset.o domain.o dnssec.o blockdata.o tables.o 
>> loop.o inotify.o poll.o rrfilter.o edns0.o arp.o isc.o -lidn
>> -lnettle -lhogweed   -lgmp
>> ...
>> ***SNAP***
> 
> This is in my code. I made a patch for that:
> 
> http://git.ipfire.org/?p=people/ms/dnsmasq.git;a=commitdiff;h=bac82b4f
> f2f971a0227efb1a83f2b2bb1cd28764
> 
> You can also pull the entire branch from that repository to generate a 

> recent patch against the latest development version.

I hope this was the right thing to do: I integrated this patch in the 
existing 'dnsmasq-Add-support-to-read-ISC-DHCP-lease-file.patch'-file.
Warning is gone.

>> ...

Best,
Matthias
  

Hi,

On 05.02.2016 00:50, Michael Tremer wrote:
> Get in touch with Simon for this. It is nothing major. But good to
> point it out.

For the records:
The (two) warnings about "unused variables' are ONLY triggered when
deactivating DHCP in lfs-file through:

...
-e 's|#define HAVE_DHCP|//#define HAVE_DHCP|g' \
...

No other warnings or errors occured during my tests.

I asked about this in the dnsmasq mailing list. We'll see.

Best,
Matthias