From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] dnsmasq 2.75: next patch... (No.50) Date: Wed, 20 Jan 2016 23:51:21 +0000 Message-ID: <1453333881.585.9.camel@ipfire.org> In-Reply-To: <569FD8E7.9060503@dailydata.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7918301487562647973==" List-Id: --===============7918301487562647973== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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(a)ipfire.org] > > Sent: Tuesday, January 19, 2016 2:59 PM > > To: development(a)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 > > > > > > > --===============7918301487562647973== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRSWNCQUFC Q2dBR0JRSldvQjE1QUFvSkVJQjU4UDl2a0FrSEZkZ1FBSWl3ZzZCcitvUmF0SHRxcnlyTmtwejkK aVRqYmlLSVFPYnprdkRoUVAyeU1xdGxjaWJ1Z2tQNmxrVG8yQXdaUUVwVmFzOHd1RktsNm93dmJJ T2QrM1J4MwpsQjFCNkZoanJrYVNFV2VDMjBzbFJvcnVMTU8zcEs0dHo4L3BHUURQaVVuRTdocFlp NVhmajJiT3VGTFd0eHBqCkZXOUpXUG03dzF0RStnUWFWVVcvc1BGT1hCSkFRUDUwRFhzeEZVRDhs dUZJWGNJQ0psVEJRdHNPY0gvcVp6KysKdEhFa0dqM203MzYvNzQvNWh4VjROOGE0WWRtTVM4NFZm YzM1bXNlcFVxMnVwSXJiYVNBMWEvaEtuSWl2bHFQQQpGSWVBY3ZnMUNmNk4yMGtFeGpEL1pXcHVn RVJ4Tkg4R1p0L0FiYWxBa3hCR0lOU0hUNlczTENHRzF6K3JQQXhhCjN2bDFPOUxaR1htN3dYQ3hw T2VtNUF1cWVaeElKYkk4MlpqTUdJc214aWcxYlh0R2I4TWdYbUZEM00rVHpKQ2oKd05TdzEyVE1l L3hhcis3VVRzdFN2NEF3MmtoZVdhNEYrVGNINmozWWtwZk5aS3YvaFlNZGtKY1ByaG1BWWhvYwpZ YVNhMVRNMUdJcHdHbjhzWmc3a3JsakZDc2JXQmJ4K1g4UFVwSmVvbzBrRW9qelFBanF1NE1mdjBI RE9zNXVNCk93N1RNZUR3TS9BZjlldW4wS25VS0dVSDRyOTdCVW5XMlQyRmE4MzJaVjRFQzVUcjJV ZENRQ2tFTkVPd0M1LzAKSWtHcWljVmYyUEtnWVVjUXdBMy9aSUhtS1ZocmkvUWVsSCthdWpra2pa dUp5c0p4QmtUbEV6bkpDcjNOSHF3UwptMXFiTkkyQXQ1VXkySEFPM3RJUAo9bmJtNAotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============7918301487562647973==--