Re: [Dnsmasq-discuss] [PATCH] unittests
Hi, > https://github.com/themiron/dnsmasq Thank you for asking, it's my private mirrored master branch and related openssl fork (in separate branch). Updated occasionally from release to release, so hardly can be ~official mirror. -- Best Regards, Vladislav Grishenko > -Original Message- > From: - Neustradamus - > Sent: Thursday, April 15, 2021 7:27 PM > To: Petr Menšík ; dnsmasq- > disc...@lists.thekelleys.org.uk > Cc: webs...@sarvepalli.net; themiron...@gmail.com > Subject: Re: [Dnsmasq-discuss] [PATCH] unittests > Importance: High > > Hello Simon, and all others, > > Here, I see a fork of Dnsmasq on GitHub, thanks Petr :) > > Can you look for https://github.com/dnsmasq organization and add the > https://github.com/dnsmasq/dnsmasq after it? > And remove the old https://github.com/simonkelley/dnsmasq-collab which is a > fork of https://github.com/sei-vsarvepalli/dnsmasq-collab. > > The goal is to have a best development of Dnsmasq, and more contributors, > improvements etc. > It will be better to devs to fork directly the dnsmasq/dnsmasq. > > If this repo is a real mirror (without changes), I can see with Vladislav Grishenko > (themiron) to transfer directly into dnsmasq organization. > - https://github.com/themiron/dnsmasq > > Thanks in advance. > > Regards, > > Neustradamus > > > From: Dnsmasq-discuss on > behalf of Petr Menšík > Sent: Wednesday, April 14, 2021 19:35 > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: [Dnsmasq-discuss] [PATCH] unittests > > Hi Simon and other dnsmasq friends, > > after some struggling with Makefile support, I am sending my dnsmasq unit > tests. It uses another directory with tests specific code. I moved some common > parts to Makefile.config, in order to be able to reuse them. > Unit tests are under tests directory with own Makefile. > > New target make check should work also from top directory. Some checks > would work only from tests directory (make kyua). Current coverage is rather > poor, but I hope can be used as a building block to better tests. > Especially option parsing tests are easy to write. Testing of sending and > receiving packets seems to be difficult, it should be tested by different kind of > test IMHO. > > First is attempt to refactor, the second is what evolved into more complex set of > tests. > > Original separate commits are still available on github [1]. > > What do you think? > > PS: sending this message again, because patch #2 were big enough to require > moderator's approval. Compressed it as a workaround. > > Cheers, > Petr > > 1. https://github.com/InfrastructureServices/dnsmasq/tree/unittests > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemen...@redhat.com > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Fix HAVE_CRYPOHASH build and tune GOST/ECDSA usage
Hi Simon, > I committed a slightly more comprehensive clean up that fixes > this. Thank you, unfortunately it will not compile with 2.x and 3.0 nettle due no version.h. It was fixed in my original patch with bignum.h include at first place - for indirect version, if available. > This shouldn't be a problem, is both are not available, then the signatures cannot > be used. No problem, may then NO_GOST compile time option please be available to turn insecure GOST validation off when it's available in nettle? Before nettle 3.6 there was no such support, so GOST validation was actually not working. I'm ok to specially disable it to keep original behavior. > RFC8624 says it's a MAY. When that changes to MUST NOT, then we'll delete. Russian authority has draft since 2020 year for GOST R 34.11-2012 which will (although de facto already is) officially deprecate GOST R 34.10-2001, not standardized yet by IETF. https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-03 Maybe it makes sense for the decision, and nettle has no GOST R 34.11-2012 support at the moment. Thank you -- Best Regards, Vladislav Grishenko > -Original Message- > From: Dnsmasq-discuss On > Behalf Of Simon Kelley > Sent: Wednesday, April 14, 2021 3:44 AM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] [PATCH] Fix HAVE_CRYPOHASH build and tune > GOST/ECDSA usage > > On 10/04/2021 15:57, Vladislav Grishenko wrote: > > Hello, > > > > > > > > Recent nettle version detection changes in dnsmasq 2.85 have brought > > build regression with HAVE_CRYPTOHASH defined due no MIN_VERSION > macro > > is defined. > > That's not good. I committed a slightly more comprehensive clean up that fixes > this. > > I also built myself a script which test compiles with lots of different compile-time > options, to try and avoid this in the future. I counted 20 different options, so all > combinations at a million test combinations, and not practical. I do at least > check each one by itself, and interacting combinations. > > > > Also, DNSSEC GOST validation is not consistent in case only hash but > > not signature functions are available. > > > > This shouldn't be a problem, is both are not available, then the signatures cannot > be used. > > > Please refer patch set attached. > > > > > > > > As for disabling GOST, what if disable it by default? > > > > Current implemented GOST algos are obsolete, newer ones didn't pass > > certification as DNSSEC algo, so. > > > > > > > RFC8624 says it's a MAY. When that changes to MUST NOT, then we'll delete. > > > Simon. > > > > > > -- > > > > Best Regards, Vladislav Grishenko > > > > > > > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discu > > ss > > > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] Fix HAVE_CRYPOHASH build and tune GOST/ECDSA usage
Hello, Recent nettle version detection changes in dnsmasq 2.85 have brought build regression with HAVE_CRYPTOHASH defined due no MIN_VERSION macro is defined. Also, DNSSEC GOST validation is not consistent in case only hash but not signature functions are available. Please refer patch set attached. As for disabling GOST, what if disable it by default? Current implemented GOST algos are obsolete, newer ones didn't pass certification as DNSSEC algo, so. -- Best Regards, Vladislav Grishenko 0001-Fix-HAVE_CRYPOHASH-build-and-tune-GOST-ECDSA-usage.patch Description: Binary data 0002-Allow-to-disable-DNSSEC-GOST-algo-validation.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Rename HAVE_NETTLEHASH to HAVE_CRYPTOHASH
Hi Petr, > Where is openssl version used anyway? In https://asuswrt-merlin.net, embedded software for wireless routers > Would it make sense to support multiple crypto libraries? Taking into account existing official support of nettle and required support of system openssl (in asuswrt-merlin) - multilib support looks useful. Current dnsmasq-openssl work is here https://github.com/themiron/dnsmasq > Why is just nettle support inadequate? Because of additional ram/flash footprint, libnettle is used only by dnsmasq among the rest of firmware packages. > Our crypto team asked me, why is nettle used. I believe nettle was picked due openssl licensing incompatibility while initial dnssec approach was done with openssl. Another point is memory usage with openssl, allocations are dynamic so frequent allocations/frees are expected unlike mostly-static nettle. Simon may give more light on this. > It has no independent FIPS ceritification, so they would like to use > different library, like gnutls or openssl. Is that similar reason to yours? My reasons are above, fortunately certification is not an issue for 3rd party project. As for openssl license, 3.x version is compatible, and 1.x has no license issue if used as system library (as we have). Ggnutls support implementation seems possible for me, almost like openssl, tho till this moment I was not really interested (we have no gnutls used in our project). > I just did not think long about the name, CRYPTOHASH sound much better. > Thanks! Np > > On 1/25/21 10:53 AM, Vladislav Grishenko wrote: > > Hi, > > > >> Patch modified to keep backwards compatibility with HAVE_NETTLEHASH > >> because, why not? and applied. Looks like a sensible idea. > > > > Indeed, much better. Thank you > > > > -- > > Best Regards, Vladislav Grishenko > > > >> -Original Message- > >> From: Dnsmasq-discuss > >> On Behalf Of Simon > >> Kelley > >> Sent: Monday, January 25, 2021 3:15 AM > >> To: dnsmasq-discuss@lists.thekelleys.org.uk > >> Subject: Re: [Dnsmasq-discuss] [PATCH] Rename HAVE_NETTLEHASH to > >> HAVE_CRYPTOHASH > >> > >> On 24/01/2021 14:30, Vladislav Grishenko wrote: > >>> Hi, > >>> > >>> > >>> > >>> Commit 2024f9729713fd657d65e64c2e4e471baa0a3e5b "Support hash > >> function > >>> from nettle (only)" has introduced HAVE_NETTLEHASH option (thanks, > > Petr!). > >>> But, I think, there's no much sense to bind feature name to specific > >>> cryptolib because this will require rename or introduce more similar > >>> opts for some other cryptolib backend if/when it'll be available > >>> (for example in my dnsmasq-openssl fork). > >>> > >>> If no objections, let's name it "cryptohash" early before 2.84 is out? > >>> Sorry, have missed pre-2.83, but it has dns issues so unlikely be > >>> widely deployed. > >>> > >>> Please refer patch attached. > >>> > >>> > >> > >> Patch modified to keep backwards compatibility with HAVE_NETTLEHASH > >> because, why not? and applied. Looks like a sensible idea. > >> > >> > >> > >> Cheers, > >> > >> Simon. > >> > >>> > >>> -- > >>> > >>> Best Regards, Vladislav Grishenko > >>> > >>> > >>> > >>> > >>> ___ > >>> Dnsmasq-discuss mailing list > >>> Dnsmasq-discuss@lists.thekelleys.org.uk > >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >>> > >> > >> > >> ___ > >> Dnsmasq-discuss mailing list > >> Dnsmasq-discuss@lists.thekelleys.org.uk > >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemen...@redhat.com > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Rename HAVE_NETTLEHASH to HAVE_CRYPTOHASH
Hi, > Patch modified to keep backwards compatibility with HAVE_NETTLEHASH > because, why not? and applied. Looks like a sensible idea. Indeed, much better. Thank you -- Best Regards, Vladislav Grishenko > -Original Message- > From: Dnsmasq-discuss On > Behalf Of Simon Kelley > Sent: Monday, January 25, 2021 3:15 AM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] [PATCH] Rename HAVE_NETTLEHASH to > HAVE_CRYPTOHASH > > On 24/01/2021 14:30, Vladislav Grishenko wrote: > > Hi, > > > > > > > > Commit 2024f9729713fd657d65e64c2e4e471baa0a3e5b "Support hash > function > > from nettle (only)" has introduced HAVE_NETTLEHASH option (thanks, Petr!). > > But, I think, there's no much sense to bind feature name to specific > > cryptolib because this will require rename or introduce more similar > > opts for some other cryptolib backend if/when it'll be available (for > > example in my dnsmasq-openssl fork). > > > > If no objections, let's name it "cryptohash" early before 2.84 is out? > > Sorry, have missed pre-2.83, but it has dns issues so unlikely be > > widely deployed. > > > > Please refer patch attached. > > > > > > Patch modified to keep backwards compatibility with HAVE_NETTLEHASH > because, why not? and applied. Looks like a sensible idea. > > > > Cheers, > > Simon. > > > > > -- > > > > Best Regards, Vladislav Grishenko > > > > > > > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] Rename HAVE_NETTLEHASH to HAVE_CRYPTOHASH
Hi,
Commit 2024f9729713fd657d65e64c2e4e471baa0a3e5b "Support hash function from
nettle (only)" has introduced HAVE_NETTLEHASH option (thanks, Petr!).
But, I think, there's no much sense to bind feature name to specific
cryptolib because this will require rename or introduce more similar opts
for some other cryptolib backend if/when it'll be available (for example in
my dnsmasq-openssl fork).
If no objections, let's name it "cryptohash" early before 2.84 is out?
Sorry, have missed pre-2.83, but it has dns issues so unlikely be widely
deployed.
Please refer patch attached.
--
Best Regards, Vladislav Grishenko
>From d0a80d2ba18cb8d6bf3e93b66656ca5a9339df9f Mon Sep 17 00:00:00 2001
From: Vladislav Grishenko
Date: Sun, 24 Jan 2021 19:15:31 +0500
Subject: [PATCH] Rename HAVE_NETTLEHASH to HAVE_CRYPTOHASH
There's no much sense to bind feature name to specific cryptolib
because this will require rename or introduce more similar opts
for some other cryptolib backend if/when it'll be available.
So, let's name it "cryptohash" early before 2.84 is out, 2.83
has dns issues so unlikely be widely deployed.
---
Makefile | 4 ++--
src/config.h | 10 +-
src/crypto.c | 2 +-
src/dnsmasq.h| 2 +-
src/hash_questions.c | 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index 7d2afd1..92bc811 100644
--- a/Makefile
+++ b/Makefile
@@ -63,9 +63,9 @@ ct_libs = `echo $(COPTS) | $(top)/bld/pkg-wrapper
HAVE_CONNTRACK $(PKG_CON
lua_cflags =`echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT
$(PKG_CONFIG) --cflags lua5.2`
lua_libs = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT
$(PKG_CONFIG) --libs lua5.2`
nettle_cflags = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_DNSSEC
$(PKG_CONFIG) --cflags 'nettle hogweed' \
-HAVE_NETTLEHASH
$(PKG_CONFIG) --cflags nettle`
+HAVE_CRYPTOHASH
$(PKG_CONFIG) --cflags nettle`
nettle_libs = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_DNSSEC
$(PKG_CONFIG) --libs 'nettle hogweed' \
-HAVE_NETTLEHASH
$(PKG_CONFIG) --libs nettle`
+HAVE_CRYPTOHASH
$(PKG_CONFIG) --libs nettle`
gmp_libs = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_DNSSEC NO_GMP
--copy -lgmp`
sunos_libs =`if uname | grep SunOS >/dev/null 2>&1; then echo -lsocket
-lnsl -lposix4; fi`
version = -DVERSION='\"`$(top)/bld/get-version $(top)`\"'
diff --git a/src/config.h b/src/config.h
index e71a117..ba461b7 100644
--- a/src/config.h
+++ b/src/config.h
@@ -120,8 +120,8 @@ HAVE_AUTH
define this to include the facility to act as an authoritative DNS
server for one or more zones.
-HAVE_NETTLEHASH
- include just hash function from nettle, but no DNSSEC.
+HAVE_CRYPTOHASH
+ include just hash function from crypto library, but no DNSSEC.
HAVE_DNSSEC
include DNSSEC validator.
@@ -190,7 +190,7 @@ RESOLVFILE
/* #define HAVE_IDN */
/* #define HAVE_LIBIDN2 */
/* #define HAVE_CONNTRACK */
-/* #define HAVE_NETTLEHASH */
+/* #define HAVE_CRYPTOHASH */
/* #define HAVE_DNSSEC */
@@ -424,10 +424,10 @@ static char *compile_opts =
"no-"
#endif
"auth "
-#if !defined(HAVE_NETTLEHASH) && !defined(HAVE_DNSSEC)
+#if !defined(HAVE_CRYPTOHASH) && !defined(HAVE_DNSSEC)
"no-"
#endif
-"nettlehash "
+"cryptohash "
#ifndef HAVE_DNSSEC
"no-"
#endif
diff --git a/src/crypto.c b/src/crypto.c
index 09525d2..5f4c390 100644
--- a/src/crypto.c
+++ b/src/crypto.c
@@ -27,7 +27,7 @@
#endif
#endif
-#if defined(HAVE_DNSSEC) || defined(HAVE_NETTLEHASH)
+#if defined(HAVE_DNSSEC) || defined(HAVE_CRYPTOHASH)
#include
#include
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 360c226..e108359 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -157,7 +157,7 @@ extern int capget(cap_user_header_t header, cap_user_data_t
data);
#include
#endif
-#if defined(HAVE_DNSSEC) || defined(HAVE_NETTLEHASH)
+#if defined(HAVE_DNSSEC) || defined(HAVE_CRYPTOHASH)
# include
#endif
diff --git a/src/hash_questions.c b/src/hash_questions.c
index 51d88c2..90fa9f8 100644
--- a/src/hash_questions.c
+++ b/src/hash_questions.c
@@ -28,7 +28,7 @@
#include "dnsmasq.h"
-#if defined(HAVE_DNSSEC) || defined(HAVE_NETTLEHASH)
+#if defined(HAVE_DNSSEC) || defined(HAVE_CRYPTOHASH)
unsigned char *hash_questions(struct dns_header *header, size_t plen, char
*name)
{
int q;
--
2.17.1
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Convert dnsmasq log timestamp to use timespec.
Hi,
timespec_get() can be not available on all the supported platforms/libc*.
For glibc (since ~2.17) please refer
https://www.gnu.org/software/gnulib/manual/html_node/timespec_005fget.html
Using other functions may require linking with additional libs (rt for
example).
I'd suggest to reconsider the msec/nsec time source.
--
Best Regards, Vladislav Grishenko
> -Original Message-
> From: Dnsmasq-discuss On
> Behalf Of Cody Carey
> Sent: Monday, October 12, 2020 2:12 AM
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: [Dnsmasq-discuss] [PATCH] Convert dnsmasq log timestamp to use
> timespec.
>
> This patch converts log timestamps to an RFC3339 format and includes
> nanoseconds. This provides more complete timestamp information and
> granularity. This is particularly important when dealing with SIEM's and
other log
> analysis systems where less specific timestamps can cause out-of-order
issues,
> particularly where UDP is used.
>
> From ffd56111d61021f709967caf3767fbda19785d20 Mon Sep 17 00:00:00 2001
> From: Cody Carey <17598826+codyaca...@users.noreply.github.com>
> Date: Sun, 11 Oct 2020 17:01:59 -0400
> Subject: [PATCH] Convert dnsmasq log timestamp to use timespec.
>
> Signed-off-by: Cody Carey <17598826+codyaca...@users.noreply.github.com>
> ---
> src/log.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/src/log.c b/src/log.c
> index dbd6bd4..6e273aa 100644
> --- a/src/log.c
> +++ b/src/log.c
> @@ -278,7 +278,7 @@ void my_syslog(int priority, const char *format, ...)
{
>va_list ap;
>struct log_entry *entry;
> - time_t time_now;
> + struct timespec ts;
>char *p;
>size_t len;
>pid_t pid = getpid();
> @@ -364,14 +364,20 @@ void my_syslog(int priority, const char *format,
...)
> tmp->next = entry;
> }
>
> - time(&time_now);
> + timespec_get(&ts, TIME_UTC);
>p = entry->payload;
>if (!log_to_file)
> p += sprintf(p, "<%d>", priority | log_fac);
>
>/* Omit timestamp for default daemontools situation */
>if (!log_stderr || !option_bool(OPT_NO_FORK))
> - p += sprintf(p, "%.15s ", ctime(&time_now) + 4);
> +{
> + char timestamp[100];
> + char timezone[6];
> + strftime(timestamp, sizeof timestamp, "%FT%T",
gmtime(&ts.tv_sec));
> + strftime(timezone, sizeof timezone, "%z", gmtime(&ts.tv_sec));
> + p += sprintf(p, "%s.%09ld%s ", timestamp, ts.tv_nsec,
timezone);
> +}
>
>p += sprintf(p, "dnsmasq%s[%d]: ", func, (int)pid);
>
> --
> 2.25.1
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] Add DHCPv6 NTP server option handling
Hi, Simon There was discussion in the past regarding DHCPv6 NTP server option which needs special subclassing per RFC5908. Patch adds support for unicast, multicast IPv6 address and for FQDN string, preserving possibly used (as suggested earlier) hex value. Unfortunately it's still not fully free from limitations - only address list or only fqdn value list is possible, not mixed due current state option parsing & flagging. Would be nice to have it in 2.81. Hi Kevin, FYI Thank you and Best Regards, Vladislav Grishenko 0001-Add-DHCPv6-ntp-server-56-option-handling.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Remove ECC-GOST (GOST R 34.10-2001) algorithm as this is set to status MUST NOT implement in RFC 8624
Sorry, overlooked it (along with GOST R 34.11-94) must not be used for signing/delegation, but still may - for validation. Please ignore previous mail. Best Regards, Vladislav Grishenko -Original Message- From: Vladislav Grishenko Sent: Sunday, March 1, 2020 10:00 PM To: 'Simon Kelley' ; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Remove ECC-GOST (GOST R 34.10-2001) algorithm as this is set to status MUST NOT implement in RFC 8624 Hi Simon, Thank you for the DSA update. According https://tools.ietf.org/html/rfc8624 ECC-GOST must not be implemented too: ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 in [RFC7091]. GOST R 34.10-2012 hasn't been standardized for use in DNSSEC. Maybe worth to drop it too and save a couple of bytes? Thank you and Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Remove ECC-GOST (GOST R 34.10-2001) algorithm as this is set to status MUST NOT implement in RFC 8624
Hi Simon, Thank you for the DSA update. According https://tools.ietf.org/html/rfc8624 ECC-GOST must not be implemented too: ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 in [RFC7091]. GOST R 34.10-2012 hasn't been standardized for use in DNSSEC. Maybe worth to drop it too and save a couple of bytes? Thank you and Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Remove DSA-NSEC3-SHA1 & DSA DNSSEC algorithm as this is set to status MUST NOT implement in RFC 8624
Hi, Have that since last year with possibility to reenable with HAVE_DNS build-time define: https://github.com/themiron/dnsmasq/commit/5a1a8bc039561455677e825194f470219093aaf6.patch Also, GOST is obsolete and GOST2012 is not standardized yet. This helps to turn it off by default: https://github.com/themiron/dnsmasq/commit/a9ef96041fd0b594b662cbcb1a9b475844a4a5ab.patch p.s Please ignore ctypto-openssl.c part, it's not part of official dnsmasq source. Best Regards, Vladislav Grishenko -Original Message- From: Dnsmasq-discuss On Behalf Of Loganaden Velvindron Sent: Monday, February 24, 2020 12:08 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] Remove DSA-NSEC3-SHA1 & DSA DNSSEC algorithm as this is set to status MUST NOT implement in RFC 8624 Google might mangle the patch. Feedback welcomed. RFC 8624 Section 3.1 (https://www.rfc-editor.org/rfc/rfc8624.txt )says: 3 | DSA| MUST NOT| MUST NOT 6 | DSA-NSEC3-SHA1 | MUST NOT| MUST NOT I've added them on this gh repo: 1) Remove DSA-NSEC3-SHA1 DNSSEC algorithm as this is set to status MUST NOT implement in RFC 8624: https://raw.githubusercontent.com/cyberstormdotmu/dnsmasq_dnssec_patches/master/0001-Remove-DSA-NSEC3-SHA1-DNSSEC-algorithm-as-this-is-se.patch 2) Remove DSA DNSSEC algorithm as this is set to status MUST NOT implement in RFC 8624: https://github.com/cyberstormdotmu/dnsmasq_dnssec_patches/blob/master/0002-Remove-DSA-DNSSEC-algorithm-as-this-is-set-to-status.patch ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] CPU spinning bug, possibly related to SSHFP queries
Hi Tore, Can you try to capture dns exchange to dnsmasq (on lo interface) and from it (on your nic interface) both at the same time? $ tcpdump -i lo port 53 -w /path/to/dns-lo.pcap $ tcpdump -i port 53 -w /path/to/dns-ext.pcap Highly possible that trigger query (or reply) can't be logged in usual way, but will be captured by tcpdump. Next, I'd like to take a look at them, will there be something after/near the last logged query before spinning starts. p.s. Caution, pcap files will contain all your dns traffic, sending it to mail list might be not a really good idea. Best Regards, Vladislav Grishenko -Original Message- From: Dnsmasq-discuss On Behalf Of Tore Anderson Sent: Thursday, November 28, 2019 12:38 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] CPU spinning bug, possibly related to SSHFP queries Hello, I've noticed that Dnsmasq on my system sometimes enters a defective state where it starts spinning on the CPU. When it has entered this state, I need to send it SIGKILL to get rid of it - SIGTERM is ignored. The version is current Git master (2.80-93-g6ebdc95). I've enabled query logging and grabbed the final log lines of a few incidents (slightly anonymised): Example 1: forwarded git.i.example.org to 192.168.33.1 reply git.i.example.org is reply git01-osl3.i.example.org is 10.22.3.196 reply git.i.example.org is reply git01-osl3.i.example.org is 2001:db8:400:c:18:59ff:fe7a:73c4 query[type=44] git.i.example.org from 127.0.0.1 (CPU spin begins) Example 2: query[A] s2-a8-osl3.n.example.org from 127.0.0.1 forwarded s2-a8-osl3.n.example.org to 192.168.33.1 query[] s2-a8-osl3.n.example.org from 127.0.0.1 forwarded s2-a8-osl3.n.example.org to 192.168.33.1 reply s2-a8-osl3.n.example.org is reply lo.s2-a8-osl3.n.example.org is 2001:db8:1::4:1 reply s2-a8-osl3.n.example.org is reply lo.s2-a8-osl3.n.example.org is 192.168.63.11 query[type=44] s2-a8-osl3.n.example.org from 127.0.0.1 (CPU spin begins) Example 3: query[A] s1-a8-osl3.n.example.org from 127.0.0.1 forwarded s1-a8-osl3.n.example.org to 192.168.33.1 query[] s1-a8-osl3.n.example.org from 127.0.0.1 forwarded s1-a8-osl3.n.example.org to 192.168.33.1 reply s1-a8-osl3.n.example.org is reply lo.s1-a8-osl3.n.example.org is 192.168.63.10 reply s1-a8-osl3.n.example.org is reply lo.s1-a8-osl3.n.example.org is 2001:db8:1::4:0 query[type=44] s1-a8-osl3.n.example.org from 127.0.0.1 (CPU spin begins) All of them ends with an incoming query for SSHFP records (type 44), which I find highly suspect. The SSHFP requests comes from the SSH client (due to VerifyHostKeyDNS being set in my ~/.ssh/config). None of the hostnames in question do have SSHFP records published, but that does not seem to matter, as the query does not seem to be forwarded upstream in the first place. When the bug does not occur, Dnsmasq does log that it forwards the query upstream, like so: query[type=44] l1-a9-osl3.n.example.org from 127.0.0.1 forwarded l1-a9-osl3.n.example.org to 192.168.33.1 Dnsmasq is invoked from NetworkManager, using the following command line: /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/NetworkManager/dnsmasq.pid --listen-address=127.0.0.1 --cache-size=400 --clear-on-reload --conf-file=/dev/null --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d Additional configuration in /etc/NetworkManager/dnsmasq.d/dnssec.conf: dnssec conf-file = /usr/share/dnsmasq/trust-anchors.conf log-queries Finally, my environment contains RES_OPTIONS=edns0 in case that is relevant (this is required for SSH's VerifyHostKeyDNS feature to work correctly). I cannot reliably reproduce the issue. It seems to happen regularly (several times a day) during normal usage - I use the SSH client quite frequently. I would be happy to provide additional debugging information, if given instructions on how to obtain it.' Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [BUG] RA are sent too fast and slows down the machine
Hi, Petr, Just worrying, isn't this bug a side effect of previous interface-related binding patch we're talking about? If yes, since it's not in upstream, it can be quite tricky to reproduce it on vanilla sources. Best Regards, Vladislav Grishenko -Original Message- From: Dnsmasq-discuss On Behalf Of Petr Mensik Sent: Wednesday, August 28, 2019 12:11 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] [BUG] RA are sent too fast and slows down the machine Hi Iain, of course. I am sorry, forgot to add a link as intended[1]. Used base report from Network Manager tester report. I added it to Fedora bug mentioned, but forgot to add script itself. At least to me, it produces tens of RA announces. Regards, Petr [1] https://github.com/InfrastructureServices/dnsmasq-tests/blob/master/bz1739797.sh On 8/27/19 10:45 AM, Iain Lane wrote: > On Wed, Aug 21, 2019 at 08:59:07PM +0200, Petr Mensik wrote: >> Hi Simon and Maarten, >> >> we discovered when playing with NetworkManager-ci [1], that lastest >> release is somehow broken. Test running dnsmasq are quite slow on >> latest release. >> >> I have created repeatable started script that reproduces it. Then >> used git bisect to find when it was broken. It seems fast sending >> were intentional in commit 0a496f059c1e9 [2], but maybe way it >> affects the system were underestimated. It is significant for systems >> that hit such issue. I think it has to be fixed to slow it down to >> short time interval, not endless loop. Reported as Fedora bug [3]. > > Thanks for this Petr. Would you be able to share the script you've > used, so that perhaps an upstream developer could recreate the bug? > > Mainly I wanted to chime in and say that (in addition to the other > instance referenced), we found this in the NetworkManager testsuite in > Ubuntu. I didn't come up with a nice reproducer at the time, but we > did identify the same commit and we've reverted it in Ubuntu. I posted > on the ML back then but we didn't get much traction and I didn't > follow up very aggressively. > > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012709 > .html > > > https://launchpadlibrarian.net/405377161/dnsmasq_2.80-1_2.80-1ubuntu1.diff.gz > (the commit ID referenced in the changelog there seems or from > somewhere else, it's the same patch) > > Cheers, > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated interfaces.
Hi Petr,
> Not tested this specific case, but I think it should be handled correctly,
> unlike previous code. Because it now compares also interface index, it will
> mark existing entry as found only if interface index also match. If it does
> not, new entry is created with correct index instead.
Checked, unfortunately interface index comparison breaks the things.
If there's 2+ interface with same address on startup, no error is happen,
single TCP and multiple UDP (unlike before) sockets are created, on any of such
interface shutdown - thins single TCP socket is closed (unlike before), so
there are noting listens on TCP:53 after that.
If there's only one interface on startup - single TCP&UDP sockets are created,
on subsequent interface up with the same address - bind error raised and only
UDP socket is created additionally (unlike before).
At the moment, dnsmasq logic expects single TCP/UDP socket per address even for
multiple interfaces.
For example, comment in iface_allowed() states that:
/* check whether the interface IP has been added already
* we call this routine multiple times */
So, I'm afraid, seems proposed changes does not play well with that.
How do you think, can it be solved too?
Reproduction this case is quite easy, just need to create dummy interface with
same address (different netmask) and up/down it.
> Ok, I forgot to follow style on 3rd patch. Attached fixed formatting and
> removed debug log on interface removal.
Thanks, fyi sed -r 's/[ ]{8}/\t/' is missed too.
> I think that is better to state explicitly return value is not used.
I think that would be better to rip it off from functional patch, and let it be
as separate full patch for all prettyprint_* instances not just for some
selected.
At the other hand, with no __attribute__((warn_unused_result)) it will not
generate warning anyway.
Best Regards, Vladislav Grishenko
-Original Message-
From: Petr Mensik
Sent: Wednesday, July 10, 2019 3:01 PM
To: Vladislav Grishenko ;
dnsmasq-discuss@lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated
interfaces.
Hi Vladislav
On 7/9/19 10:00 PM, Vladislav Grishenko wrote:
> Hi Petr,
>
> Regarding 0002-Compare-address-and-interface-index-for-allowed-inte.patch,
> does it support case with different valid interfaces with the same address?
> For example:
> eth0 192.168.1.1/24
> tun0 192.168.1.1./16 (created/destroyed dynamically)
Not tested this specific case, but I think it should be handled correctly,
unlike previous code. Because it now compares also interface index, it will
mark existing entry as found only if interface index also match. If it does
not, new entry is created with correct index instead.
It should work, unlike previous code, it should keep both interface addresses
stored separately.
If tun0 is often destroyed and recreated, number of interfaces records might
grow. That is reason for patch #3, which removes dropped interfaces after
creating new ones.
>
> Regarding appearance, seems newly added code doesn’t fully follow dnsmasq
> code style in several places:
> * indentation (should be ident ==2 spaces, 8 spaces == \t)
> * brackets on the same code lines
Ok, I forgot to follow style on 3rd patch. Attached fixed formatting and
removed debug log on interface removal.
> * function args on the next line are not aligned with the first
> argument
> * prettyprint_addr() result is forcibly ignored with (void) unlike
> other places
I think that is better to state explicitly return value is not used.
>
> Best Regards, Vladislav Grishenko
>
> -Original Message-
> From: Dnsmasq-discuss
> On Behalf Of Petr
> Mensik
> Sent: Tuesday, July 9, 2019 5:31 PM
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated
> interfaces.
>
> Hello Simon and others,
>
> we have discovered issues with TCP DNS query on dnsmasq, when running in
> bind-dynamic or bind-interfaces mode. dnsmasq scans automatically new
> interfaces or do that on new query in second case. However, because used
> speedup comparing only IP adresses in iface_allowed function, it never gets
> updated index of an interface.
>
> In case where named interface is destroyed and created again, that drops TCP
> queries on that interface. They are checked for incoming interface number. If
> such number is not found in interfaces list, query is denied.
>
> Luckily, there was a bug in checking, hiding this problem from usual
> configuration. If IPv6 address is enabled on the new device, new iface entry
> would be created, because scope_id of sockaddr_in6 does not match previous.
> That makes even IPv4 queries succeed.
>
> Bug on bugzilla [1] is par
Re: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated interfaces.
Hi Petr, Regarding 0002-Compare-address-and-interface-index-for-allowed-inte.patch, does it support case with different valid interfaces with the same address? For example: eth0 192.168.1.1/24 tun0 192.168.1.1./16 (created/destroyed dynamically) Regarding appearance, seems newly added code doesn’t fully follow dnsmasq code style in several places: * indentation (should be ident ==2 spaces, 8 spaces == \t) * brackets on the same code lines * function args on the next line are not aligned with the first argument * prettyprint_addr() result is forcibly ignored with (void) unlike other places Best Regards, Vladislav Grishenko -Original Message- From: Dnsmasq-discuss On Behalf Of Petr Mensik Sent: Tuesday, July 9, 2019 5:31 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] [PATCH] Issues with TCP queries on recreated interfaces. Hello Simon and others, we have discovered issues with TCP DNS query on dnsmasq, when running in bind-dynamic or bind-interfaces mode. dnsmasq scans automatically new interfaces or do that on new query in second case. However, because used speedup comparing only IP adresses in iface_allowed function, it never gets updated index of an interface. In case where named interface is destroyed and created again, that drops TCP queries on that interface. They are checked for incoming interface number. If such number is not found in interfaces list, query is denied. Luckily, there was a bug in checking, hiding this problem from usual configuration. If IPv6 address is enabled on the new device, new iface entry would be created, because scope_id of sockaddr_in6 does not match previous. That makes even IPv4 queries succeed. Bug on bugzilla [1] is partly private. I propose three changes. First is just helper to log what happens with listeners on bind-dynamic configuration. Second is the most important. Create new interface every time index changes. Also test address family of incoming TCP query when checking allowed clients. Third is cleanup of unused interfaces. On some virtual machines hosts, interfaces may often be created and destroyed. It might have negative effect on walking trough interfaces list. I think listeners should be garbage collected also on bind-interfaces configuration. But for now, release memory for unused interfaces at least for bind-dynamic. 1. https://bugzilla.redhat.com/show_bug.cgi?id=1721668 -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] nettle 3.5 breaks build of dnsmasq
Hi Juergen, Temporary workaround/patch is here https://github.com/themiron/dnsmasq/commit/6fd9aba7abe1e084123bc5002959350897774ace Best Regards, Vladislav Grishenko -Original Message- From: Dnsmasq-discuss On Behalf Of Juergen Daubert Sent: Wednesday, June 26, 2019 4:57 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] nettle 3.5 breaks build of dnsmasq Hi, just discovered that new version 3.5 of nettle breaks building dnsmasq 2.80: make COPTS=-DHAVE_DNSSEC crypto.c: In function 'dnsmasq_ecdsa_verify': crypto.c:297:36: error: 'nettle_secp_256r1' undeclared (first use in this function); did you mean 'nettle_get_secp_256r1'? nettle_ecc_point_init(key_256, &nettle_secp_256r1); ^ nettle_get_secp_256r1 crypto.c:297:36: note: each undeclared identifier is reported only once for each function it appears in crypto.c:310:36: error: 'nettle_secp_384r1' undeclared (first use in this function); did you mean 'nettle_get_secp_384r1'? nettle_ecc_point_init(key_384, &nettle_secp_384r1); ^ nettle_get_secp_384r1 make[1]: *** [/tmp/dnsmasq-2.80/Makefile:161: crypto.o] Error 1 thanks Juergen ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Problem with server=/local/127.0.0.1
Hi Denis, .local is reserved domain for mdns, therefore by default it's resolved mdns multicast on the client, not via dns. check nsswitch.conf, if you're on linux, maybe for windows host there's something similar. it's not recommended to use .local domains for internal services. чт, 13 дек. 2018 г. в 10:27, Denis : > > Hello, everyone! > > In my dnsmasq.conf "server=/local/127.0.0.1" doesn't seem to work. At least, > it doesn't work how I thought it was supposed to work. I was under the > impression that server=/$domainname/$address should cause the $domainname to > be looked up only in $address. However, like I said, I have the line > "server=/local/127.0.0.1", dnsmasq --test returns "syntax check OK", but my > *.local names are not resolved. > > Here's the full content of my dnsmasq.conf: > > domain-needed > bogus-priv > strict-order > server=/local/127.0.0.1 > local=/local/ > listen-address=127.0.0.1 > no-dhcp-interface=127.0.0.1 > expand-hosts > domain=local > > Am I missing something, ir is this option not supposed to work like I think? > > -- > Respectfully, > Denis Shadrin > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Best regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] dhcpv6: fix unaligned access crash on aarch64
Yep, it works as expected, thanks. Unfortunately, struct copying is still there and need to keep in mind that pointers must be aligned or absence of protection will crash it again in any possible future. Btw, alignment rule was applied to DECLINE, but seems missed in DHCPRELEASE part, put_opt6(opt6_ptr(ia_option, 0)...) is still there instead of put_opt6(&addr...). Best Regards, Vladislav Grishenko ср, 22 авг. 2018 г. в 2:11, Simon Kelley : > > Thanks for chasing that down. Your patch will fix it, but I think it's > probably better to solve the problem at source, where we copy addresses > out of packets, rather than pass unaligned pointers to struct in6_addr > around and patch things up at the other end. That stops this coming and > biting us again. > > That makes a much bigger patch, unfortunately. > > I just pushed my attempt at doing that. Does it work OK for you? > > > Cheers, > Simon. > > On 21/08/18 14:04, Vladislav Grishenko wrote: > > Hi, Simon > > > > > > > > Faced with dnsmasq crash on aarch64 (32bit userspace, > > arm-buildroot-linux-gnueabi-gcc 5.3.0) with dhcpv6 stateful configured. > > > > Unaligned packet’s req_addr is used in lease6_allocate() for struct copy > > since 2.67test15 (commit 89500e31f199e9ae1eadc86213b911ff44d30d6f). > > > > As for other places, seems well-aligned stack-local vars are used. > > > > Please refer proposed patch attached and gdb trace: > > > > > > > > Program received signal SIGBUS, Bus error. > > > > 0x0003f990 in lease6_allocate (addrp=0xa55e6, lease_type=32) at lease.c:822 > > > > 822 lease->addr6 = *addrp; > > > > (gdb) bt > > > > #0 0x0003f990 in lease6_allocate (addrp=0xa55e6, lease_type=32) at > > lease.c:822 > > > > #1 0x00055fac in update_leases (state=0xfffef8ac, context=0xa7ee8, > > addr=0xa55e6, lease_time=900, now=14609) at rfc3315.c:1825 > > > > #2 0x00055ab4 in add_address (state=0xfffef8ac, context=0xa7ee8, > > lease_time=900, ia_option=0xa55e2, min_time=0xfffef6d0, addr=0xa55e6, > > now=14609) at rfc3315.c:1684 > > > > #3 0x00053764 in dhcp6_no_relay (state=0xfffef8ac, msg_type=3, > > inbuff=0xa55a8, sz=128, is_unicast=0, now=14609) at rfc3315.c:938 > > > > #4 0x00051744 in dhcp6_maybe_relay (state=0xfffef8ac, inbuff=0xa55a8, > > sz=128, client_addr=0xfffef9a0, is_unicast=0, now=14609) at rfc3315.c:172 > > > > #5 0x000513b8 in dhcp6_reply (context=0xa7ee8, interface=23, > > iface_name=0xfffef978, fallback=0xfffef9f8, ll_addr=0xfffefa18, > > ula_addr=0xfffefa28, sz=128, client_addr=0xfffef9a0, > > > > now=14609) at rfc3315.c:103 > > > > #6 0x0004f4b4 in dhcp6_packet (now=14609) at dhcp6.c:233 > > > > #7 0x00038c78 in main (argc=3, argv=0xfffefd34) at dnsmasq.c:1099 > > > > > > > > Best Regards, Vladislav Grishenko > > > > > > > -- Best regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] dhcpv6: fix unaligned access crash on aarch64
Hi, Simon Faced with dnsmasq crash on aarch64 (32bit userspace, arm-buildroot-linux-gnueabi-gcc 5.3.0) with dhcpv6 stateful configured. Unaligned packet’s req_addr is used in lease6_allocate() for struct copy since 2.67test15 (commit 89500e31f199e9ae1eadc86213b911ff44d30d6f). As for other places, seems well-aligned stack-local vars are used. Please refer proposed patch attached and gdb trace: Program received signal SIGBUS, Bus error. 0x0003f990 in lease6_allocate (addrp=0xa55e6, lease_type=32) at lease.c:822 822 lease->addr6 = *addrp; (gdb) bt #0 0x0003f990 in lease6_allocate (addrp=0xa55e6, lease_type=32) at lease.c:822 #1 0x00055fac in update_leases (state=0xfffef8ac, context=0xa7ee8, addr=0xa55e6, lease_time=900, now=14609) at rfc3315.c:1825 #2 0x00055ab4 in add_address (state=0xfffef8ac, context=0xa7ee8, lease_time=900, ia_option=0xa55e2, min_time=0xfffef6d0, addr=0xa55e6, now=14609) at rfc3315.c:1684 #3 0x00053764 in dhcp6_no_relay (state=0xfffef8ac, msg_type=3, inbuff=0xa55a8, sz=128, is_unicast=0, now=14609) at rfc3315.c:938 #4 0x00051744 in dhcp6_maybe_relay (state=0xfffef8ac, inbuff=0xa55a8, sz=128, client_addr=0xfffef9a0, is_unicast=0, now=14609) at rfc3315.c:172 #5 0x000513b8 in dhcp6_reply (context=0xa7ee8, interface=23, iface_name=0xfffef978, fallback=0xfffef9f8, ll_addr=0xfffefa18, ula_addr=0xfffefa28, sz=128, client_addr=0xfffef9a0, now=14609) at rfc3315.c:103 #6 0x0004f4b4 in dhcp6_packet (now=14609) at dhcp6.c:233 #7 0x00038c78 in main (argc=3, argv=0xfffefd34) at dnsmasq.c:1099 Best Regards, Vladislav Grishenko 0001-dhcpv6-fix-unaligned-access-crash-on-aarch64.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file
Hi Kristian, FYI, changing resolv.conf format could lead libc resolver to fail, so it's quite dangerous change. As I understand, you want dynamic DNS servers update with additional info (interface/src ip binding). With no DBUS, can't it be done with --servers-file option (available since 2.69)? This files allow full format of --server & --rev-server and are reread on SIGHUP, polling is not supported at the moment. Best Regards, Vladislav Grishenko -Original Message- From: Dnsmasq-discuss [mailto:dnsmasq-discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Kristian Evensen Sent: Monday, April 10, 2017 1:35 PM To: Simon Kelley Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file Hi Simon, On Fri, Apr 7, 2017 at 11:27 PM, Simon Kelley wrote: > The overriding objection to this is that it adds to the syntax and > semantics of the resolv-file format, but dnsmasq doesn't "own" that > format: it's actually a libc configuration file, and dnsmasq takes > advantage of the fact that the format is "well known" to extract > useful information from it. If you start adding extra fields to > /etc/resolv.conf then the c-library will get upset. I have been thinking some more about this. The reason for locking the support for server-strings in the resolv behind a command line option, was to avoid what you are describing here - compatibility issues with the existing resolv-file format. I assume that if anyone enables the option, they know what they are doing and what implications it might have. I should maybe have explained this better in either the commit or the addition to the man-page. > I understand the desire to be able to specify resolvers dynamically > with the full set of source-address and routing options; that's > actually already available, and has been for a long time, using the > DBus interface to dnsmasq, which includes the "SetDomainServers" > method, which takes strings identical to argument to --server. I've > not looked at the code, but your previous patch to allow binding both > IP and interface should have automatically added that feature to > SetDomainServers. (if it didn't then I'd certainly take a patch to > correct that.) I did a quick test and it seems that specifying servers (with the additional interface/ip-information) using the DBus-interface works fine. However, this does not help on systems not using DBus (like OpenWRT/LEDE). Do you have any suggestions for an acceptable way to implement this feature, without requiring the use DBus? Thanks in advance for the help, Kristian ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Sequential IP doesn't look for unused IPs
Hi Alec, A bit disagree on that, at up-to-time Asus routers use hashed mac allocations, not sequential. Older ones – did sequential allocation with reuse of expired IP from the very start (original udhcpd behavior), and in my practice, it rose issues when the same ip was allocated to different interfaces of one particular host, first time – as a first lease, second – after a hibernate/sleep. Same code was merged into udhcpd@busybox and was fixed into sdbm hash several years ago. In my opinion, sequential reuse of ip pool does more harm than helps to keep the “things” in order. Best Regards, Vladislav Grishenko From: Dnsmasq-discuss [mailto:dnsmasq-discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Alec Robertson Sent: Sunday, December 25, 2016 4:14 AM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Sequential IP doesn't look for unused IPs I understand what you’re saying but I was suggesting this should be a feature enhancement. All the other routers I have used work the way I have described, be it NETGEAR, Asus, Huawei, etc. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
Hi, all Just FYI, common way to really control resolv.conf updates w/o races and even with sym&hardlinks is to kick dnsmasq with signal after resolv.conf update is fully finished in any way.This also triggers hosts/ether/etc reread and corresponding reconf. Best Regards, Vladislav Grishenko _ From: Albert ARIBAUD Sent: вторник, октября 25, 2016 2:51 ДП Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour To: John Knight Cc: Hi John, Yes, you can submit patches to the list. However, 2.55 is quite old with respect to the current release of dnsmasq, which is 2.76 IIRC. Amicalement, Albert. Le Mon, 24 Oct 2016 17:57:03 + John Knight a écrit: > Hi Albert, > > I have finished making my changes to dnsmasq 2.55 and I have a patch > file. However, I am not sure how to submit it... do I send it to the > discussion list? > > Thanks, > > John Knight > > > -Original Message- > From: John Knight > Sent: Wednesday, October 19, 2016 12:57 PM > To: 'Albert ARIBAUD' > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: RE: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an > hour > > Hi Albert, > > My comments inline. > > John > > > Hi All, > > > The main while(1) loop uses select() to determine if it has work to > > do. In most cases, it appears to use timeout of 0, which I believe > > means just wait indefinitely for work on the file descriptors. > > Other times, it appears that the timeout is set to a quarter second > > when doing a tftp transfer or polling the dbus. > > > > Now what concerns me is that when a "retry later" condition occurs, > > we may get stuck on the select() for a long period of time. Alas, > > I do not know how frequent one might expect to see work arrive on > > the file descriptors that select is watching, so I don't really > > know if this is a long time or not. It seems though that in this > > failure scenario, the poll_resolv() function does NOT get called > > very often at all. > > Albert: Actually, if dnsmasq does not receive any request from > clients, it does not need to poll servers, so I would ask: does the > select() include descriptors for client requests (either UDP > datagrams received, or TCP connections opened)? If so, I think it > will exit just when necessary and no tiemout is needed; otherwise, > you are right that a timeout is required. > > Albert: Also, it may be improbable that select() does not return for > a whole hour; but then, is every return from select() followed by a > resolv file poll, or can select() return and then be entered again > without polling the resolv files? I am thinking, for instance, about > cached answers which do not need servers if their TTL is long enough. > > John: I have made a simple change that provides a one second timeout > for select. I have found that dnsmasq is much more responsive now to > changes made to /etc/resolv.conf. With code that calls poll_resolv, > it rate limits the calls to once every two seconds, which I believe > is fine and responsive enough. > > John: Given I am testing this in a lab situation and just me on the > console and one idle PC connected to the router, there is little use > of DNS. In my experience since the initial failure, I believe I did > see poll_resolv polled in one case at an interval of about 20 > minutes. I don’t think this poll interval should be driven by how > active the users are and how much they use dns; just my personal > feeling about that. > > John: It should be noted that if I had been doing a tftp transfer, > the code would set the select timeout for 250ms. I am not sure why > the tftp transfer being active would warrant the much quicker > timeout? Anyhow, what I did was an else statement... if tftp > transfer, set timeout to 250ms else set timeout to 1 second. > > John: I don't know dnsmasq well enough to answer your other questions > about select and what all of the file descriptors are associated > with. Perhaps someone more knowledgeable can chime in. My change > was made in response to the situation where a "retry later" situation > was pending, and not getting poll_resolv was not getting polled again > in a reasonable time period to do the retry. > > John: I believe on our router, dhcp entries have an hour TTL and we > do use dnsmasq for dhcp. On an idle PC, would it have any reason to > initiate a dnsmasq query? Occasionally if the browser is up and > running, I do see the browser query the address of its update server, > but I haven't generally speaking had my browser running on the PC > while doing my d
Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
Hi Albert, > The clock and the RTC are two different things. Of course they are. In my opinion, RTC in dnsmasq terms shouldn't be literally treated as it exactly is, but as main (original) reason leads to local time available to application is not equal to real time. If platform has no RTC chip, NTP is the almost only time source, so time shifts are expeted. If platform has RTC chip, but system clock source is inaccurate and NTP "fixes" it from time to time - time shifts are expeted. If platform has RTC chip, but is has wrong value (battery failure/etc) - time shifts are expected. All expected time shifts cases require HAVE_BROKEN_RTC to be define for normal flow. There's nothing to fix here, because here nothing is broken. > But timeouts can occur, TTLs can get past, etc. To treat those properly, > dnsmasq needs to know how much time has flown while it was sleeping (if > it ever does, of course). It does (actually not due sleeping, more likely to timer granulation), can be easily checked in code. Despite the fact that sleeping DHCP/DNS servers looks quite ridiculous, if dnsmasq code without HAVE_BROKEN_RTC has issue with time goes backward too much, it needs to be fixed. Not with changing the clock source, because it'll just mask the problem, but with proper dealing with such kind of time values. And, seems John have already found last_change variable wasn't static, didn’t check it by myself yet. Best Regards, Vladislav Grishenko > -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Friday, October 14, 2016 7:04 PM > To: Vladislav Grishenko > Cc: 'John Knight' ; dnsmasq- > disc...@lists.thekelleys.org.uk; 'Simon Kelley' > Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour > > Hi Vladislav, > > Le Fri, 14 Oct 2016 11:52:33 +0500 > "Vladislav Grishenko" a écrit: > > > Hi, Albert, > > > > > 1. HAVE_BROKEN_RTC should be used for, well, broken RTCs. Here, we > > > are not dealing with broken RTC. > > > > Root issue from original mail: > > > One of which acknowledges potential problem if the clock goes > > > backwards... > > As for me it's indeed broken RTC behavior, not? > > The clock and the RTC are two different things. > > The RTC is what keeps time in between power-offs. It has backup power > (frequently on PCs it is a CR20xx battery) and a slow autonomous clock > source (typically a 32 kHz crystal). IT is not set or read frequently > while the system is on, because it is usually slow to access. > > So while it is on, the system keeps track of the time not through the > RTC but through some internal clock reference which is easier and > faster to read and set. It is this clock reference which gets read > every time a process needs to known what time is "now", and it is what > gets affected by NTP etc. > > > > 2. The man mage for times() states that "a portable application > > > would be wise to avoid using [the] value [returned by times()]. To > > > measure changes in elapsed time, use clock_gettime(2) instead". > > > > Because start value of posix's times() return value may vary across > > kernel versions & UNIX impl., combined with possibility of value > > overflow the clock_t range. Since we don’t care neither about initial > > boot value nor about sleep/suspended time (files can't be modified > > when suspended, right?) > > But timeouts can occur, TTLs can get past, etc. To treat those properly, > dnsmasq needs to know how much time has flown while it was sleeping (if > it ever does, of course). > > > - the only possible issue is overflow. Since > > times() not counting CPU ticks in sleep/supspended mode, suggestion > > clock_gettime here is about using CLOCK_MONOTONIC which is almost the > > same, but with no-overflow API. > > Hm... I believe that's what my proposal amounts to on systems where > CLOCK_BOOTTIME is not available. > > > > - otherwise, if CLOCK_MONOTONIC is defined (it should always) and if > > > clock_gettime(CLOCK_MONOTONIC,...) succeeds at run time, use > > > that; > > > > Even with defined CLOCK_MONOTONIC, the real presence of this clock > > source can be retrieved from kernel in runtime only. > > Indeed, hence my double test suggestion: one must test the existence > of CLOCK_MONOTONIC and only call clock_gettime(CLOCK_MONOTONIC...) > if > it exists, and mone must test the return value of clock_gettime() in > case dnsmasq runs on an older kernel/glic than it was compiled and > built against. > > > Yes, there're > > old running kernels with no CLOCK_MONOTONIC, clock_gettime() returns > > EINVAL. Same check is true for CLOCK_BOOTTIME. > > Exact, hence my "returns success" conditional. > > > Best Regards, Vladislav Grishenko > > Amicalement, > -- > Albert. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
Hi, Albert, > 1. HAVE_BROKEN_RTC should be used for, well, broken RTCs. Here, we are > not dealing with broken RTC. Root issue from original mail: > One of which acknowledges potential problem if the clock goes backwards... As for me it's indeed broken RTC behavior, not? > 2. The man mage for times() states that "a portable application would be >wise to avoid using [the] value [returned by times()]. To measure >changes in elapsed time, use clock_gettime(2) instead". Because start value of posix's times() return value may vary across kernel versions & UNIX impl., combined with possibility of value overflow the clock_t range. Since we don’t care neither about initial boot value nor about sleep/suspended time (files can't be modified when suspended, right?) - the only possible issue is overflow. Since times() not counting CPU ticks in sleep/supspended mode, suggestion clock_gettime here is about using CLOCK_MONOTONIC which is almost the same, but with no-overflow API. > - otherwise, if CLOCK_MONOTONIC is defined (it should always) and if > clock_gettime(CLOCK_MONOTONIC,...) succeeds at run time, use that; Even with defined CLOCK_MONOTONIC, the real presence of this clock source can be retrieved from kernel in runtime only. Yes, there're old running kernels with no CLOCK_MONOTONIC, clock_gettime() returns EINVAL. Same check is true for CLOCK_BOOTTIME. Best Regards, Vladislav Grishenko > -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Friday, October 14, 2016 2:40 AM > To: Vladislav Grishenko > Cc: John Knight ; dnsmasq- > disc...@lists.thekelleys.org.uk; Simon Kelley > Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour > > Hi, > > I think it is preferable not to use HAVE_BROKEN_RTC for at least two > reasons, in increasing order of importance: > > 1. HAVE_BROKEN_RTC should be used for, well, broken RTCs. Here, we are > not dealing with broken RTC. > > 2. The man mage for times() states that "a portable application would be >wise to avoid using [the] value [returned by times()]. To measure >changes in elapsed time, use clock_gettime(2) instead". > > But you are right that CLOCK_BOOTTIME is Linux specific (I did mention that, > in fact). > > So my proposal would become: > > - if CLOCK_BOOTTIME is defined as compile time, and if > clock_gettime(CLOCK_BOOTTIME,...) succeeds at run time, use that; > > - otherwise, if CLOCK_MONOTONIC is defined (it should always) and if > clock_gettime(CLOCK_MONOTONIC,...) succeeds at run time, use that; > > - otherwise, if CLOCK_REALTIME is defined (it should always) and if > clock_gettime(CLOCK_REALTIME,...) succeeds at run time, use that; > > - otherwise, as a last resort, use times(). > > Amicalement, > Albert. > > Le Thu, 13 Oct 2016 20:15:15 + (UTC) Vladislav Grishenko > a écrit: > > > Hi, > > Why not just use existing HAVE_BROKEN_RTC?CLOCK_BOOTIME is > > linux-specific, non-portable, absent in older (but still running) > > kernels and logically is the same as CLOCK_MONOTONIC except counting > > suspended/sleep time. In turn using CLOCK_MONOTONIC is already there > > in times() form when HAVE_BROKEN_RTC is enabled. > > > > Best Regards, Vladislav Grishenko > > > > _ > > From: John Knight > > Sent: четверг, октября 13, 2016 11:00 ПП > > Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an > > hour To: Albert ARIBAUD > > Cc: > > > > > > Hi Albert, > > > > That sounds like a very good idea to use CLOCK_BOOTTIME. Good > > suggestion. > > > > When I did a search for difftime in the source code... there are quite > > a few calls... each one is a potential issue with respect to time > > going backwards. I only see one instance that actually considers the > > case if time goes backwards and that is in dnsmasq.c where it does > > difftime(now, daemon->last_resolv) and compares the > > result to both > 1.0 and < -1.0. So in general, I am somewhat > > concerned about possible affects of changing time on dnsmasq. We have > > seen some issues in the past which we suspected were probably caused > > by changing the time, so your suggested change could potentially fix > > some other issues. > > > > Thanks! > > > > John > > > > > > > > > > -Original Message- > > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > > Sent: Thursday, October 13, 2016 2:16 AM > > To: John Knight > > Cc: dnsmasq-discuss@lists.thekelleys.or
Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
Hi, Why not just use existing HAVE_BROKEN_RTC?CLOCK_BOOTIME is linux-specific, non-portable, absent in older (but still running) kernels and logically is the same as CLOCK_MONOTONIC except counting suspended/sleep time. In turn using CLOCK_MONOTONIC is already there in times() form when HAVE_BROKEN_RTC is enabled. Best Regards, Vladislav Grishenko _ From: John Knight Sent: четверг, октября 13, 2016 11:00 ПП Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour To: Albert ARIBAUD Cc: Hi Albert, That sounds like a very good idea to use CLOCK_BOOTTIME. Good suggestion. When I did a search for difftime in the source code... there are quite a few calls... each one is a potential issue with respect to time going backwards. I only see one instance that actually considers the case if time goes backwards and that is in dnsmasq.c where it does difftime(now, daemon->last_resolv) and compares the result to both > 1.0 and < -1.0. So in general, I am somewhat concerned about possible affects of changing time on dnsmasq. We have seen some issues in the past which we suspected were probably caused by changing the time, so your suggested change could potentially fix some other issues. Thanks! John -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, October 13, 2016 2:16 AM To: John Knight Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour Hi, Just a generic comment: from what I can see, all absolute times in dnsmasq are returned bu dnsmasq_time() which calls either times() or time(). This, IIUC, corresponds to CLOCK_REALTIME in clock_gettime(), which is indeed affected when (re)setting the time. Maybe a fix to time jump issues would be (in Linux at least) to replace time() with clock_gettime(CLOCK_BOOTTIME,...) which seems to have been designed to get around discontinuities caused by settimeofday(). Note: maybe dates used for logging purposes should still use time() or clock_gettime(CLOCK_REALTIME) in order to remain comparable to other logs in the same system -- or maybe not. Sources: man times, man time, man clock_gettime. HTH, Amicalement, Albert. Le Wed, 12 Oct 2016 23:50:11 + John Knight a écrit: > Hi, > > I think I may know what the issue is... it appears that the time may > be changed by ntp in my failure scenario as suggested by the URLs > referencing ntp in the dnsmasq.log file. There are numerous > references to difftime in dnsmasq code. One of which acknowledges > potential problem if the clock goes backwards... and is handled by > comparing last_resolv >1.0 and < -1.0 to accommodate such a > possibility. However, in function poll_resolv(), the difftime() call > checks for > 0.0, assuming the modification time of the file is > greater than the last_change time. If the time had changed on the > router, then its possible that the modification time of the > /etc/resolv.conf could be less than that of the last_change. I think > this needs to be a check for != 0. If the time is changed negatively, > then the existing code will not work properly me thinks. > Its imperative that latest gets set in order for the reload_servers() > code to run... and if the time is not right, then the > reload_servers() won't get called. This specific code (poll_resolv) > hasn't changed, and if I am right, it is also broken in 2.76. > > What do you think? I am going to make the change locally and re-test > and see if I can make it fail again. Unfortunately, it doesn't always > fail, but I have reproduced it twice now, hopefully it will happen > again if my fix is not right. > > Best Regards, > > John Knight > > __ > Confidential This e-mail and any files transmitted with it are the > property of Belkin International, Inc. and/or its affiliates, are > confidential, and are intended solely for the use of the individual or > entity to whom this e-mail is addressed. If you are not one of the > named recipients or otherwise have reason to believe that you have > received this e-mail in error, please notify the sender and delete > this message immediately from your computer. Any other use, retention, > dissemination, forwarding, printing or copying of this e-mail is > strictly prohibited. Pour la version fran?aise: > http://www.belkin.com/email-notice/French.html F?r die deutsche > ?bersetzung: http://www.belkin.com/email-notice/German.html > __ Amicalement, -- Albert. __ Confidential This e-mail and any files transmitted with it are the property of Belkin Inte
Re: [Dnsmasq-discuss] fe80/10 link local dns forwarding
Hi Kevin, There's RFC 6303 for that, current status is best current practice. As for dnsmasq implementation of that recommendations, it could depend on auth support, since it enables zone support. Best Regards, Vladislav Grishenko > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Kevin Darbyshire-Bryant > Sent: Monday, September 07, 2015 6:28 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: [Dnsmasq-discuss] fe80/10 link local dns forwarding > > Hi All, > > After enabling dnsmasq's dns logging the other day I was a little surprised to > see queries for fe80:: being forwarded to my ISP's resolvers. I'd say that > they're extremely unlikely to know anything about my link local stuff so as a > solution I've added the following to my config: > > server=/8.e.f.ip6.arpa/ > > What don't I understand here? Awaiting education :-) > > Kevin ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq not responding to DNS queries for local addresses when WAN down
When wan is down, dns queries to router gets intercepted with help of iptables. So, dnsmasq receives (and replies) nothing. Best Regards, Vladislav Grishenko > -Original Message- > From: Justin Smith [mailto:jus...@smithpolglase.com] > Sent: Monday, July 20, 2015 4:02 PM > To: Vladislav Grishenko > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] dnsmasq not responding to DNS queries for > local addresses when WAN down > > Thanks Vladislav. That solved my problem! > > But I'm a little confused as to why... Isn't dnsmasq (running on the > router) responsible for processing all DNS queries on the local network? Or is > this a "modified" version of dnsmasq? > > Thanks again. > Justin. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq not responding to DNS queries for local addresses when WAN down
Hi Justin, There's nothing wrong with dnsmasq. Instead, when your wan in down, all dns queries from lan gets faked by answering fake 10.0.0.1 address which is used for showing the router's wan state and reason. You could turn it off with "Enable WAN down browser redirect notice" under Administration / System web ui page. Best Regards, Vladislav Grishenko > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Justin Smith > Sent: Sunday, July 19, 2015 2:20 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: [Dnsmasq-discuss] dnsmasq not responding to DNS queries for local > addresses when WAN down > > Hi, > > My home network uses an Asus RT-N66U running Merlin's firmware (ver > 378.55). I have dnsmasq running on the router. My problem is that when the > WAN interface goes down (as it does occasionally) dnsmasq no longer > returns the correct IP address to DNS queries to local hosts. > > For example (fake domain name): > > WAN UP > === > justin@juka:~$ nslookup myhost1 > Server: 127.0.1.1 > Address: 127.0.1.1#53 > > Name: myhost1 > Address: 192.168.30.3 > > WAN DOWN > == > justin@juka:~$ nslookup myhost1 > Server: 127.0.1.1 > Address: 127.0.1.1#53 > > Name: myhost1.mydomain.com > Address: 10.0.0.1 > > > My dnsmasq.conf looks something like this (personal data > suppressed/changed): > > bind-dynamic > interface=br0 > no-negcache > cache-size=1500 > domain-needed > bogus-priv > no-resolv > no-poll > server=aaa.bbb.ccc.ddd # ISP DNS server IP address > local=/mydomain.com/ > domain=mydomain.com > dhcp-range=192.168.30.200,192.168.30.250,24h > dhcp-host=f4:6d:04:da:3e:c4,myhost1,192.168.30.3 > dhcp-host=38:2c:4a:af:e4:53,myhost2,192.168.30.4 > ... > dhcp-authoritative > > > My resolv.conf on the router looks like: > # cat /tmp/etc/resolv.conf > nameserver 127.0.0.1 > > > Does anyone offer advice on how to correctly set up dnsmasq? > > > Thanks, > Justin. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] IPv6 RA issues when bound to IPv4
Hi Michal Use netstat -g to display multicast group memberships Best Regards, Vladislav Grishenko > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Michal Zatloukal > Sent: Friday, July 17, 2015 5:01 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] IPv6 RA issues when bound to IPv4 > > I'm not sure what you mean - what exactly should I have in the > configuration? > Is there a way to check, if the correct multicast address is being bound to? > netstat -tupan doesn't show any multicast addresses. > > MZ > > On 16 July 2015 at 19:49, Simon Kelley wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Dnsmasq needs to advertise the global address, I think. Receiving RAs > > shouldn't be a problem, dnsmasq binds the correct multicast address. > > > > Cheers, > > > > Simon. > > > > > > On 16/07/15 16:27, Michal Zatloukal wrote: > >> Hi all, > >> > >> I'm using dnsmasq (2.68-1ubuntu0.1) on a machine where the need to > >> run tftpd-hpa along with dnsmasq's own tftp server has arisen (both > >> on just IPv4). I decided to use the "secondary IP address" feature in > >> Linux networking system to bind tftpd-hpa to the secondary IP > >> address, and set up dnsmasq to bind the following: - primary IPv4 > >> address - localhost IPv4 - For IPv6, I put in localhost, global and > >> link-local addresses. IIUC, RA can't work in this config, since the > >> destination on RS is multicast ff02::2 and therefore aren't delivered > >> to any of the sockets opened by dnsmasq. > >> > >> Now, which IPv6 address do I enter so that IPv6 router announcements > >> work correctly? (Is it even possible?) - adding > >> ff02::2 doesn't work, dnsmasq reports error in syslog - cannot bind > >> to this address. - replacing all IPv6 addresses with "::" allows > >> dnsmasq to start and bind to wildcard IPv6, but it seems incoming RS > >> packets are ignored - nothing appears in syslog when clients send > >> solicitation. Is the filtering code in DSNmasq perhaps not expecting > >> a wildcard address in the listen-address parameter and filters > >> packets against it? > >> > >> Regards, > >> > >> MZ > >> > >> ___ Dnsmasq- > discuss > >> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk > >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1 > > > > > iQIcBAEBCAAGBQJVp+6bAAoJEBXN2mrhkTWitrYP/i/4dcuoEBWJohhXhjMS6lI > 7 > > > G9/jw80md0bSwzyddi8k+8+SM+oPqMBmnaqh9TWJ5pQT0j8rQsNd06ByJ85cf > k4k > > > 2k5QKJoc1o6dfA/E6bJU9DtxMUqupBdQZdOo6c+b57nRRxwubXXmJe2qpDUF > V1wQ > > > Z3INhtdVAHwNBAM1+amDGMrps1dmOv+cBKr81jpoX/ySvUL1j5nG2cMz+wi > 4ux2Y > > > 0xf4RKsH2WqUOwVpVfmYMe/Mc5V2thdG6xpwdZ+qzMbrux/RWeNJ+4r/G7 > +mSS7l > > > TeAKtFkT5mrhxMIbrmC49a12WQtBZBpaAHUuSwkesGAytPelpuU5e3TwgvP0 > WCc8 > > QXoDGRm1YntM1dlu24TOPPz5jRk9L9qrJnzpXf1lyiojxpzsvRJa+Ei8uu2IWg4q > > > 75eVCs1wX4hLMmf9J7L759KpBrhqPoV2vu5J15vwsfXmP4bCIcDAuQOSLDiJjG > XV > > > My3oeNw9Rws6qKCFYZX8YQ7SRtNDA7ssEM/aneJKTUMB7k6O3i41z2Y7DRP2 > m9uf > > > u5Yo3HUi9B+1G9fICNnicxZdAh5hLKilo4Fvswvn5dEMgo3LMkHiGUgHLebhsJW > e > > > 68UwmvFmmZyStg1wd4qBJ4eUKIRpsvWgvaUA+Huv+nzfco2GOM8tZVPb2W > Aq+XFj > > Ct+n7zarBZQeIS0Ku/kJ > > =Gn77 > > -END PGP SIGNATURE- > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
> On the surface it looks like it's either pointless behavior on the server's > part or incorrect logic in the DHCP client. Am I missing something? Yes, without overriding serverid to one from incoming request packet, the server’s nak could be pointless. But with overriding, it’ll introduce the same naking issue even with clients which were checking server id and ignoring naks from non-selected servers. Dnsmasq starts to nak request from selecting clients in 2.46, see the story here http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q4/002476.html Point of busybox’s udhcpc changes is described here https://bugs.busybox.net/show_bug.cgi?id=4267 As for ISC DHCP, it’s known client ignores NAK from non-selected servers in SELECTING state. As for server, it allow run-time control over weither or not a server, participating in failover, verifies server id option. This commit contains the old and new descriptions https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commitdiff;h=7116a34fc9b1fb307bcdca22e6963254289ecb80 Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com] Sent: Monday, June 01, 2015 5:15 PM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue Let me rephrase it slightly. What is the point of dnsmasq NAKing client responses to other servers if the clients are being programmed to ignore the NAKs? On the surface it looks like it's either pointless behavior on the server's part or incorrect logic in the DHCP client. Am I missing something? On Mon, Jun 1, 2015 at 2:58 AM, Vladislav Grishenko mailto:themi...@mail.ru> > wrote: Hi Kevin, ы > why do DHCP servers like dnsmasq generate them in the first place? Because it’s per dnsmasq configuration and the effects are well-described in the man. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html -K, --dhcp-authoritative Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum). you definitely have multiple dhcp servers, so this option is misused under your circumstances, not? Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com <mailto:blak...@gmail.com> ] Sent: Monday, June 01, 2015 2:02 PM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk <mailto:dnsmasq-discuss@lists.thekelleys.org.uk> Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue I understand, but that eliminates the whole 'correcting rouge dhcp offers' part of the authoritative mode. If we are teaching clients to ignore NAKs from other DHCP servers, why do DHCP servers like dnsmasq generate them in the first place? Wouldn't it be logically consistent to make a change to dnsmasq to prevent it from generating a NAK if the client is communicating with a different server? Is the client behavior regarding NAKs outlined in one of the DHCP RFCs? It does seem like there is a lot of confusion around what authoritative servers should be doing. On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko mailto:themi...@mail.ru> > wrote: Hi Kevin, Ignoring all naks – would be, but the fix is different. That fix ignores all naks except from the selected/requested server only, it’s ok. Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com <mailto:blak...@gmail.com> ] Sent: Wednesday, May 27, 2015 9:32 AM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk <mailto:dnsmasq-discuss@lists.thekelleys.org.uk> Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue That fix is interesting. Doesn't ignoring a NAK sort of defeat the point of the 'authoritative' NAKing in the first place? On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko mailto:themi...@mail.ru> > wrote: > On 02/02/2015 05:47 PM, Brian Haley wrote: > >> > >>> The one thing I'm curious about is if dnsmasq is restarted while a > >>> VM holds a lease, how will it respond? As someone else has > >>> pointed-out to me - isc-dhcp will respond with a DHCPNAK in that > >>> case, and wondered why there would be a difference with dnsmasq. > >>> Different interpretation of an RFC? > >&
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
Hi Kevin, > why do DHCP servers like dnsmasq generate them in the first place? Because it’s per dnsmasq configuration and the effects are well-described in the man. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html -K, --dhcp-authoritative Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum). you definitely have multiple dhcp servers, so this option is misused under your circumstances, not? Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com] Sent: Monday, June 01, 2015 2:02 PM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue I understand, but that eliminates the whole 'correcting rouge dhcp offers' part of the authoritative mode. If we are teaching clients to ignore NAKs from other DHCP servers, why do DHCP servers like dnsmasq generate them in the first place? Wouldn't it be logically consistent to make a change to dnsmasq to prevent it from generating a NAK if the client is communicating with a different server? Is the client behavior regarding NAKs outlined in one of the DHCP RFCs? It does seem like there is a lot of confusion around what authoritative servers should be doing. On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko mailto:themi...@mail.ru> > wrote: Hi Kevin, Ignoring all naks – would be, but the fix is different. That fix ignores all naks except from the selected/requested server only, it’s ok. Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com <mailto:blak...@gmail.com> ] Sent: Wednesday, May 27, 2015 9:32 AM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk <mailto:dnsmasq-discuss@lists.thekelleys.org.uk> Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue That fix is interesting. Doesn't ignoring a NAK sort of defeat the point of the 'authoritative' NAKing in the first place? On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko mailto:themi...@mail.ru> > wrote: > On 02/02/2015 05:47 PM, Brian Haley wrote: > >> > >>> The one thing I'm curious about is if dnsmasq is restarted while a > >>> VM holds a lease, how will it respond? As someone else has > >>> pointed-out to me - isc-dhcp will respond with a DHCPNAK in that > >>> case, and wondered why there would be a difference with dnsmasq. > >>> Different interpretation of an RFC? > >> > >> > >> If by "dnsmasq is restarted" you mean "dnsmasq is restarted and > >> therefore has its lease database deleted", then the RFC says that if > >> a server gets a renewal for an unknown lease, it should return > >> DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is > >> set, when instead it quietly re-creates the lease. > > > > Yes, your assumption is correct, as --leasefile-ro is used it knows of > > no current leases, and by default get a DHCPNAK. > > > >> dhcp-authoritative gives permission to dnsmasq to violate the RFC in > >> a way which is useful in certain circumstances. > > > > Thanks, it does seem to do what I want with my initial testing. > > Hi Simon, > > Replying to my old thread since using --dhcp-authoritative seems to have > introduced an issue where a DHCP client can get a NAK when using multiple > dnsmasq servers on the same subnet (they both have the same host > information, >1 running just to get HA). > > Short story is that both dnsmasq's return the same lease info, but when the > client ACKs (sending to broadcast), one agent ACKs and the other agent > NAKs. > The tcpdump shows this better than I'm describing: > > https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html > > Does that seem like normal operation to you? Does this second dnsmasq > assume this response is from a rogue server and NAKs since it didn't send out > the offer? > Hi Brian, Second dnsmasq assume the client request is to another server and responds with NAK in authoritative mode. The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't check server id for anything but offer p
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
Hi Kevin, Ignoring all naks – would be, but the fix is different. That fix ignores all naks except from the selected/requested server only, it’s ok. Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com] Sent: Wednesday, May 27, 2015 9:32 AM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue That fix is interesting. Doesn't ignoring a NAK sort of defeat the point of the 'authoritative' NAKing in the first place? On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko mailto:themi...@mail.ru> > wrote: > On 02/02/2015 05:47 PM, Brian Haley wrote: > >> > >>> The one thing I'm curious about is if dnsmasq is restarted while a > >>> VM holds a lease, how will it respond? As someone else has > >>> pointed-out to me - isc-dhcp will respond with a DHCPNAK in that > >>> case, and wondered why there would be a difference with dnsmasq. > >>> Different interpretation of an RFC? > >> > >> > >> If by "dnsmasq is restarted" you mean "dnsmasq is restarted and > >> therefore has its lease database deleted", then the RFC says that if > >> a server gets a renewal for an unknown lease, it should return > >> DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is > >> set, when instead it quietly re-creates the lease. > > > > Yes, your assumption is correct, as --leasefile-ro is used it knows of > > no current leases, and by default get a DHCPNAK. > > > >> dhcp-authoritative gives permission to dnsmasq to violate the RFC in > >> a way which is useful in certain circumstances. > > > > Thanks, it does seem to do what I want with my initial testing. > > Hi Simon, > > Replying to my old thread since using --dhcp-authoritative seems to have > introduced an issue where a DHCP client can get a NAK when using multiple > dnsmasq servers on the same subnet (they both have the same host > information, >1 running just to get HA). > > Short story is that both dnsmasq's return the same lease info, but when the > client ACKs (sending to broadcast), one agent ACKs and the other agent > NAKs. > The tcpdump shows this better than I'm describing: > > https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html > > Does that seem like normal operation to you? Does this second dnsmasq > assume this response is from a rogue server and NAKs since it didn't send out > the offer? > Hi Brian, Second dnsmasq assume the client request is to another server and responds with NAK in authoritative mode. The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't check server id for anything but offer packet. Bug is already fixed in bb 1.23.x, see commit http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52 <http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0> e588c0 Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk <mailto:Dnsmasq-discuss@lists.thekelleys.org.uk> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Kevin Benton ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
> On 02/02/2015 05:47 PM, Brian Haley wrote: > >> > >>> The one thing I'm curious about is if dnsmasq is restarted while a > >>> VM holds a lease, how will it respond? As someone else has > >>> pointed-out to me - isc-dhcp will respond with a DHCPNAK in that > >>> case, and wondered why there would be a difference with dnsmasq. > >>> Different interpretation of an RFC? > >> > >> > >> If by "dnsmasq is restarted" you mean "dnsmasq is restarted and > >> therefore has its lease database deleted", then the RFC says that if > >> a server gets a renewal for an unknown lease, it should return > >> DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is > >> set, when instead it quietly re-creates the lease. > > > > Yes, your assumption is correct, as --leasefile-ro is used it knows of > > no current leases, and by default get a DHCPNAK. > > > >> dhcp-authoritative gives permission to dnsmasq to violate the RFC in > >> a way which is useful in certain circumstances. > > > > Thanks, it does seem to do what I want with my initial testing. > > Hi Simon, > > Replying to my old thread since using --dhcp-authoritative seems to have > introduced an issue where a DHCP client can get a NAK when using multiple > dnsmasq servers on the same subnet (they both have the same host > information, >1 running just to get HA). > > Short story is that both dnsmasq's return the same lease info, but when the > client ACKs (sending to broadcast), one agent ACKs and the other agent > NAKs. > The tcpdump shows this better than I'm describing: > > https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html > > Does that seem like normal operation to you? Does this second dnsmasq > assume this response is from a rogue server and NAKs since it didn't send out > the offer? > Hi Brian, Second dnsmasq assume the client request is to another server and responds with NAK in authoritative mode. The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't check server id for anything but offer packet. Bug is already fixed in bb 1.23.x, see commit http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52 e588c0 Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Mirror the git repository to github.com
Hi Simon, There's a number of dnsmasq forks on github, so imho, it would be good to have official mirror there to base against. Best Regards, Vladislav Grishenko > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Wednesday, May 13, 2015 4:38 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Mirror the git repository to github.com > > On 11/05/15 17:51, Thiago Farina wrote: > > On Sat, May 9, 2015 at 5:38 PM, Karl-Philipp Richter > > wrote: > >> Hi, > >> Mirroring the git repository git://thekelleys.org.uk/dnsmasq.git to > >> github.com would facilitate contributions by providing the pull > >> request feature. > >> > > Is Simon fine with pull requests? > > > > I like to be sent a patch. If a mirror at github makes it easier for people to > generate a patch, then I'm happy to do it, or have someone else set it up. > > > Cheers, > > Simon. > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Don't reply to requests for DHCPv6 addresses when M flag is off
Simon, thanks As for reasons, I guess, Steven thought it departs from ordinal meaning of RFC and prevents his odhcp6c to work normally. p.s in my previous mail was a typo, RFC 2119, of course, not 2219. sorry Best Regards, Vladislav Grishenko > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Monday, April 20, 2015 1:21 AM > To: Vladislav Grishenko; 'Win King Wan' > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Don't reply to requests for DHCPv6 addresses > when M flag is off > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > My feeling is that this is a better solution, and I'm inclined to apply the patch. > Does anyone know what caused openWRT to revert the patc h? > > > Cheers, > > Simon. > > > > On 17/04/15 12:51, Vladislav Grishenko wrote: > > Hi, > > > > Per RFC 3315 17.2.1 the server MAY discard the Solicit message, but > > per 17.2.2, if the server will not assign any addresses to any IAs in > > a subsequent Request from the client, the server MUST send an > > Advertise message to client. Also, per RFC 2219 MAY is truly optional > > item, and MUST be prepared to interoperate with another inverse option > > existence implementation. So, interpreting that dnsmasq may not > > respond at all in stateless mode into RFC 3315 > > 17.2.1 seems a bit farfetched. > > > > In real world, absence of Advertise message with NoAddrsAvail Status > > Code may lead to client misbehavior and prevent it from fallback to > > DHCPv6 Stateless mode, because RFC 3315 doesn't state any non-zero MRC > > & MRD non-zero values by default for Solicit messages transmission. > > Example of such client is https://github.com/sbyx/odhcp6c Also, > > openwrt has already reverted this change, refer > > > https://dev.openwrt.org/browser/trunk/package/network/services/dnsmas > q > /patch > > > > > es/200-fix-dhcpv6-solicit-handling.patch > > > > Since the original issue was in log flooding, log error only for > > non-stateless contexts and threat it as false-positive error if it's > > expected due the configuration. Please refer patch attached. > > > > Best Regards, Vladislav Grishenko > > > >> -Original Message- From: Dnsmasq-discuss > >> [mailto:dnsmasq-discuss- boun...@lists.thekelleys.org.uk] On Behalf > >> Of Simon Kelley Sent: Thursday, January 22, 2015 2:02 AM > >> To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: > >> [Dnsmasq-discuss] Don't reply to requests for DHCPv6 > > addresses > >> when M flag is off > >> > > My first reaction to this was to apply it, but then I went and looked > > at RFC3315, and found this: > > > > If the server will not assign any addresses to any IAs in a subsequent > > Request from the client, the server MUST send an Advertise message to > > the client that includes only a Status Code option with code > > NoAddrsAvail and a status message for the user, a Server Identifier > > option with the server's DUID, and a Client Identifier option with the > > client's DUID. > > > > Which seems to indicate that the patch would violate the RFC. > > > > But then I looked some more, and found this: > > > > 17.2.1. Receipt of Solicit Messages > > > > > > The server determines the information about the client and its > > location as described in section 11 and checks its administrative > > policy about responding to the client. If the server is not permitted > > to respond to the client, the server discards the Solicit message. > > For example, if the administrative policy for the server is that it > > may only respond to a client that is willing to accept a Reconfigure > > message, if the client indicates with a Reconfigure Accept option in > > the Solicit message that it will not accept a Reconfigure message, the > > servers discard the Solicit message. > > > > > > So I think we can define "DHCPv6 address allocation not configured" > > as administrative policy and chose to discard the solict message in > > this > >> case. > > > > Patch applied, with some style changes, thanks. > > > > > > Cheers, > > > > Simon. > > > > > > > > > > > > > > > > On 19/01/15 21:30, Win King Wan wrote: > >>>> Hi, > >>>> > >>>> In https://github.com/RMerl/asuswrt-merlin/pull/854 I patched the > >>>> dnsmasq version of my ro
Re: [Dnsmasq-discuss] Don't reply to requests for DHCPv6 addresses when M flag is off
Hi, Per RFC 3315 17.2.1 the server MAY discard the Solicit message, but per 17.2.2, if the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to client. Also, per RFC 2219 MAY is truly optional item, and MUST be prepared to interoperate with another inverse option existence implementation. So, interpreting that dnsmasq may not respond at all in stateless mode into RFC 3315 17.2.1 seems a bit farfetched. In real world, absence of Advertise message with NoAddrsAvail Status Code may lead to client misbehavior and prevent it from fallback to DHCPv6 Stateless mode, because RFC 3315 doesn't state any non-zero MRC & MRD non-zero values by default for Solicit messages transmission. Example of such client is https://github.com/sbyx/odhcp6c Also, openwrt has already reverted this change, refer https://dev.openwrt.org/browser/trunk/package/network/services/dnsmasq/patch es/200-fix-dhcpv6-solicit-handling.patch Since the original issue was in log flooding, log error only for non-stateless contexts and threat it as false-positive error if it's expected due the configuration. Please refer patch attached. Best Regards, Vladislav Grishenko > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Thursday, January 22, 2015 2:02 AM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Don't reply to requests for DHCPv6 addresses > when M flag is off > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > My first reaction to this was to apply it, but then I went and looked at > RFC3315, and found this: > >If the server will not assign any addresses to any IAs in a >subsequent Request from the client, the server MUST send an Advertise >message to the client that includes only a Status Code option with >code NoAddrsAvail and a status message for the user, a Server >Identifier option with the server's DUID, and a Client Identifier >option with the client's DUID. > > Which seems to indicate that the patch would violate the RFC. > > But then I looked some more, and found this: > > 17.2.1. Receipt of Solicit Messages > > >The server determines the information about the client and its >location as described in section 11 and checks its administrative >policy about responding to the client. If the server is not >permitted to respond to the client, the server discards the Solicit >message. For example, if the administrative policy for the server is >that it may only respond to a client that is willing to accept a >Reconfigure message, if the client indicates with a Reconfigure >Accept option in the Solicit message that it will not accept a >Reconfigure message, the servers discard the Solicit message. > > > So I think we can define "DHCPv6 address allocation not configured" as > administrative policy and chose to discard the solict message in this case. > > Patch applied, with some style changes, thanks. > > > Cheers, > > Simon. > > > > > > > > On 19/01/15 21:30, Win King Wan wrote: > > Hi, > > > > In https://github.com/RMerl/asuswrt-merlin/pull/854 I patched the > > dnsmasq version of my router's firmware to not send out replies to > > DHCPv6 queries when dhcp-range mode is ra-stateless. > > > > Even though the M flag is off in the router advertisement, Windows > > 8 (and newer) clients will still request an address via DHCPv6. > > When it receives a reply that no addresses are available, it tries a > > few more time before giving up for several minutes. After several > > minutes however it retries. This causes the syslog to be filled up > > with noise stating that there are no DHCPv6 addresses available for a > > specific MAC address. (--quiet-dhcp6 does not help much as the "no > > addresses available" message is always logged.) > > > > My changes basically stops dnsmasq from sending this reply. Since the > > O flag is on, Windows 8 will try to get other information from the > > DHCPv6 server if it does not get an reply for its initial request for > > an address (which seems to still work, as it is able to get the IPv6 > > DNS server). > > > > After running Wireshark for quite some time, it appears that Windows 8 > > will not send out subsequent requests for an IPv6 address to the > > DHCPv6 server (after my patch), at least not within several minutes. > > > > I have included the patch for completeness sake. Would it be possible > > to apply it? Or perhaps there is a
Re: [Dnsmasq-discuss] dhcp option 43 question
Hi AJ, > There's apparently an option 43 setting that will resolve this, but even after a > few google searches, I'm confused as to how to configure this in dnsmasq. > I'd like to configure it so only this vendor's devices gets the option returned. > > Here's the sample config for Cisco and linux dhcpd.conf...I need help > translating this into what I should include into my dnsmasq.conf file, please? > http://wiki.ubnt.com/UniFi_FAQ#To_use_DHCP_Option_43 > > The other, alternate, is that these APs use the url http://unifi:8080/inform -- > so I considered setting the "cname" option in dnsmasq to my controller. But I > couldn't get that working for some reason. Try either dhcp-option=vendor:,1,ip.ip.ip.ip or or dhcp-option=vendor:,1,http://fqdn:8080/inform Refer --dhcp-option http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html for details Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Adding Route Information Option to prefixes in RA
In spite of fact that dnsmasq send's only on-link prefixes and in absence of RIO control, let's follow Steven proposal regarding RIO and avoidance of duplicate routes on Win* platforms. Please refer patch, it also tides up option length calculating, as used in other parts of code. http://wl500g.googlecode.com/svn/trunk/dnsmasq/071-ra-route-info.patch Best Regards, Vladislav Grishenko > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Steven Barth > Sent: Thursday, September 11, 2014 12:36 PM > To: Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Adding Route Information Option to prefixes > in RA > > > > Focusing on the current dnsmasq code, I guess the take-home message > > here is that we're probably better off to revert the code which adds > > RIOs, for now, as the only RIOs we're sending are exactly the ones > > which Steven suggests should be suppressed. Should probably re-visit > > the issue of more general support for RIO in the next release. > Possibly rare client issues aside if you announce a prefix both using an on-link > PIO and a RIO the RIO doesn't do you any good. In the best case it just adds > another redundant route for the same /64 in the worst case it confuses > clients. My personal opinion would be to only send it if you announce the PIO > as off-link (don't know if that is configurable in > dnsmasq) and otherwise just drop the RIO if it would be identical to the PIO. > > I think it would make more sense to add some kind of option to specify the > RIO-length for a prefix and only announce the RIO if said RIO length is < than > that of the prefix announced in the PIO or just add a generic option which > let's you add arbitrary RIOs or so. > > > Cheers, > > Steven ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcpv6
> From: v...@selfip.ru [mailto:v...@selfip.ru] On Behalf Of Vasiliy Tolstov > Sent: Wednesday, September 03, 2014 3:55 AM > > 2014-09-03 1:52 GMT+04:00 Vladislav Grishenko : > > Hi Vasiliy, > > Kernel never sends RA, so it's always up to userspace like dnsmasq. > > > > Please, re-read my question. I'm understand who send ra, but who send NS > and NA ? Sorry, misread. dnsmasq sends unsolicited periodic RA and sends solicited RA in reply to incoming RS from client only. dnsmasq may send several NS to client in reply to incoming DHCPv6 requests to know its hw address (mac). All other cases of NS/NA sending and receiving are up to kernel only. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcpv6
Hi Vasiliy, Kernel never sends RA, so it's always up to userspace like dnsmasq. Best Regards, Vladislav Grishenko > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Vasiliy Tolstov > Sent: Monday, September 01, 2014 6:59 PM > To: Simon Kelley > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] dhcpv6 > > 2014-09-01 12:57 GMT+04:00 Simon Kelley : > > > > It definitely listens on port 547 UDP. > > > > Simon. > > > Thanks. Last question - when dnsmasq sends RA to client who send in > response Neighbor Solicitation and Neighbor Advertisement , kernel or > dnsmasq ? > > -- > Vasiliy Tolstov, > e-mail: v.tols...@selfip.ru > jabber: v...@selfip.ru > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-pd, and autoassigned internal interfaces issues
Hi Simon, > > -if (ifa->ifa_flags& IFA_F_PERMANENT) > > +if (!(ifa->ifa_flags& IFA_F_TEMPORARY)) IFA_F_TEMPORARY flag used only if privacy extensions are enabled in kernel, in all other cases it makes no sense and will not be there. That means condition will be always evaluated as TRUE for any kind of address, including event tentative, and any address but privacy-generated will get permanent flag. Meanwhile, construct_worker() has no protection against tentative, temporary and so on flags, so, after patch, it will work for any address on linux. Was it really intended? Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq-2.68rc3 Coverity difference scan against 2.67
Hi Simon, Could you please also check out compiler warning fixes from here? Thanks http://wl500g.googlecode.com/svn/trunk/dnsmasq/ Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Tuesday, November 26, 2013 4:17 PM > To: Tomas Hozza > Cc: dnsmasq discussion list > Subject: Re: [Dnsmasq-discuss] dnsmasq-2.68rc3 Coverity difference scan > against 2.67 > > On 26/11/13 09:11, Tomas Hozza wrote: > > Hi. > > > > I scanned dnsmasq-2.68rc3 against 2.67 for added errors with Coverity. > > The log is attached. There is missing one check of whine_malloc return > > value in cache.c. I checked that the value is commonly checked in > > other parts of the source. > > > Fix pushed. Thanks. > > > Otherwise > > looks good :) > > > > Great stuff. > > Simon. > > > Regards, > > > > Tomas Hozza > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Need some example for ipv6 dhcp mode(ra-only, slaac, ra-names, ra-stateless)
Since dnsmasq 2.67 it's possible to use MAC addresses for DHCPv6 as well Of course, there's some limitations, refer dnsmasq man for details Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of mudru...@spoje.net > Sent: Monday, November 11, 2013 7:58 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Need some example for ipv6 dhcp mode(ra- > only, slaac, ra-names, ra-stateless) > > Unfortunately DHCPv6 does not use MAC adresses, but rather software > defined string called DUID. > However better documentation and examples of dnsmasq configs for > various DHCPv6 usecases would be great. > > Dne 11.11.2013 09:56, Da Zhao Y Yu napsal: > > Hi, > > > > Now I was a bit confused about IPv6 dhcp mode, such as ra-only, slaac, > > ra-names, ra-stateless, whether have some guys can give me some > > example about it? > > > > I want to use IPv6 stateless address autoconfiguration function via > > dnsmasq server, but I do not know the difference between ra-only, > > slaac, ra-names and ra-stateless? Who can give me some example about > > it, thanks! > > > > For example, one host's mac address is 00:12:34:00:AB:CD, base on the > > method of automatically generation IPv6 address(EUI-64), if the dhcp > > mode was set to RA-ONLY, then how much is the destination IPv6 > > address? if the dhcp mode was set to RA-NAMES, what is the result? > > how > > about "slaac" and "ra-stateless"? All of the IPv6 address is same? > > > > Thanks & Best Regards > > Yu Da Zhao(于大钊) > > -- > > Cloud Solutions & OpenStack Development China Systems & Technology > > Laboratory in Beijing > > Email: d...@cn.ibm.com > > Tel: (86)10-82450677 > > -- > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
> From: Simon Kelley > Sent: Friday, October 25, 2013 4:15 PM > > On 24/10/13 23:41, Vladislav Grishenko wrote: > >> From: Simon Kelley > >> Sent: Thursday, October 24, 2013 11:00 PM > >> > >> So, don't use --bind-interfaces. If you're on Linux, you can use > >> --bind- dynamic instead if you're running multiple dnsmasq instances. > >> > > > > So, on linux --bind-interfaces can be just an alias of --bind-dynamic, > > with no --bind-interfaces code and no warnings, less binary size, more > seciruty. > > There's practically no code that could be removed with --bind-interfaces, -- > bind-dynamic is pretty much bind-interfaces plus the code to determine > arrival interface which is disabled or missing with bind interfaces plus some > new code to notice new addresses arriving. > > If it could be supported everywhere, I'd just have extended bind-interfaces > to work in the way that the new bind-dynamic mode does, but I don't want > to have one mode which behaves subtly differently on different platforms. > By giving the new mode a new option, I can raise an error when it's not > available. I see, wasn't aware it can't be supported on BSD. makes sense than, thanks for pointing out. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
> From: Simon Kelley > Sent: Thursday, October 24, 2013 11:00 PM > > So, don't use --bind-interfaces. If you're on Linux, you can use --bind- > dynamic instead if you're running multiple dnsmasq instances. > So, on linux --bind-interfaces can be just an alias of --bind-dynamic, with no --bind-interfaces code and no warnings, less binary size, more seciruty. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Clarification of prefix length field in dhcp-range
Hi, Kevin Refer http://wl500g.googlecode.com/svn/trunk/dnsmasq/020-relax-prefix.patch It does what you want (ugly a bit), but, beware, it was made before following dnsmasq commit, need to handle it too, had no time to do so yet. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=486479e94308f8579a d5132a5218a74dbc707521 Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] gatway
> The problem with that is that RDNSS and DNSSL are per interface, not per- > prefix. Maybe the calculation should the maximum valid time of any prefix > advertised on the interface? It will not work for several different prefixes and serveral different global-scope addresses on dnsmasq interface. Since it's per interface (actually not, per router, but whatever), and onlink flag is always set, auto-cooked [::] rdnss address should contain link-local address of that interface, not global. After that, lifetimes can be max (or 2/3 of max to fit RFC defaults) of any valid ra lifetime. Also, announcing link-local addres of interface as RDNSS make life easier while prefix changing, renumbering, etc. As for user-specified RDNSS addresses, it's up to him to shoot in own foots and specify static or dynamic servers. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] gatway
Hi, Simon, Thanks for the implementation, works well with one issue is still there RDNSS & DNS Search List RA options contain lifetimes calculated from MaxRtrAdvInterval, where MaxRtrAdvInterval = , and MinRtrAdvInterval = 3/4* Since, there's no way to specify MinRtrAdvInterval & MaxRtrAdvInterval (as I proposed before), RDNSS & DNS Search List lifetimes always equal 2*. So, if is small, like 10sec, that lifetimes are small too, just 20sec, without any connection to . Hosts may refresh RDNSS info with RS packets and trigger solicited RA answers in addition to existing unsolicited RA packets. In the same time, with working DHCPv6 stateless/full lifetime is taken from dhcp-range, 600 sec as min. In radvd, MinRtrAdvInterval, MaxRtrAdvInterval, DefaultLifetime and other lifetimes can be set via conf file, In dnsmasq they are automatic, guess automatic needs to be tuned up. What do you think? Best Regards, Vladislav Grishenko > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Friday, October 11, 2013 2:01 AM > To: Vladislav Grishenko > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] gatway > > On 08/10/13 12:09, Vladislav Grishenko wrote: > >> From: Simon Kelley > >> Sent: Tuesday, October 08, 2013 4:20 PM On 06/10/13 11:32, Vladislav > >> Grishenko wrote: > >>> Hi, RFC4861 says: > >>> > >>> A router might want to send Router Advertisements without > > advertising > >>> itself as a default router. For instance, a router might advertise > >>> prefixes for stateless address autoconfiguration while not > >>> wishing > > to > >>> forward packets. Such a router sets the Router Lifetime field in > >>> outgoing advertisements to zero. > >>> > >>>>> is it possible to tell dnsmasq not to announce itself as router? > >>> So , yes, it's theoretically possible. > >> > >> That's good information, thanks. In answer to the next question, no, > >> it's > > not > >> possible to configure dnsmasq to send Router Lifetime == 0. > >> > >> The lifetime, in dhcp-range is used to calculate the lifetimes for > > prefixes, no > >> the router lifetime. In fact the router lifetime is always advertised > >> as > > 1800 > >> seconds, I think. > >> > >> Since this is a per-broadcast domain thing, and not per prefix thing, > >> it > > needs > >> to be associated with an interface. > >> > >> Simplest would be > >> > >> no-router-interface=[,,] > >> > >> to set the interfaces that get router lifetime of zero. > >> > >> More complex would be to allow explict setting of the router lifetime > >> per interface, that would have to be linked to the RA frequency: you > >> wouldn't want a router expiring before it could be re-advertised. > >> > > > > No-router-interface is simplest, and adds more option to control RA. > > Currently we have already: > > --dhcp-range=...ra-only|slaac|ra-names... > > --enable-ra > > --force-fast-ra > > > > What if to logically split options to dhcp*-related and to slaac-related? > > --dhcp-range= > > Sets only DHCP range/RA prefix parameters (including > > lease/prefix/rdnss/domain lifetimes), but not RA timeouts > > > > --enable-ra=[,,...][,AdvDefaultLifetime][,MinRtr > > AdvInt > > erval,MaxRtrAdvInterval] > > Sets only RA timouts, if params absent - use defaults, 600 as max, > > 1/3*600 as min. > > With this, both min& max can be configured, As per RFC, > > max should be in range 4-1800 secodns, default 600 > > min should be in range 3-3/4*max, default 1/3*max, if max>=9, > > otherwise equal to max > > > > With this approach, --no-router-interface will be alias of > > --enable-ra=interface,0 > > And --force-fast-ra will be an alias of > > --enable-ra=interface,1800,5,20 > > > > Also, current code uses 600 as max, and 3/4*max as min ra intervals, > > what fits RFC, bit, guessб isn't optimal, too big min delay. > > As for startup advertisements and force-fast-ra, interval is 5-20, but > > can be limited to range > > MIN_DELAY_BETWEEN_RAS-MAX_INITIAL_RTR_ADVERT_INTERVAL, 3 and > 16 > > respectively as RFC suggests Since RA can be very frequent, is it ever > > worth to log with LOG_INFO level every unsolicited RTR-ADVERT? It just > > floods syslog and has no other meaning in my opinion. > > &g
Re: [Dnsmasq-discuss] gatway
> From: Simon Kelley > Sent: Tuesday, October 08, 2013 4:20 PM > On 06/10/13 11:32, Vladislav Grishenko wrote: > > Hi, RFC4861 says: > > > > A router might want to send Router Advertisements without advertising > > itself as a default router. For instance, a router might advertise > > prefixes for stateless address autoconfiguration while not wishing to > > forward packets. Such a router sets the Router Lifetime field in > > outgoing advertisements to zero. > > > >>> is it possible to tell dnsmasq not to announce itself as router? > > So , yes, it's theoretically possible. > > That's good information, thanks. In answer to the next question, no, it's not > possible to configure dnsmasq to send Router Lifetime == 0. > > The lifetime, in dhcp-range is used to calculate the lifetimes for prefixes, no > the router lifetime. In fact the router lifetime is always advertised as 1800 > seconds, I think. > > Since this is a per-broadcast domain thing, and not per prefix thing, it needs > to be associated with an interface. > > Simplest would be > > no-router-interface=[,,] > > to set the interfaces that get router lifetime of zero. > > More complex would be to allow explict setting of the router lifetime per > interface, that would have to be linked to the RA frequency: you wouldn't > want a router expiring before it could be re-advertised. > No-router-interface is simplest, and adds more option to control RA. Currently we have already: --dhcp-range=...ra-only|slaac|ra-names... --enable-ra --force-fast-ra What if to logically split options to dhcp*-related and to slaac-related? --dhcp-range= Sets only DHCP range/RA prefix parameters (including lease/prefix/rdnss/domain lifetimes), but not RA timeouts --enable-ra=[,,...][,AdvDefaultLifetime][,MinRtrAdvInt erval,MaxRtrAdvInterval] Sets only RA timouts, if params absent - use defaults, 600 as max, 1/3*600 as min. With this, both min & max can be configured, As per RFC, max should be in range 4-1800 secodns, default 600 min should be in range 3-3/4*max, default 1/3*max, if max >=9, otherwise equal to max With this approach, --no-router-interface will be alias of --enable-ra=interface,0 And --force-fast-ra will be an alias of --enable-ra=interface,1800,5,20 Also, current code uses 600 as max, and 3/4*max as min ra intervals, what fits RFC, bit, guessб isn't optimal, too big min delay. As for startup advertisements and force-fast-ra, interval is 5-20, but can be limited to range MIN_DELAY_BETWEEN_RAS-MAX_INITIAL_RTR_ADVERT_INTERVAL, 3 and 16 respectively as RFC suggests Since RA can be very frequent, is it ever worth to log with LOG_INFO level every unsolicited RTR-ADVERT? It just floods syslog and has no other meaning in my opinion. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] gatway
Hi, RFC4861 says: A router might want to send Router Advertisements without advertising itself as a default router. For instance, a router might advertise prefixes for stateless address autoconfiguration while not wishing to forward packets. Such a router sets the Router Lifetime field in outgoing advertisements to zero. > > is it possible to tell dnsmasq not to announce itself as router? So , yes, it's theoretically possible. Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Wednesday, October 02, 2013 3:44 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] gatway > > On 02/10/13 02:57, Moritz Warning wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hi, > > > > is it possible to tell dnsmasq not to announce itself as router? > > The problem is that connected computers try to use the router as gateway. > > The router is not the gateway of the network, but some other computer. > > > > For what it matter, this is the IPv6 setting in my Dnsmasq (version 2.66) > configuration: > > > > dhcp-range=public,fdef:1700:::,ra-names,slaac,64,infinite > > I don't think it is, except by stopping it from advertising prefixes as well, (ie, > remove the above line completely). The protocol doesn't > (AFAIK) allow prefix advertisements which are not also router > advertisements. > > > It _might_ be possible to do the ra-names functionality whilst leaving > router/prefix announcement to another host, it would required code > changes and I've not thought hard about if it would work or be desirable. > > > Cheers, > > Simon. > > > > > thanks, > > mwarning > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.12 (GNU/Linux) > > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > > > > iQEcBAEBAgAGBQJSS319AAoJECHrh56PP4wpXgUH/j0D8rSF7qWciHLfmjlLtVh > Q > > > NUicHU4rN2ZyX1XTNn9HZi66tziZc3PcOs4y3xg+QKdUCkMKiQAV0CDgRmoqg > pe6 > > > ER03eC9ibBm7VLU/TubX2Z1tnHIDFwvkyDSP66LBwTbstyaxmS4cOTX6bzizL0o > H > > > fE2lwRMIYLn1eV5G/niLdxkZI+WjrWy/d6bggZ6N4M2GqPnwkHkdvdDRwMgo > 7F0h > > > 2aZWQs6PUxpFVuHpVYIZcDEvjYI1CBBi9BF6XXaiWIVSktnIQ0AfKYK58E3tkWAI > > > RnRJ0G3Di3DwNGpPJZ2Da6v0pR1PEKMcjzmcvfKgwdFiKBVP2SMa3VHPXkAQ > z7s= > > =ign/ > > -END PGP SIGNATURE- > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Announce: dnsmasq-2.67rc1
Hi Simon, > Remove the rule for constructed DHCP ranges that the local > address must be either the first or last address in the > range. This was originally to avoid SLAAC addresses, but > we now explicitly autoconfig and privacy addresses > instead. There's minor cosmetic issue after above changes. Dnsmasq logs first address for SLAAC/DHCP stateless templates on startup, what makes sense only for DHCPv6 stateful. Example: br0 inet6 addr: 2001:db8::1/64 Scope:Global dhcp-range=lan,::2,::255,constructor:br0,ra-names,64,86400 dnsmasq-dhcp: DHCPv6, IP range ::2 -- ::255, lease time 1d, template for br0 dnsmasq-dhcp: DHCPv4-derived IPv6 names on ::2, template for br0 dnsmasq-dhcp: router advertisement on ::2, template for br0 dnsmasq-dhcp: DHCPv6, IP range 2001:db8::2 -- 2001:db8::255, lease time 1d, constructed for br0 dnsmasq-dhcp: DHCPv4-derived IPv6 names on 2001:db8::, constructed for br0 dnsmasq-dhcp: router advertisement on 2001:db8::, constructed for br0 dnsmasq-dhcp: IPv6 router advertisement enabled Addr "::2" shown above in DHCPv4-derived IPv6 names and router advertisement is redundant, because not further used. Actually, non-DHCPv6 stateful templates use only prefix part of the first address in configured range, in example above "::2/64" => "::". Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Reg: Info related to leases file
> From: Simon Kelley [mailto:si...@thekelleys.org.uk] > > I understand that leasefile format is preserved due legacy reasons to > > allow dnsmasq precompiled updates. > > What if just to add LEASEFILE_LEGACY_FORMAT define to control the subj > > format? > > Ppl who able to build it and to control lease format dependent apps > > would be able to enable/disable it and use on his own, while the rests > > can continue to use legacy defaults with no harm. > > No code redundancy would be brought this way, new/old lease-format > > code would be just not compiled in, anyway don't treat this opinion as > > a kind of pushing, just consider it's probably good to have it in upstream. > > The problem is that you're asking for two incompatible things. You want the > leasefile format to be a defined interface, which implies, amongst other > things, that it's stable, and you want to change the leasefile format. > BTW, as far as I'm concerned, the leasefile format has never been a defined > interface, if people are looking in there directly, that's their risk. Actually not exactly, I see possible leasfile code simplification, and in the side effect it could be possible to have file format as defined interface, nothing else. Ok, if lease format hasn't never been a defined interface, nothing should prevent from format change at any time, right? So, why not then. > > > > Thanks for the remind, both cases require either HAVE_SCRIPT or > HAVE_DBUS to > > be enabled, openwrt folks use scripts from the very start. > > So, dnsmasq code, additional not-dnsmasq file sizes& required mem > > increases, complexity grows, possible fault places number too, with the > same > > desired result as if leasefile contains new lease info. > > In my humble opinion, it seems a little bit overkill for embedded world. > > As an example - a number of recent mails of Tomato firmware folks here in > > the list when they decided to update dnsmasq and have accidentally > dropped > > homegrown leases-save code, that extends the format of the original one. > > They have the same reasons - keep dnsmasq& outter environment as > small and > > functional as possible. > > HAVE_SCRIPT isn't very big and this tiny shell script makes a file of > (IP-address, MAC-address) pairs. It's trivial to alter it to split IPv4 > and IPv6 into different files or include any information from the fields > exposed by the script interface. The script interface is defined and > I'll keep it compatible going forward. Ok, giving up. Script-based has even-driven pros while adding/deleting lease. My next concern is about lease init stage, when dnsmasq needs to be restarted due reconfig. Does it need to be implemented, or leasefile in whatever format could coexist with script? Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Reg: Info related to leases file
> From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Tuesday, September 24, 2013 9:16 PM > > On 24/09/13 15:31, Vladislav Grishenko wrote: > > Hi Simon, > > > >> However, if you're interested in the MAC addresses of clients, the > >> very > > latest > >> dnsmasq code can determine that in most cases. The MAC address is not > >> stored in the leases file, but it can be used to key configurations > >> to > > particular > >> MAC addresses, and it's made available to the DHCP lease external > >> script, > > so > >> an external application can use it. > > > > Storing MACs for DHCPv6 clients is just exactly I'm looking for. > > In my scenario, lease file is used to obtain current list of DHCP4/6 > > clients as some status information, the latter usage of this info is: > > * DHCP4/6 reservation, it's MAC-based, because client DHCP6 DUID-LLT > > is dynamic by the nature, thanks for implementing this approach > > * client blocking, it's MAC bases too > > So, storing lease info with MAC for DHCPv6 clients (if available, that > > is highly likely for direct-connected clients) is the simplest way for > > my case without usage any other leasudump-like api > > > > Best Regards, Vladislav Grishenko > > > > > > > > I realise that adding to MAC to the leasefile for DHCPv6 clients would make > this possible, but I'm reluctant to change the leasefile format. I understand that leasefile format is preserved due legacy reasons to allow dnsmasq precompiled updates. What if just to add LEASEFILE_LEGACY_FORMAT define to control the subj format? Ppl who able to build it and to control lease format dependent apps would be able to enable/disable it and use on his own, while the rests can continue to use legacy defaults with no harm. No code redundancy would be brought this way, new/old lease-format code would be just not compiled in, anyway don't treat this opinion as a kind of pushing, just consider it's probably good to have it in upstream. > One way to do this now is to script (as script or with Lua) something > which maintains an extended lease database. It's actually possible to do > without the leasefile at all (which saves on writes to flash > filesystems) and have the script maintain the database in any database > engine you like. > Another possibility for a future enhancement is to add a method to the > DBus interface to read the lease database. There's a lot of information > that can be known about a lease/client that will never go into the > leases file, but could be accessible this way: look at all the > environment variables set when the DHCP script is run. Thanks for the remind, both cases require either HAVE_SCRIPT or HAVE_DBUS to be enabled, openwrt folks use scripts from the very start. So, dnsmasq code, additional not-dnsmasq file sizes & required mem increases, complexity grows, possible fault places number too, with the same desired result as if leasefile contains new lease info. In my humble opinion, it seems a little bit overkill for embedded world. As an example - a number of recent mails of Tomato firmware folks here in the list when they decided to update dnsmasq and have accidentally dropped homegrown leases-save code, that extends the format of the original one. They have the same reasons - keep dnsmasq & outter environment as small and functional as possible. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Reg: Info related to leases file
Hi Simon, > However, if you're interested in the MAC addresses of clients, the very latest > dnsmasq code can determine that in most cases. The MAC address is not > stored in the leases file, but it can be used to key configurations to particular > MAC addresses, and it's made available to the DHCP lease external script, so > an external application can use it. Storing MACs for DHCPv6 clients is just exactly I'm looking for. In my scenario, lease file is used to obtain current list of DHCP4/6 clients as some status information, the latter usage of this info is: * DHCP4/6 reservation, it's MAC-based, because client DHCP6 DUID-LLT is dynamic by the nature, thanks for implementing this approach * client blocking, it's MAC bases too So, storing lease info with MAC for DHCPv6 clients (if available, that is highly likely for direct-connected clients) is the simplest way for my case without usage any other leasudump-like api Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Reg: Info related to leases file
> Out of the three types: DUID-LLT, DUID-EN and DUID-LL, which one is used > by dnsmasq? I am asking because I want to confirm whether the MAC > address of the network interface is always a substring of the client DUID or > not. 1. DUID-EN, if --dhcp-duid specified 2. DUID-LL from MAC of the first suitable interface, if HAVE_BROKEN_RTC defined 3. DUID-LLT from MAC of the first suitable interface for all other cases FYI, as per RFC3315 DUIDs should be treated as opaque values only: > 9. DHCP Unique Identifier (DUID) > Clients and servers MUST treat DUIDs as opaque values and MUST only > compare DUIDs for equality. Clients and servers MUST NOT in any > other way interpret DUIDs. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 Server not respecting lease time setting
Hi Jonathan, There's quick fix for your issue, if client hasn't specified preferred address lifetime, lease time is used. Valid timeout value is still ignored. <http://wl500g.googlecode.com/svn/trunk/dnsmasq/110-no-lifetime-preference.p atch> http://wl500g.googlecode.com/svn/trunk/dnsmasq/110-no-lifetime-preference.pa tch Best Regards, Vladislav Grishenko From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq-discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Jonathan Fabian Sent: Thursday, August 01, 2013 4:06 AM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] DHCPv6 Server not respecting lease time setting Hi, I'm seeing some strange behavior between my mac and dnsmasq (running on arch linux arm) when getting assigned an IPv6 address. Specifically, I have the DHCPv6 set to give out a 12 hour lease time: dhcp-range=a:b:c::1, a:b:c::ff, 64, 12h, but it will only give the mac a 2 min lease time (as a side note, I have also tried setting a dhcp host option specifically for macs duid and it ignores those lease time values as well). The lease time setting works fine with the windows machines on the same network. Looking at the network packets, I see the mac solicit the dhcp server, the dhcp server replies with an advertisement message offering an ip address with a valid and preferred lifetime of 43200, then the mac replies with a request for the advertised ip address with the valid and preferred lifetimes set to 0 (which looking at rfc3315 should be treated as no preference), dnsmasq then sends back a reply with the address but the valid and preferred lifetimes only set to 120 (the min time allowed)! The only difference I can see with the windows machines is that when a windows machine sends the request message they copy the preferred and valid lifetimes of 43200 from the advertise message. Maybe I'm wrong, but it seems that dnsmasq should always be ignoring the 0 when sent, and only treating the valid and preferred lifetimes from the client as a request at best. It seems, however, to be treating them in a manner that overrides the explicitly configured setting in its config files. Can anyone shed some light on this behavior? Thanks, Jonathan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 lease hwaddr
Little addition, previous mail says nothing about iaid, it needs be moved to separate lease filed too, and, for example before/after/with flags in leasefile. Best Regards, Vladislav Grishenko > -Original Message- > From: Vladislav Grishenko [mailto:themi...@mail.ru] > Sent: Sunday, August 04, 2013 7:32 PM > To: 'dnsmasq-discuss@lists.thekelleys.org.uk' > Cc: Simon Kelley (si...@thekelleys.org.uk) > Subject: DHCPv6 lease hwaddr > > Hi Simon, > > dnsmasq 2.67test9 dhcpv6 leases implementation uses only clid approach, > which is the same and should not be treated as containing client's hwaddr. > It makes impossible in real life to specify specific dhcpv6 options for clients, if > only mac address is known (ISP billing, specific & static allocations, etc). > > But, in fact, if DHCPv6 client directly attached, link layer address is available > just from the packet, but if they are served via relay, relay agent may use > OPTION_CLIENT_LINKLAYER_ADDR as defined in RFC6939. Refer > http://tools.ietf.org/html/rfc6939: > > 5. DHCPv6 Relay Agent Behavior >DHCPv6 relay agents that receive messages originating from clients >(for example, Solicit and Request, but not, for example, >Relay-Forward or Advertise) MAY include the link-layer source address >of the received DHCPv6 message in the Client Link-Layer Address >option, in relayed DHCPv6 Relay-Forward messages. The DHCPv6 relay >agent behavior can depend on configuration that decides whether the >Client Link-Layer Address option needs to be included. > 6. DHCPv6 Server Behavior >If the DHCPv6 server is configured to store or use a client link- >layer address, it SHOULD look for the Client Link-Layer Address >option in the Relay-Forward DHCP message of the DHCPv6 relay agent >closest to the client. The mechanism described in this document is >not necessary in the case where the DHCPv6 server is connected to the >same network link as the client, because the server can obtain the >link-layer address from the link-layer header of the DHCPv6 message. >If the DHCP server receives a Client Link-Layer Address option >anywhere in any encapsulated message that is not a Relay-Forward DHCP >message, the server MUST silently ignore that option > > So, we can keep using hwaddr for DHCPv6 clients, if it's available, and make > leasefile & mac-based options work. > Also, it will allow struct lease, code and leasefile format cleanup: > > Lease struct contains struct in_addr addr and hwaddr member is reused as > struct in_addr in6_addr, so we have no hwaddr for v6 clients Lease file is > looks like, where for DHCPv6 records hwaddr is replaced by hwtype + 32 bit > of hwaddr > 86400 00:21:6a:xx:xx:xx 192.168.1.191 host 01:00:21:6a:xx:xx:xx > 86400 553656682 201:db8::109 host > 00:01:00:01:14:0d:23:69:90:e6:ba:xx:xx:xx > If lease struct will contain separate struct in6_addr for ipv6 address or even > struct all_addr, hwaddr could be kept and used as is. > As for lease file format, it could look like below: > 86400 [hwtype-]00:21:6a:xx:xx:xx 192.168.1.191 host 01:00:21:6a:xx:xx:xx > [%04x: flags like TA/NA/other] > 86400 [hwtype-]00:21:6a:xx:xx:xx 201:db8::109 host > 00:01:00:01:14:0d:23:69:90:e6:ba:xx:xx:xx [%04x: flags like TA/NA/etc] Legacy > format with %u (even not %lu for keeping the whole hwaddr...) can be easily > supported, but doesn't worth to, since no soft writes it directly for ipv6 > leases. > > Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DHCPv6 lease hwaddr
Hi Simon, dnsmasq 2.67test9 dhcpv6 leases implementation uses only clid approach, which is the same and should not be treated as containing client's hwaddr. It makes impossible in real life to specify specific dhcpv6 options for clients, if only mac address is known (ISP billing, specific & static allocations, etc). But, in fact, if DHCPv6 client directly attached, link layer address is available just from the packet, but if they are served via relay, relay agent may use OPTION_CLIENT_LINKLAYER_ADDR as defined in RFC6939. Refer http://tools.ietf.org/html/rfc6939: 5. DHCPv6 Relay Agent Behavior DHCPv6 relay agents that receive messages originating from clients (for example, Solicit and Request, but not, for example, Relay-Forward or Advertise) MAY include the link-layer source address of the received DHCPv6 message in the Client Link-Layer Address option, in relayed DHCPv6 Relay-Forward messages. The DHCPv6 relay agent behavior can depend on configuration that decides whether the Client Link-Layer Address option needs to be included. 6. DHCPv6 Server Behavior If the DHCPv6 server is configured to store or use a client link- layer address, it SHOULD look for the Client Link-Layer Address option in the Relay-Forward DHCP message of the DHCPv6 relay agent closest to the client. The mechanism described in this document is not necessary in the case where the DHCPv6 server is connected to the same network link as the client, because the server can obtain the link-layer address from the link-layer header of the DHCPv6 message. If the DHCP server receives a Client Link-Layer Address option anywhere in any encapsulated message that is not a Relay-Forward DHCP message, the server MUST silently ignore that option So, we can keep using hwaddr for DHCPv6 clients, if it's available, and make leasefile & mac-based options work. Also, it will allow struct lease, code and leasefile format cleanup: Lease struct contains struct in_addr addr and hwaddr member is reused as struct in_addr in6_addr, so we have no hwaddr for v6 clients Lease file is looks like, where for DHCPv6 records hwaddr is replaced by hwtype + 32 bit of hwaddr 86400 00:21:6a:xx:xx:xx 192.168.1.191 host 01:00:21:6a:xx:xx:xx 86400 553656682 201:db8::109 host 00:01:00:01:14:0d:23:69:90:e6:ba:xx:xx:xx If lease struct will contain separate struct in6_addr for ipv6 address or even struct all_addr, hwaddr could be kept and used as is. As for lease file format, it could look like below: 86400 [hwtype-]00:21:6a:xx:xx:xx 192.168.1.191 host 01:00:21:6a:xx:xx:xx [%04x: flags like TA/NA/other] 86400 [hwtype-]00:21:6a:xx:xx:xx 201:db8::109 host 00:01:00:01:14:0d:23:69:90:e6:ba:xx:xx:xx [%04x: flags like TA/NA/etc] Legacy format with %u (even not %lu for keeping the whole hwaddr...) can be easily supported, but doesn't worth to, since no soft writes it directly for ipv6 leases. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Forwarding all DNS requests (wildcard effectively) to single upstream server
> From: Stuart Jenkins > Sent: Wednesday, May 22, 2013 2:44 AM > >I thought a quick one line in the /etc/dnsmasq.conf file would be the solution (a variant of) >server=[/[]/[domain/]][[#][@|[# ]] >But apparently server=//a.b.c.d will not work as: "An empty domain specification, // has the special meaning of "unqualified names only" ie names without any dots in them. " >I know I am missing something - any hints? "server=/#/a.b.c.d" does what you need, # matches everything and becomes a zero length domain string. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] autogenerating dns records
> From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Thursday, April 25, 2013 4:18 PM > > I'm not clear what the advantage is. The main advantage is to have automatic reverse PTR records for the subnet(s) for online services that check it (ftp, irc, etc). While IPv4 is quite ok to pre-generate, it's quite impossible/inefficient for IPv6 SLAAC subnet(s). Mean intended to be viewable, but not to be reused by human offen. There're already tools to force readable names in dnsmasq/hosts, this is about autogeneration only. > The maximum length of the presentation > form of an IPv6 address is 46 characters, which fits in a DNS label (63 max) > quite comfortably. A matter of taste, I'd say. Full IPv6 reverse PTR representation plus domain could not fit format (example: IRC server names name!name@host, where host is reverse looked-up name) > By encoding the address, that makes it useless for > humans, which is the main point of doing this, plus you'd have to support the > encoded form in forward as well as reverse queries, since people will do a > reverse query and then use the result in a forward query later. Actually not, since IPv6 address (with zero comp) could be more readable (mean short), than expanded one plus domain. As wrote above, main aim - to have reverse PTR records without pregeneration for services, not for humans, also it's kind of masking. > You've reminded me however that the prefix is limited to 63-46 for IPv6, to > be sure to avoid the label length limit. The problem is it's artificial limit, one can use private prefix even with /3 or less. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] autogenerating dns records
Hi Simon, Really, good feature, thanks for including it. Have a suggestion not for naming, but for ipv6 reverse domain algo. Since ipv6 domain representation could be quite long, it can be shortened. For example, using duotrigesimal system (base 32) + zero compression: 2001:db8::1 => 1zigr64z21 2001:db8:1234:5678:90ab:cdef:1234:5678 => ojl839stdua19spakh4gr64z21 Here's working minimalistic IPv6 Reverse DNS daemon I'm using (with dnsmasq conf server=/domain.local/127.0.0.1#5353) which implements the approach. https://code.google.com/p/rev6dns/ $ rev6dns -a 127.0.0.1 -p 5353 ns.domain.local domain.local 2001:db8::/32 $ dig -x 2001:db8::1 @127.0.0.1 -p 5353 ;; ANSWER SECTION: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 3994671 IN PTR 1zigr64z21.domain.local. $ dig -x 2001:db8:1234:5678:90ab:cdef:1234:5678 @127.0.0.1 -p 5353 ;; ANSWER SECTION: 8.7.6.5.4.3.2.1.f.e.d.c.b.a.0.9.8.7.6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa. 3994671 IN PTR ojl839stdua19spakh4gr64z21.domain.local. $ dig 1zigr64z21.domain.local. @127.0.0.1 -p 5353 ;; ANSWER SECTION: 1zigr64z21.domain.local. 62511 IN 2001:db8::1 Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Thursday, April 25, 2013 1:48 AM > To: Vishvananda Ishaya > Cc: dnsmasq discussion list > Subject: Re: [Dnsmasq-discuss] autogenerating dns records > > On 08/04/13 18:07, Vishvananda Ishaya wrote: > > Thanks appreciate the feedback. I am going to do some testing to see > > how expensive it is to add a whole bunch to the hosts file for now. > > If that is too painful I will work on a patch. > > > > Vish > > > > > I've been working through my post-release TODO list. Please try > 2.67test3 which has a new --synth-domain option. > > Suggestions as to a better name for the option gratefully received. > > Cheers, > > Simon. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Patch] dnsmasq with IPSET feature enabled doesn't compile on linux kernel < 2.6.24
Dears, We have 2.6.22 with ipset. Plz, keep in mind there're no only vanilla kernels around. Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Monday, April 22, 2013 7:07 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] [Patch] dnsmasq with IPSET feature enabled > doesn't compile on linux kernel < 2.6.24 > > On 20/04/13 15:31, Eugene Rudoy wrote: > > Dear all, > > > > dnsmasq with IPSET feature enabled (added in dnsmasq-2.66 and enabled > > by > > default) doesn't compile on linux kernel versions< 2.6.24. The > > attached patch fixes the problem by disabling the feature for these kernel > versions. > > > > As far as I understand the missing symbols are just convenience ones, > > from technical point of view it is possible to add IPSET support also > > for kernel versions prior to 2.6.24. I however don't need this > > feature, thus simple disable-patch. > > > > Hmmm, As I recall, considerable effort was made to get this code to work > with old kernels, so I'm wary of just disabling it in this circumstance. > CC'ing the orginal author for his comments. > > > Cheers, > > Simon. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Config file behaviour - change/bug/feature - comments
Hi Kevin, Frankly speaking, resulting following conf should be only treated as misconfiguration. > interface=br0 > no-dhcp-interface=br0 > interface=br0 As for tomato, it's up to fw logic/general settings why dhcp is disabled via web ui, but tried ti be enabled by user custom settings. So, there's nothing wrong with dnsmasq to be fixed, instead just drop no-dhcp-interface line from being saved. If there's no dhcp-range, no dhcp will happen anyway. Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Kevin Darbyshire- > Bryant > Sent: Wednesday, March 27, 2013 11:41 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: [Dnsmasq-discuss] Config file behaviour - change/bug/feature - > comments > > Hi Simon, > > As previously mentioned I got 2.66test16 into a recent version of Tomato > router firmware which means it's now out in the wild and being used. An > obscure corner case change in behaviour has been observed, relating to > disabling and then re-enabling dhcp service on an interface, and specifically > which lines in a config file stick. Example config: > > interface=br0 > no-dhcp-interface=br0 > > then later in the file: > > interface=br0 > dhcp-range=br0,192.168.235.21,192.168.235.254,255.255.255.0,720m > dhcp-option=br0,3,192.168.235.1 > dhcp-option=br0,44,0.0.0.0 > > Now in v2.61 (!) dnsmasq would take the last interface line and say 'oh you > do want dns AND dhcp service' and everything would procede as expected. > In 2.66, once no-dhcp-interface is set it's set and dhcp service is disabled > forever. Now there's a very valid argument that the above example is a > stupid config file. Unfortunately the example config file is representative of > the conflicts between the automatically generated part of Tomato's dnsmasq > config, and the manual 'advanced config options' that get appended to the > file via the router's GUI. > > Now I personally think the router's gui should be fixed (though I've no idea > how at this point) but is there perhaps an argument that an 'interface=intfn' > command later in the file should also reset the 'no-dhcp-flag'? > > Kevin ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Enable HAVE_IPSET by default
Hi Simon, Here's output from bloat-o-meter (busybox's one) after enabling HAVE_IPSET on mips32 platform The growth is ~2Kb, I guess it's ok to have it enabled by default for bb, but please, insist on not to drop HAVE_IPSET define. At least, not the all kernels jave it patched/builtin. function old new delta add_to_ipset - 832+832 one_opt25184 25600+416 ipset_init - 392+392 process_reply8721104+232 extract_addresses 23402464+124 main68406872 +32 .rodata25440 25472 +32 snl- 12 +12 old_kernel - 4 +4 ipset_sock - 4 +4 buffer - 4 +4 -- (add/remove: 6/0 grow/shrink: 5/0 up/down: 2084/0) Total: 2084 bytes Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Thursday, March 21, 2013 9:09 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Enable HAVE_IPSET by default > > On 21/03/13 15:05, sven falempin wrote: > > > > > DNSMASQ also run on system like FreeBSD, do not assume a linux kernel > > -_- you could also have a cygwin port one day. > > > > You want IPSET ? you turn it on. > > Imagine if everyone want his very own favorite feature set by default ! > > > That's true, but not relevant. IPSET gets turned off automatically in non-linux > builds, and it's not proposed to change that. > > > Cheers, > > Simon. > > > > ___ > Dnsmasq-discuss mailing list > <mailto:Dnsmasq-discuss@lists.thekelleys.org.uk> Dnsmasq-discuss@lists.thekelleys.org.uk > <http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Enable HAVE_IPSET by default
Hi Simon, Just my 2 cents, binary size is important on devices with very limited flash size (2Mb, 4Mb). So HAVE_IPSET compile-time switch should continue to exist, same as others, have no idea about default compile-time states, we always can override them. Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Thursday, March 21, 2013 4:08 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Enable HAVE_IPSET by default > > On 20/03/13 17:31, Jason A. Donenfeld wrote: > > Hi Simon, > > > > It's just occurred to me that no router developer is going to know to > > turn HAVE_IPSET on, and hence, it won't be available immediately on > > any devices, which is a bummer. Further, unless the --ipset= options > > are used, HAVE_IPSET doesn't contribute at _all_ to the runtime of the > app. > > And even further, if HAVE_LINUX_NETWORK isn't enabled, HAVE_IPSET is > > automatically disabled. > > > > Makes sense, then, I think, to uncomment HAVE_IPSET by default. > > > > How about it? > > > > I'm torn. > > The main reason for not including this is to reduce footprint. (It does affect > binary size, which matters, but the delta isn't going to be very > big.) > > The second reason (in general) for excluding stuff at compile time is to > maintain the invariant that the distributed tarball can be built with just a C- > compiler and make: no other library or tool dependencies. This was relevant > for the first versions of ipset, but is no longer a factor as it doesn't depend on > external libraries. > > OTOH. > > Router firmware makers, in my experience, make definite decisions about > what they want included at compile time: the defaults as I distribute them > are not very relevant, as they get overridden. Ideally, you want router distros > to actively take up the new facility and support it in their configuration > system/ web pages/ documentation. > > "Full fat" distro packagers also pick what they want, taking into account that > library dependencies are not a problem. I include ipset in the Debian > dnsmasq package, that will cascade to Ubuntu. I'd expect Fedora and thus > Redhat to take the same path. > > > Finally, if it's going to be on by default, and given the limited size delta/lack of > library definitions, there's an argument for not making it compile-time > selectable at all. Every compile-time switch contributes to the combinatorial > explosion of possible binaries, and lots of bugs come from unanticipated > interactions in untested compile-flag combinations. > > > Opinions, anyone? > > > > Simon. > > > > > > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] build fails with HAVE_BROKEN_RTC
Hi, Simon After auth code merging, one die() call has insufficient agrs for HAVE_BROKEN_RTC case. Refer patch attached Best Regards, Vladislav Grishenko zone-serial-with-broken-rtc-fix.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [dnsmasq] Errors found by static analysis of source code (Coverity)
Hi Simon, We have a regression after aa608c84b499f75b692a1eb4120f7851f10912e4 Fix wrong syntax check. If lease time is set and valid, *cp points to \0 and so !*cp triggers bad dhcp-range error for valid case. Refer obvious patch attached. Btw, why not to use strto(u)l funcs for number checking simplification? Refer alternative patch as well, probably other code places need it too. Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Tuesday, February 05, 2013 8:58 PM > To: Tomas Hozza > Cc: dnsmasq-disc...@thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] [dnsmasq] Errors found by static analysis of > source code (Coverity) > > On 04/02/13 10:24, Tomas Hozza wrote: > > Hello Simon. > > > > We at Red Hat are scanning a lot of open source packages with static > > analysis tool named Coverity. I have been scanning and reviewing group > > of network daemons where dnsmasq falls in, too. > > > > I scanned the latest dnsmasq-2.66-test13 source with Coverity version > > 6.5.1. It found 115 errors from which a lot of are just false > > positives or are not worth fixing. I wrote patches for issues that I > > think should be fixed. Please review and consider fixing these issues. > > I'm also including the Coverity scan log, so you can have a look at > > all errors. > > > > Coverity is also running a project where they allow open source > > project to be scanned for FREE. If you find it interesting you can > > find more information on http://scan.coverity.com/. > > > > If you have any questions about the scan or want to do more scanning, > > don't hesitate to write me back. > > > > > > More patches: > > 0018-RESOURCE_LEAK-CWE-404.patch > Taken, but only a problem if one malloc succeeds and a second fails - then we > leak the first block. I won't lose sleep over that. > > 0019-REVERSE_INULL-CWE-476.patch > Fixed. !cp should be !*cp > > 0020-STRING_OVERFLOW-CWE-120.patch > Not taken, same as 0001-STRING_OVERFLOW. > > 0021-UNUSED_VALUE-CWE-563.patch > Taken. straightforward. > > 0022-USE_AFTER_FREE-CWE-416.patch > Taken. New code in 2.66test* > > 0023-USE_AFTER_FREE-CWE-416.patch > Taken, changed style of fix to match other code. > > > > A very worthwhile exercise, thanks Tomas. > > I've pushed the fixes into git. > > > Cheers, > > Simon. > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss dhcp-range-lease-fix.patch Description: Binary data dhcp-range-lease-fix-alt.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Additional feature requested for stateful DHCHv6 together with a 6RD-tunnel to the ISP
> From: Simon Kelley > Sent: Friday, January 11, 2013 8:59 PM > > On 11/01/13 11:09, Vladislav Grishenko wrote: > > 4. syntax constructor: can be done in constructor[:] > > way, with usage of interface= data minus dhcp excluded interfaces. > > Sorry, I don't understand what you're suggesting here. I mean it would be handy to re-use interface= option values (if any) for dhcp-range construction. Current syntax (br0 interface appears twice) interface=br0 dhcp-range=::1,constructor:br0,... Suggested syntax: interface=br0 dhcp-range=::1,constructor,... Reason - configuration simplification Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Additional feature requested for stateful DHCHv6 together with a 6RD-tunnel to the ISP
Hi Simon, constructor: stuff works well, and is useful not only for 6RD, but for 6to4, upstream DHCPv6_PD also, and even for simplifying static addresses configuration without dnsmasq restart. Great. There's still some thought about: 1. DHCP stateless with dhcp-range=::1,constructor:br0,ra-stateless,64 Works with unneeded (in case of no DHCPv6 stateful) full address in log dnsmasq-dhcp[9636]: DHCPv6 stateless on ::1 dnsmasq-dhcp[9636]: router advertisement on ::1, template for br0 dnsmasq-dhcp[9636]: DHCPv6 stateless on ::::1 dnsmasq-dhcp[9636]: router advertisement on ::::, constructed for br0 For dhcp stateless, only prefix should be used/shown, imho 2. DHCP stateless with dhcp-range=::,constructor:br0,ra-stateless,64 I.e empty prefix before construction, this is not working at all. Neither with 64 prefix, nor without (it's 64 by default, and resetting to 0, if prefix is empty in options.c) 3. Only new addresses on interface trigger recalculation. This works for scenarios: 1. Del old address from interface 2. Add new address on interface => only new is announced now And this is not work well with backorder scenario: 1. Add new address on interface => both addresses are announced 2. Del old address from interface => nothing happens If address is deleted, shouldn't it became deprecated for announcing (ra)? Haven't played with address deprecation instead of deletion yet. 4. syntax constructor: can be done in constructor[:] way, with usage of interface= data minus dhcp excluded interfaces. Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Friday, January 11, 2013 4:24 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Additional feature requested for stateful > DHCHv6 together with a 6RD-tunnel to the ISP > > I meant to say in my last reply that the new constructor: mode only currently > works on Linux. I need a *BSD networking guru to help me with the BSd > equivalent of the netlink-foo used to make it all happen. > > > Cheers, > > Simon. > > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
Hi Gene, Instead of deprecating/turning-off logging by facility, it would be better to have ability to tune loglevel for each sysbsystem. Like following: where 0 means log-level=dhcp,dhcpv6,6,dns,7,ra,-1 Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Gene Czarcinski > Sent: Sunday, November 25, 2012 9:31 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] RA support in dnsmasq > > On 11/24/2012 11:20 AM, Gene Czarcinski wrote: > > OK, I am using both "ra-only" and "enable-ra" in a couple of libvirt > > dnsmasq instances. > > > > 1. I am getting a lot of "clutter" in syslog. How about using > > log-dhcp to also enable all of the "RTR-ADVERT" messages. There are a > > lot of them but they really provide little if any useful information. > > That is, add: > > if (option_bool(OPT_LOG_OPTS)) > > > > 2. I am getting a lot of RTR-ADVERT messages. I know it is suppose > > to start off frequently but then slow up to a much less frequent > > period (intervals of seconds). I thought this was a problem but then > > I looked into radvd and it also issues advertisements often so I > > assume things are working properly. However, I am concerned that all > > those syslog messages will lead others to suspect a problem where > > there is none. > > > > 3. Similar to radvd, should there be some dnsmasq parameters which are > > used to specify how often RAs will be issued? > > > OK, I am going to slightly increase the scope of this. Simon, how receptive > are you to adding a "couple" of new options to enable/disable some logging. > > 1. log-ra to enable RA logging which, by default, is disabled. This would be its > own option and not related to log-dhcp. > > 2. log-dhcp-renew to enable the log messages about renewing DHCP > requests which would, by default, be disabled. > > The messages from both of these currently run as if they were disabled. > Since I am running/testing using dnsmasq's RA services, I first noticed all of > the RA related messages and would like them to be normally suppressed. > > Apparently other libvirt users noticed the dhcp-renew messages and don't > wish to see them either. > > If you are receptive, I will do the heavy lifting but I would like to see this in > 2.64 if there is possibly enough time. > > Gene > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Improve DHCP stateless support
Hi Simon, As I wrote bofore, it's impossible to setup dnsmasq to do only DHCPv6 stateless and to not depend on interface/config addresses/prefixes. DHCPv6 stateless mode should not care about address allocation, but dnsmasq code enforces it with ra-stateless and even static. Suggested patch allows to setup DHCPv6 static range up to ::/0, what means every and any client will be served with stateless options like DNS, etc. Following example enables DHCPv6 stateless information allocation for any requesting client (after interface/address filtering, if set), including DNSv6 derived from current interface address, DNSv6 search list and information-refresh time to prevent obsolete data usage on clients for the default time value (86400). Clients get autonomous prefixes and default route via RA (radvd) with O bit (AdvOtherConfigFlag) set. No dnsmasq restart is needed in case of prefixes and listening interface address changes. dhcp-range=::,::,static,0 dhcp-option=option6:23,[::] dhcp-option=option6:24,example.com dhcp-option=option6:32,600 Known bug: information-request messages handling lacks of full tag support, including ra-stateless, static ranges. Only interface name and DHCPv6 tag will be added, whatever they were set for range. DNSv6 option will be used in any case (if set), but any others with tags - will not. Fixing it is highly useful, but is out of the subject scope. Test case: dhcp-range=set:lan,::,::,static,0 dhcp-option=tag:lan,option6:23,[::] dhcp-option=tag:lan,option6:24,example.com dhcp-option=tag:lan,option6:32,600 Refer patch attached. Best Regards, Vladislav Grishenko ICQ: 303357 MSN: themi...@mail.ru Skype: the.miron 0001-Relax-static-dhcpv6-ranges-up-to-0.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] It works: multiple dnsmasqs running
Refer patch attached (against current git) Best Regards, Vladislav Grishenko > -Original Message- > From: Vladislav Grishenko [mailto:themi...@mail.ru] > Sent: Sunday, October 14, 2012 3:51 PM > To: 'Gene Czarcinski'; 'dnsmasq-discuss@lists.thekelleys.org.uk' > Subject: RE: [Dnsmasq-discuss] It works: multiple dnsmasqs running > > Hi Gene, Simon, > > I'm using similar patch for a couple of months already. > Works fine, hadn't time to send it here yet. > > As for V6ONLY, with wildcarding and without this socket will listen for IPv4 > messages too on 547 port, nut not sure v6-mapped addresses will pass > checks there. > Anyway, behavior is externally controlled by sysctl net.ipv6.bindv6only, so, > it's better to set the flag, just in case. > > Best Regards, Vladislav Grishenko > > > -Original Message- > > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Gene Czarcinski > > Sent: Sunday, October 14, 2012 1:45 AM > > To: dnsmasq-discuss@lists.thekelleys.org.uk > > Subject: Re: [Dnsmasq-discuss] It works: multiple dnsmasqs running > > > > On 10/13/2012 02:39 PM, Gene Czarcinski wrote: > > > I still have the setting of IPV6_V6ONLY and I do not know if this is > > > needed. I will try and run some tests without it and see if it > > > still works. > > Tested: not needed. > > > > Gene > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss 0001-Allow-multiple-dnsmasq-instances-and-fix-DHCPv6-sock.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] It works: multiple dnsmasqs running
Hi Gene, Simon, I'm using similar patch for a couple of months already. Works fine, hadn't time to send it here yet. As for V6ONLY, with wildcarding and without this socket will listen for IPv4 messages too on 547 port, nut not sure v6-mapped addresses will pass checks there. Anyway, behavior is externally controlled by sysctl net.ipv6.bindv6only, so, it's better to set the flag, just in case. Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Gene Czarcinski > Sent: Sunday, October 14, 2012 1:45 AM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] It works: multiple dnsmasqs running > > On 10/13/2012 02:39 PM, Gene Czarcinski wrote: > > I still have the setting of IPV6_V6ONLY and I do not know if this is > > needed. I will try and run some tests without it and see if it still > > works. > Tested: not needed. > > Gene > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] Use IP family for initial setup logging
Hi, Initial setup logging is a bit inconsistent for DHCP/DHCPv6, Patch add actual IP family usage for stateless, static, proxy and range messages Before: dnsmasq-dhcp: IPv6 router advertisement enabled dnsmasq-dhcp: DHCP, IP range 192.168.10.101 -- 192.168.10.254, lease time 1d dnsmasq-dhcp: DHCP, IP range 2001:db8::1 -- 2001:db8::1255, lease time 1d dnsmasq-dhcp: stateless DHCPv6 on 2001:db8:: dnsmasq-dhcp: SLAAC on 2001:db8:: prefix valid 1d After: dnsmasq-dhcp: IPv6 router advertisement enabled dnsmasq-dhcp: DHCP, IP range 192.168.10.101 -- 192.168.10.254, lease time 1d dnsmasq-dhcp: DHCPv6, IP range 2001:db8::1 -- 2001:db8::1255, lease time 1d dnsmasq-dhcp: DHCPv6 stateless on 2001:db8:: dnsmasq-dhcp: SLAAC on 2001:db8:: prefix valid 1d Best Regards, Vladislav Grishenko Use-IP-family-for-initial-setup-logging.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] Avoid false netlink errors logging
Hi all, Commit 54dd393f [PATCH] Add --bind-dynamic introduced regression. Netlink errors with actual success status gets logged as errors. Patch fixes that by checking status, as it was before 54dd393f, could be applied to current git. Best Regards, Vladislav Grishenko Avoid-false-netlink-errors-logging.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] НА: dnsmasq 2.61 no periodic RA's and sendto errors
Jim, make sure you're using enable-ra in your config Best regards, Vladislav Grishenko - Reply message - От: "Jim Bos" Кому: "Simon Kelley" Копия: "Vladislav Grishenko" , Тема: dnsmasq 2.61 no periodic RA's and sendto errors Дата: вс, май 13, 2012 22:29 On 05/12/2012 04:34 PM, Simon Kelley wrote: > On 11/05/12 15:16, Vladislav Grishenko wrote: >> Hi Simon, >> >> dnsmasq 2.61 has couple of issues: >> 1. No Router Advertisement and corresponding syslog sendto error when >> replying on Router Solicitation from Windows XP and possible other OSes >> It's caused by absence of source IPv6 address in RS packet, what is >> allowed >> by RFC if host's interface doesn't acquired valid link-local yet >> In this case RA should be sent to all nodes multicast address (sources >> has >> ALL_HOSTS define, which has a bit different meaning) >> 2. For non-slaac modes periodic RA doesn't work because next RA event >> could >> be reset by empty next slaac event >> Actually it could work only for the first time, if additional random >> delay >> is 0. >> >> Patches attached. >> >> Best Regards, Vladislav Grishenko >> >> > > Many thanks. That solves the mystery of the sometime-missing periodic > RAs. I was aware that could sometime happen, but hadn't reproduced the > problem. > > I've put out 2.62test1 with these fixes in place. This probably needs > another release, but I'll leave it a week or two in case any other > regressions come to light in 2.61. > > Jim, I'm pretty sure this is the fix for you problem. > > Cheers, > > Simon. > I tried the patches already but unfortunately still don't get RA's. But note I'm using SLAAC-only and the patch seem to be for non-slaac cases. I'll see if I can try an almost empty config file on another PC to exclude any specific problem on my router. = Jim ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61 no periodic RA's and sendto errors
Thanks, Simon. Now, the only noticeable thing to go is configurable RA periodical interval values Rfc2461 introduces: MaxRtrAdvInterval: valid range [4 .. 1800], default 600 seconds MinRtrAdvInterval: valid range [3 .. 3/4 * MaxRtrAdvInterval], default 1/3 * MaxRtrAdvInterval AdvDefaultLifetime: valid range 0, [MaxRtrAdvInterval .. 9000], default 3 * MaxRtrAdvInterval So, probably enable-ra syntax needs to be expanded, something like enable-ra,[MaxRtrAdvInterval],[MinRtrAdvInterval],[AdvDefaultLifetime] If AdvDefaultLifetime and/or MinRtrAdvInterval are not specified - just calculate them from specified/default MaxRtrAdvInterval. This will make configuration more handy for sure. Best Regards, Vladislav Grishenko > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Saturday, May 12, 2012 8:35 PM > To: Vladislav Grishenko > Cc: dnsmasq-discuss@lists.thekelleys.org.uk; Jim Bos > Subject: Re: dnsmasq 2.61 no periodic RA's and sendto errors > > On 11/05/12 15:16, Vladislav Grishenko wrote: > > Hi Simon, > > > > dnsmasq 2.61 has couple of issues: > > 1. No Router Advertisement and corresponding syslog sendto error when > > replying on Router Solicitation from Windows XP and possible other > > OSes It's caused by absence of source IPv6 address in RS packet, what > > is allowed by RFC if host's interface doesn't acquired valid > > link-local yet In this case RA should be sent to all nodes multicast > > address (sources has ALL_HOSTS define, which has a bit different > > meaning) 2. For non-slaac modes periodic RA doesn't work because next > > RA event could be reset by empty next slaac event Actually it could > > work only for the first time, if additional random delay is 0. > > > > Patches attached. > > > > Best Regards, Vladislav Grishenko > > > > > > Many thanks. That solves the mystery of the sometime-missing periodic RAs. > I was aware that could sometime happen, but hadn't reproduced the > problem. > > I've put out 2.62test1 with these fixes in place. This probably needs another > release, but I'll leave it a week or two in case any other regressions come to > light in 2.61. > > Jim, I'm pretty sure this is the fix for you problem. > > Cheers, > > Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dnsmasq 2.61 no periodic RA's and sendto errors
Hi Simon, dnsmasq 2.61 has couple of issues: 1. No Router Advertisement and corresponding syslog sendto error when replying on Router Solicitation from Windows XP and possible other OSes It's caused by absence of source IPv6 address in RS packet, what is allowed by RFC if host's interface doesn't acquired valid link-local yet In this case RA should be sent to all nodes multicast address (sources has ALL_HOSTS define, which has a bit different meaning) 2. For non-slaac modes periodic RA doesn't work because next RA event could be reset by empty next slaac event Actually it could work only for the first time, if additional random delay is 0. Patches attached. Best Regards, Vladislav Grishenko 0001-fix-RA-sendto-error-in-case-of-answering-to-RS-witho.patch Description: Binary data 0002-cosmetics-use-ALL_NODES-as-defined-in-rfc4861.patch Description: Binary data 0003-fix-periodical-RA-for-all-non-slaac-only-cases.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
> From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Jan Seiffert > Sent: Monday, March 26, 2012 3:04 AM > To: dnsmasq discussion list > Subject: Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues > > 2012/3/25 Simon Kelley : > > On 25/03/12 14:21, Vladislav Grishenko wrote: > >>> From: Simon Kelley > [snip] > >>> The 6to4 case, maybe more useful. > >>> But is 6to4 going to be used much in the real world? > >> I'd say 6to4 is the only easy solution for end-users at the moment > >> whose ISP doesn't allow any IPv6. > >> If they uses some kind of CPE in router mode with dnsmasq on-board > >> and want to use IPv6 too, it makes sense. > >> Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6 > >> connectivity at all. > > > > That's true in most places. Very few UK ISPs offer IPv6. Most people I > > know what want it use a 6in4 tunnel via a tunnel broker. I'm using > > Sixxs and it works very well. 6to4 has a bad reputation, partly > > because it comes with asymmetric routing. > > > > I think most people will not get IPv6 until their ISP offers it. > > > > Don't forget 6RD. It's basically 6to4, but with another, ISP-specific, > IPv6 prefix. the ISP "Free" in France uses it to deploy IPv6 to all it's > customer > AFAIK. > The idea is that you don't need any new HW in the > backbone/BRAS/whatever, the ISP only deploys new firmware to it's CPEs (if > they already can talk 6to4, it's a 150 line change to allow arb. > prefixes, see http://patchwork.ozlabs.org/patch/34121/), and the > "asymmetric" 6to4 Routers are under the control (and SLAG and whatnot) of > the ISP, some extra boxes without ties to the other HW. Actually 6to4 is subset of 6RD with preset 2002:: prefix and 32bit of ipv4 address length. So, talking about 6to4 as more common solution with dynamic IPv4 , ISP's 6RD is assumed too. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
Sure, will look and update you ASAP Thanks Best Regards, Vladislav Grishenko > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Monday, March 26, 2012 1:58 AM > To: Vladislav Grishenko > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues > > > Please could you look at 2.61test8, in the usual places now? > > I wrote a long email detailing the various orthogonal config options and which > combinations were useful, which helped my thoughts enormously, but > probably didn't make things clear for anyone else. > > Note that I've not updated the man pages or examples yet, but here are > examples of all the things that might be useful. > > > Do DHCPv6 on subnets, do router advertisements on these subnets with M > and O bits set and A bit not set, so that no SLAAC addresses used. > enable-ra > dhcp-range=1234::100, 1234::200 > dhcp-range=2345::100, 2345::200 > > As above, but for this subnet, set A bit so clients use SLAAC addresses as well > dhcp-range=1234::100, 1234::200, slaac > > > Don't do DHCPv6 on subnet, only RA. M and O bits clear, A bit set dhcp- > range=1234::, ra-only > > As above, but also use DHCPv4-derived names for SLAAC addresses dhcp- > range=1234::, ra-names. > > > Do stateless DHCPv6 and RA on subnet. clear M bit, set O and A bits dhcp- > range=1234::, ra-stateless > > As above, but also use DHCPv4 derived names dhcp-range=1234::, ra- > stateless, ra-names > > It came together quite well, I think.. > > > Cheers, > > Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
> From: Simon Kelley > Sent: Sunday, March 25, 2012 7:48 PM > > 3.Periodic RA isn't working, because alarm code goes into (dhcp || > > dhcp6) path and don't trigger RA alarms > > This code does that, I think. > > #ifdef HAVE_DHCP6 > else if (daemon->ra_contexts) > /* Not doing DHCP, so no lease system, manage alarms for > ra > >>> only */ > send_alarm(periodic_ra(now), now); #endif > >>> > >>> Yes, but it "else" condition of (damon->dhcp || daemon->dhcp6). > >>> In my case and example, damon->dhcp is enabled, so periodic_ra will > >>> not be executed as expected several times while first minute. > >> > >> In the damon->dhcp || daemon->dhcp6 case, send_alarm is called from > >> lease_update_file, since the first event in the future might be a > >> lease > > expiry, > >> or it might be an RA multicast. > > > > Got it, unfortunately under some circumstances there'll be neither > > incoming router solicitations nor immediate dhcp leases expiration to > trigger RA. > > Example: big dhcpv4 leases ~ week to not stress network, dnsmasq > > restart due reboot/etc, clients connected via 3 network switches > > dnsmasq - [switch1] - [switch2] - [switch3] - IPV6 only clients. > > If switch 2 is temporary off, dnsmasq and clients see the links up and > > therefore take no action, so RA packets could be either not > > originated/ or just lost. > > That means RA timers should work independent to other dhcp/dhcp6 > > events, especially if the last ones are quite long. > > They do. Check the code at the end of lease_update_file() > > It find the shortest of > time to next RA > time to next ICMP6 for SLAAC-confirm > time to next lease expiry > LEASE_RETRY - if the leasefile write failed. > > and sets the alarm to the time to first event. > > > > > > Only other netlink/dhcpv4 events could trigger it. Also, even if > > fixed event logic leads to DHCP leases rewrite on every RA event > > by > >> design. > >> > >> It shouldn't. There'd a check in lease_update_file of the file_dirty flag. > > > > Yep, really. Thanks for pointing out. > > > >> The 6to4 case, maybe more useful. > >> But is 6to4 going to be used much in the real world? > > I'd say 6to4 is the only easy solution for end-users at the moment > > whose ISP doesn't allow any IPv6. > > If they uses some kind of CPE in router mode with dnsmasq on-board and > > want to use IPv6 too, it makes sense. > > Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6 > > connectivity at all. > > That's true in most places. Very few UK ISPs offer IPv6. Most people I know > what want it use a 6in4 tunnel via a tunnel broker. I'm using Sixxs and it works > very well. 6to4 has a bad reputation, partly because it comes with > asymmetric routing. > > I think most people will not get IPv6 until their ISP offers it. Asymmetric routing can't be treated as bad-only, it has dual effect that makes lower RTT also possible, comparing to 6in4/gogo6/etc tunnels per countries. I'd say it's geo-dependent. Anyway, 6to4 pro and cons discussing is out of the subject, the fact is it's still more than widely used and will be used tomorrow and even the day after tomorrow. Personally I can't force users avoid to use tunnels just because it's theoretically worse than native IPv6 connections, which are just not available. Not a perfect world, yeah. > > But, there's no other easy way to get runtime clients stats including > > expiration (actually, preferred remaining) time with HAVE_BROKEN_RTC. > > With udpcpd it can be done via dumpleases or just to read & parse > > udhcpd's lease file and I was hoping for the same approach for dnsmasq. > > Leases get read by request, so triggering actual lease file write > > isn't the problem (used signal), the problem is no expiration/remaining > time. > > Use a dhcp-script. That has the the information you need in the environment > variable DNSMASQ_TIME_REMAINING. > > If you don't want to store the data persistently, then send SIGHUP to > dnsmasq and it will call the script on all existing leases with an "old" > event. Thanks, that was the documented way, Script support gives +10Kb to dnsmasq size, corresponding script binding and asymmetric of per-lease recording add more complexity. So, I was thinking just about to add another one parameter to dnsmasq leases file with remaining time. Code is shared for RTC and BROKEN_RTC, costs almost nothing to size, and for second case it would fix lease prolongation issue as well. Of course, I can use it for my purposes only, just let you know about. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
> From: Simon Kelley > Sent: Sunday, March 25, 2012 6:17 PM > >>> 3.Periodic RA isn't working, because alarm code goes into (dhcp || > >>> dhcp6) path and don't trigger RA alarms > >> > >> This code does that, I think. > >> > >> #ifdef HAVE_DHCP6 > >> else if (daemon->ra_contexts) > >>/* Not doing DHCP, so no lease system, manage alarms for > >> ra > > only */ > >> send_alarm(periodic_ra(now), now); #endif > > > > Yes, but it "else" condition of (damon->dhcp || daemon->dhcp6). > > In my case and example, damon->dhcp is enabled, so periodic_ra will > > not be executed as expected several times while first minute. > > In the damon->dhcp || daemon->dhcp6 case, send_alarm is called from > lease_update_file, since the first event in the future might be a lease expiry, > or it might be an RA multicast. Got it, unfortunately under some circumstances there'll be neither incoming router solicitations nor immediate dhcp leases expiration to trigger RA. Example: big dhcpv4 leases ~ week to not stress network, dnsmasq restart due reboot/etc, clients connected via 3 network switches dnsmasq - [switch1] - [switch2] - [switch3] - IPV6 only clients. If switch 2 is temporary off, dnsmasq and clients see the links up and therefore take no action, so RA packets could be either not originated/ or just lost. That means RA timers should work independent to other dhcp/dhcp6 events, especially if the last ones are quite long. > >>> Only other netlink/dhcpv4 events could trigger it. Also, even if > >>> fixed event logic leads to DHCP leases rewrite on every RA event by > design. > > It shouldn't. There'd a check in lease_update_file of the file_dirty flag. Yep, really. Thanks for pointing out. > The 6to4 case, maybe more useful. > But is 6to4 going to be used much in the real world? I'd say 6to4 is the only easy solution for end-users at the moment whose ISP doesn't allow any IPv6. If they uses some kind of CPE in router mode with dnsmasq on-board and want to use IPv6 too, it makes sense. Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6 connectivity at all. > > Don't you find this trade-off between totally inaccurate lease time > > and almost accurate with expections - as acceptable? > > Yes. It would be unacceptable if the leases turned out shorter than > promised, but this can only make the leases longer. When a client gets a > lease, it gets a promise that the address ins available for x hours. > Increasing the time before the lease expires can only be a problem if there's > a shortage of addresses, so that addresses cannot be reused. In most cases, > the DHCP server will be up much longer than the lease time, so the effect is > small. If the DHCP server goes down often, the solution is to reduce the lease > time. Reducing the frequency of writes to flash is important. Ok, that's true, it doesn't harm. But, there's no other easy way to get runtime clients stats including expiration (actually, preferred remaining) time with HAVE_BROKEN_RTC. With udpcpd it can be done via dumpleases or just to read & parse udhcpd's lease file and I was hoping for the same approach for dnsmasq. Leases get read by request, so triggering actual lease file write isn't the problem (used signal), the problem is no expiration/remaining time. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
> From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Saturday, March 24, 2012 8:31 PM > > On 23/03/12 22:36, Vladislav Grishenko wrote: > > > > Usually it's done by specifying Other bit in RA, while Managed is > > switched off. This allows host to configure address from the prefix, > > but ask DNS, Domain, etc via DHCPv6. > > > > Thanks for your issues list below: I'll go through them in the next day or two, > but I can already see that 4) at least is a real bug. > > It's worth saying that the RA support in dnsmasq is _not_ meant to be a > complete implementation. It started as an easy way to do the minimum > required to be able to to DHCP, and has expanded a bit since then, but for a > completely flexible RA implementation, it's intended that radv or similar will > be used. > > Also, IPv6 is quite new to most people, me included, and so we're still > learning what actual features will be used in practice. This is not really known > yet by anyone (see the IETF homenet working group for details). I don't want > to implement the whole of every possible facility that's been defined by the > rampant second system effect. that would bloat dnsmasq to much and it's > supposed to be small. More than agree, I respect your position and thanks for the effort. But, it was quite expected that RA support improvement is about to be asked just because it exists already in sub-minimal form, So, just a matter of time, I guess. > That said, I think SLAAC+stateless DHCPv6 is a mode I want to support, and it > isn't supported at the moment, you're right. Ok, this solution is quite common until all possible clients/hosts are dhcpv6-statful-aware. > > Unfortunately, this config is quite impossible now, refer issues list: > > > > 1.M+O bits are set if dhcv6 enabled only, and no bits set, if disabled. > > That means bits is always cleared with ra-only/ra-names, no matter set > > dhcp6 options or not. > > > > 2.Dhcp6 options without range will not create contexts, therefore > > dnsmasq doesn't listen dhcp6 requests. So, without this pt.1 > > enhancement is pointless. > > > > A way to do this is is have a "real" dhcp range, as well as the ra-only one. The > will solve at least some of these problems. The M+O bits will both be set, but > DHCPv6 requests for stateless options will be honoured. You mean different prefixes? Hosts should ignore RA prefix if there's managed bit set. > There's no way to set only the O bit, I'll think about how to do that. Probably, ra-only/ra-names syntax can could be replaced with slaac/dhcp6-stateless/dhcp-statefull form.. Can't say about the best solution which natively fits conf syntax. > > 3.Periodic RA isn't working, because alarm code goes into (dhcp || > > dhcp6) path and don't trigger RA alarms > > This code does that, I think. > > #ifdef HAVE_DHCP6 > else if (daemon->ra_contexts) >/* Not doing DHCP, so no lease system, manage alarms for ra only */ > send_alarm(periodic_ra(now), now); #endif Yes, but it "else" condition of (damon->dhcp || daemon->dhcp6). In my case and example, damon->dhcp is enabled, so periodic_ra will not be executed as expected several times while first minute. > > Only other netlink/dhcpv4 events could trigger it. Also, even if fixed > > event logic leads to DHCP leases rewrite on every RA event by design. > > I'm not sure I follow that. How? In ra_init first next event(s) are set to now or a bit ahead of ra_time. At the dhcp/netlink alarm moment they could be in the past and therefore just executed without any new ra alarm rearm. This causes only post-check of ra conext timers. > > About prefix lifetimes, you refer rfc2462 in the code which is > > obsoleted by rfc4862. > > 2 hours rules is only about Valid Lifetime, but Preferred Lifetime > > might be and usually is much smaller in dynamic v6 prefix environments. > > The problem is dnsmasq doesn't use separate valid/preferred values, > > this leads to default gateway lost issue due some "server" > > reconfiguration when client still threat 2h prefix is valid and preferred. > > This is a bigger problem: how to support hitless network re-numbering. > I'll tackle it if it becomes clear that it's actually needed for the sort of > applications dnsmasq gets used for. At the moment it's not clear it will be. I can say that dnsmasq is widely used in embedded CPEs with wide range of IPv6 upstream types. Two cases really require the inner network renumbering
[Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
Hi Simon, Latets git (2.61test7) brings several RA issues, My configuration (simplified): HAVE_DHCP, HAVE_DHCPv6, HAVE_BROKEN_RTC interface=br0 dhcp-range=192.168.1.101,192.168.1.254,86400 dhcp-range=2001:470::::,ra-only,64,2h dhcp-option=option6:23,[::] I was trying to setup dual-stack environment with IPv6 SLAAC and DNS via DHCPv6 Usually it's done by specifying Other bit in RA, while Managed is switched off. This allows host to configure address from the prefix, but ask DNS, Domain, etc via DHCPv6. Unfortunately, this config is quite impossible now, refer issues list: 1. M+O bits are set if dhcv6 enabled only, and no bits set, if disabled. That means bits is always cleared with ra-only/ra-names, no matter set dhcp6 options or not. 2. Dhcp6 options without range will not create contexts, therefore dnsmasq doesn't listen dhcp6 requests. So, without this pt.1 enhancement is pointless. 3. Periodic RA isn't working, because alarm code goes into (dhcp || dhcp6) path and don't trigger RA alarms Only other netlink/dhcpv4 events could trigger it. Also, even if fixed event logic leads to DHCP leases rewrite on every RA event by design. 4. Router Solicitation messages doesn't trigger send RA, due 2 reasons: icmp6fd isn't in read fdset , and icmp6fd socket isn't joined to ALL_ROUTERS group. All this because there's no dhcp6 context configured for ra-only/ra-names About prefix lifetimes, you refer rfc2462 in the code which is obsoleted by rfc4862. 2 hours rules is only about Valid Lifetime, but Preferred Lifetime might be and usually is much smaller in dynamic v6 prefix environments. The problem is dnsmasq doesn't use separate valid/preferred values, this leads to default gateway lost issue due some "server" reconfiguration when client still threat 2h prefix is valid and preferred. Not related to subject, but have to say. With HAVE_BROKEN_RTC lease file doesn't contain expire time, but length, which is constant. So, after restart/reload all leases get prolonged lease time, and possibly never expired then. Solution is quite simple - store not only lease length, but calculated remaining time too. With this values it's possible to correct count all previous timings. Best Regards, Vladislav Grishenko ICQ: 303357 MSN: themi...@mail.ru Skype: the.miron ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Cunning plan, or hideous hack?
Oh yes, misread, sorry. > There are a lot of clients in the world now (eg all > Android phones, at least per-ICS) which don't use privacy extensions and > can't do DHCPv6 or don't do it by default. This hack is useful for those. Got it, afaik Android devices, in general, use Android_%15d as dhcp name template, and most of them don't allow to configure it. Privacy-enabled SLAAC hosts (all Windows from XP uses that by default) either will use DHCPv6 or will jammed. This means, if enabled, ra-dhcpv4-name hack will be useful in rare cases and unreliable in common. Best Regards, Vladislav Grishenko > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Thursday, March 08, 2012 8:47 PM > To: Vladislav Grishenko > Cc: Dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Cunning plan, or hideous hack? > > On 08/03/12 13:52, Vladislav Grishenko wrote: > > Hi Simon, > > With enabled IPv6 privacy extensions, the OS generates address by > > combining advertised prefix and random host id, definitely not MAC- > derived. > > So, there's no any way to know host address, even if a "server" knows > > prefix and client's MAC, and any attempts to do this is a kind of > > hack, which is not supposed to work. > > That's true, and I think I said so in my original mail. The only client on my > wireless network at the moment which uses privacy extensions by default is > my daughter's Win 7 Laptop. That can be configured to use > DHCPv6 if necessary. There are a lot of clients in the world now (eg all > Android phones, at least per-ICS) which don't use privacy extensions and > can't do DHCPv6 or don't do it by default. This hack is useful for those. > > Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Cunning plan, or hideous hack?
Hi Simon, With enabled IPv6 privacy extensions, the OS generates address by combining advertised prefix and random host id, definitely not MAC-derived. So, there's no any way to know host address, even if a "server" knows prefix and client's MAC, and any attempts to do this is a kind of hack, which is not supposed to work. Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Thursday, March 08, 2012 5:09 PM > To: Dnsmasq-discuss@lists.thekelleys.org.uk > Subject: [Dnsmasq-discuss] Cunning plan, or hideous hack? > > As part the DHCPv6 work, I've fully enabled my home network for IPv6. > The workstation machines on my wired subnet are now running DHCPv6 and > get leases from dnsmasq. Their IPv6 addresses are now in the local DNS in > just the same way as has always worked with DHCPv4 DNS and DHCP. > > I also have a wireless network, and on that I've not enabled DHCPv6, just > Router Advertisements, via the "ra-only" keyword. Hence, clients on that > network get a SLAAC, MAC-derived IPv6 address which is not in the DNS. > > Since all these clients are dual-stack or IPv4-only, they do get DHCPv4 leases > and names in the IPv4-DNS. > > It occurs to me that dnsmasq has all the information it needs to put the > SLAAC addresses into the DNS. From the IPv4 DHCP lease it knows the name > of the client, which network segment it's on and it's MAC address. The "ra- > only" DHCP ranges tell dnsmasq the IPv6 subnet(s) corresponding to the > network segment, so combining this with the MAC address gives the SLAAC > address, ready to put into the DNS as an record along with the name. > > I've implemented this, and it works well: my Ubuntu netbook and Android > phone now have IPv6 names. (Andoid 2 has no DHCPv6 support.) > > The downside is for clients which don't do IPv6 at all, or use privacy > extensions. They end up with records pointing to the SLAAC address, > which is wrong and could end-up delaying fall-back to IPv4. This has not yet > been a problem in practise. > > I don't want to enable this by default, so I've added a new keyword, "ra- > names" to enable RA on a subnet plus the SLAAC names hack, thus > > --dhcp-range=1234::1, ra-names > > Is this a good idea, or am I blinded by my own idea into implementing a nasty > hack? Opinions? > > Cheers, > > Simon. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcpv6 duid gen
> On 01/03/12 11:40, Vladislav Grishenko wrote: > >> I wonder if the solution might be to just have a duid-override > >> =, configuration which suppresses > >> storing anything in the lease file and > > just > >> uses a type-2 DUID in the obvious way? > > > > Ok, and it can be even more easy - allow specify u_int64_t value and > > use it with DUID-LL+27 ether type (eui64). > > duid-override= > > > >> configuration which suppresses storing anything in the lease file > >> and > > just > >> uses a type-2 DUID in the obvious way? > > Storing is allowed, but until reboot... > > But then what do you do when the configred DUID conficts with the stored > one? Configured overrides stored, if you mean one stored in leases file. It's quite expected, I guess > > And what about traversing over ethernet-like interfaces only? > > Actually, for me, it would be more handy than to implement own duid > > generation and storing it in conf. > > The root issue was in sit (6to4 tunnels) interfaces, which has no > > hwaddr to be used as duid ll source. > > I think the solution to that is to ignore interfaces with HW address type >= > 256. See /include/linux/if_arp.h for details. > > OK? Should be ok, depite too small hwaddr length of some protos, like ARCNET, LTALK ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcpv6 duid gen
> I wonder if the solution might be to just have a > duid-override = , > configuration which suppresses storing anything in the lease file and just > uses a type-2 DUID in the obvious way? Ok, and it can be even more easy - allow specify u_int64_t value and use it with DUID-LL+27 ether type (eui64). duid-override= > configuration which suppresses storing anything in the lease file and just > uses a type-2 DUID in the obvious way? Storing is allowed, but until reboot... And what about traversing over ethernet-like interfaces only? Actually, for me, it would be more handy than to implement own duid generation and storing it in conf. The root issue was in sit (6to4 tunnels) interfaces, which has no hwaddr to be used as duid ll source. Best Regards, Vladislav Grishenko > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Thursday, March 01, 2012 5:16 PM > To: Vladislav Grishenko > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: dhcpv6 duid gen > > On 29/02/12 23:26, Vladislav Grishenko wrote: > > Little additions: > > > >> Allowing to specify from options would be useful too, eg. for > >> multiple dnsmasq instances > > > > Per RFC3315 "A DHCP client that generates a DUID-LLT using this (using > > sort >^^^ > > > of time source) mechanism MUST provide an administrative interface > > that replaces the existing DUID with a newly-generated DUID-LLT." > > > > > > >> Hmm, I wonder if > >> "stop dnsmasq, edit /var/lib/misc/dnsmasq.leases, start dnsmasq" > >> counts as an administrative interface? > > > sure doesn't. in embedded there's no persistent storage for such > files > other than /tmp, so under some circumstances file can be lost > > (reboot, > fast reinit, etc). > > due hashing, there's a kind of guarantee that dhcpv4 client will get > his > leases back, but not for dhcpv6 guid. > > > I wonder if the solution might be to just have a > > duid-override = , > > configuration which suppresses storing anything in the lease file and just > uses a type-2 DUID in the obvious way? > > Cheers, > > Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcpv6 duid gen
> Hmm, I wonder if > "stop dnsmasq, edit /var/lib/misc/dnsmasq.leases, start dnsmasq" > counts as an administrative interface? sure doesn't. in embedded there's no persistent storage for such files other than /tmp, so under some circumstances file can be lost (reboot, fast reinit, etc). due hashing, there's a kind of guarantee that dhcpv4 client will get his leases back, but not for dhcpv6 guid. > I'm sure that an implementation of RECONFIGURE will be done, but not for > this release: I want to get the basics working first. np, just fyi Best Regards, Vladislav Grishenko > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Thursday, March 01, 2012 4:03 PM > To: Vladislav Grishenko > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: dhcpv6 duid gen > > On 29/02/12 23:26, Vladislav Grishenko wrote: > > Little additions: > > > >> Allowing to specify from options would be useful too, eg. for > >> multiple dnsmasq instances > > > > Per RFC3315 "A DHCP client that generates a DUID-LLT using this (using > > sort of time source) mechanism MUST provide an administrative > > interface that replaces the existing DUID with a newly-generated DUID- > LLT." > > Hmm, I wonder if > > "stop dnsmasq, edit /var/lib/misc/dnsmasq.leases, start dnsmasq" > > counts as an administrative interface? > > > >> This leads to a much more longer client renew, possibly authoritative > > option > >> could be used to avoid it, can't say now is it per RFC. > > > > Not allowed for server, but RECONFIGURE implementation could be handy, > > including cases of changing options. > > I'm sure that an implementation of RECONFIGURE will be done, but not for > this release: I want to get the basics working first. > > > > Cheers, > > Simon. > > > > > Best Regards, Vladislav Grishenko > > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcpv6 duid gen
Little additions: > Allowing to specify from options would be useful too, eg. for multiple > dnsmasq instances Per RFC3315 "A DHCP client that generates a DUID-LLT using this (using sort of time source) mechanism MUST provide an administrative interface that replaces the existing DUID with a newly-generated DUID-LLT." > This leads to a much more longer client renew, possibly authoritative option > could be used to avoid it, can't say now is it per RFC. Not allowed for server, but RECONFIGURE implementation could be handy, including cases of changing options. Best Regards, Vladislav Grishenko > -Original Message----- > From: Vladislav Grishenko [mailto:themi...@mail.ru] > Sent: Thursday, March 01, 2012 5:07 AM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Cc: Simon Kelley (si...@thekelleys.org.uk) > Subject: dhcpv6 duid gen > > Hi, Simon > > Currenly 2.60 uses first interface and its hw type as (time) link-layer duid > source with exceptions of loopback and ppp. > RFC3315 says "The hardware type MUST be a valid hardware type assigned > by the IANA, as described in RFC 826", which describes only 48bit-long > ethernet addresses. > So, if there's any kind non-ethernet interfaces in system, which has first > index, dnsmasq duid generation is obviously wrong. > Example - 6to4 tunnel interfaces > sit0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-4D-62-00-00-00-00-00- > 00-00-00 > NOARP MTU:1480 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) So, instead of checking device flags, > it's better to check against encap type and allow only ether&ieee802, like > dhcp6s/wide-dhcpv6 do. > Allowing to specify from options would be useful too, eg. for multiple > dnsmasq instances, > > Also, HAVE_BROKEN_RTC has issue, duid length and allocation should be > equal to maclen+4, not maclen+8, because time bits are not used. > Seems it's not a good idea to use LLT duid type now even with RTC machines, > because if lease file is lost and dnsmasq restarted, it will get new duid and will > ignore any renew requests completely. > This leads to a much more longer client renew, possibly authoritative option > could be used to avoid it, can't say now is it per RFC. > > Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dhcpv6 duid gen
Hi, Simon Currenly 2.60 uses first interface and its hw type as (time) link-layer duid source with exceptions of loopback and ppp. RFC3315 says "The hardware type MUST be a valid hardware type assigned by the IANA, as described in RFC 826", which describes only 48bit-long ethernet addresses. So, if there's any kind non-ethernet interfaces in system, which has first index, dnsmasq duid generation is obviously wrong. Example - 6to4 tunnel interfaces sit0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-4D-62-00-00-00-00-00-00-00-00 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) So, instead of checking device flags, it's better to check against encap type and allow only ether&ieee802, like dhcp6s/wide-dhcpv6 do. Allowing to specify from options would be useful too, eg. for multiple dnsmasq instances, Also, HAVE_BROKEN_RTC has issue, duid length and allocation should be equal to maclen+4, not maclen+8, because time bits are not used. Seems it's not a good idea to use LLT duid type now even with RTC machines, because if lease file is lost and dnsmasq restarted, it will get new duid and will ignore any renew requests completely. This leads to a much more longer client renew, possibly authoritative option could be used to avoid it, can't say now is it per RFC. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] 2.60rc2
Sorry, really missed it. Thanks Best Regards, Vladislav Grishenko > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Thursday, March 01, 2012 3:49 AM > To: Vladislav Grishenko > Cc: 'dnsmasq discussion list' > Subject: Re: [Dnsmasq-discuss] 2.60rc2 > > On 29/02/12 21:30, Vladislav Grishenko wrote: > > Doesn't build with HAVE_BROKEN_RTC > > Trivial fix attached > > Many Thanks. You missed rc3 by one minute, so there's now > > http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq- > 2.60rc4.tar.gz > > which has this fix, and an adjustment to the nasty Makefile-portability hack > to make it work with GNU-make 3.82. That should fix the Gentoo problems. > > > Cheers, > > Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] 2.60rc2
Doesn't build with HAVE_BROKEN_RTC Trivial fix attached Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Thursday, March 01, 2012 2:30 AM > To: dnsmasq discussion list > Subject: [Dnsmasq-discuss] 2.60rc2 > > A fruitful day moving towards a release. This addresses: > > * Makefile problems on Gentoo. Preston, I'd be especially grateful if you > could see if this works better. > > * Documentation improvements for RA. > > * Substitute local address for [::] DHCPv6 options, like DHCPv4. > > * Lorenzo and John's --localise-queries bug. > > http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq- > 2.60rc2.tar.gz > > > > > Cheers, > > Simon. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss 0001-Fix-HAVE_BROKEN_RTC-build.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Announce: release candidate dnsmasq-2.60rc1
Same hit here, but due TOP variable is already exported from up-level Makefile I have source tree with packages and one general Makefile: src/dnsmasq/... src/Makefile export TOP := $(shell pwd) dnsmasq: $(MAKE) -C $@ So, had to change it to $(MAKE) -C $@ TOP="$(TOP)/$@". p.s Debian, GNU Make 3.81 Best Regards, Vladislav Grishenko > -Original Message- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Wednesday, February 29, 2012 1:59 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Announce: release candidate dnsmasq- > 2.60rc1 > > On 29/02/12 03:18, Preston Crow wrote: > > I hit a Makefile issue (that wasn't there in dnsmasq-2.60test10): > > > > # pmake way to learn path of Makefile > > TOP != echo `pwd`/ > > # GNU make way to learn path of Makefile TOP ?= $(shell pwd) > > > > This leads to: > > > > Makefile:38: *** missing separator. Stop. > > > > Apparently it doesn't like the first TOP line. > > > > I might be building it wrong. I'm using Gentoo Linux, and I copied and > > tweaked the ebuild that I used for test10, which was copied and > > tweaked from the ebuild for the previous release. > > > > Sigh. Writing portable makefiles is a thankless task. I tested this on Gnu-make > and BSD make. What flavour/version on make are you using. > > Related question: BSD people. Would you care if I gave up the fight and > required GNU-make to build dnsmasq? > > Cheers, > > Simon. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dhcpv6 @ rc1
Hi, Simon In latest 60rc1, it seems need to use enable-ra along with dhcp-range=ipv6,ipv6,. Without it default link local gateway can't be assigned to clients, because it's always done via RA. About dhcp-range, prefix6::, ra-only syntax, According sources, preffered and valid lifetime can be set with ra-only token, but not mentioned in sample conf, a bit confusing Next thing is dnsv6 option, it works a bit abnormally (comparing with v4) Suppose we need to assign several dns servers, where one is dnsmasq itself. With dhcpv4 it could be done with dhcp-option=44,dns1,0.0.0.0 But following for dhcpv6 passes [::] in reply message, instead of interface global/link local address dhcp-option=option6,dns-server,[dns1],[dns2],[::] As for dnsv6 without dhcpv6, list can be passed via RA RDNSS option, see RFC 6106. Windows clients don't support it, and, according technet, will never do. However, there's 3rd party win32 daemons, which can be used, like rdnssd-win32 *nix also has support in 3rd party standalone daemons. Best Regards, Vladislav Grishenko ICQ: 303357 MSN: themi...@mail.ru Skype: the.miron ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
