On 07/12/15 04:39, Shane Manjarres wrote:
> Looking at the build options listed in /src/config.h it states the
> following:
>
> *The default set of options to build*
>
> HAVE_DHCP
> HAVE_DHCP6
> HAVE_TFTP
> HAVE_SCRIPT
> HAVE_AUTH
> HAVE_IPSET
> HAVE_LOOP
>
> *In the same config.h file is
On 20/10/15 21:35, Simon Kelley wrote:
> To add to the list of canonical uses for dnsmasq: DHCP and DNS services
> to VMs and containers in things like OpenStack. These typically use
> RFC1918 addresses (there's no point in being able to spin a new VM in
> seconds if you have to go buy it a real
From abe37dd25e466f813b4bc5864c1bd7ad676ba6c8 Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
Date: Mon, 19 Oct 2015 13:27:15 +0100
Subject: [PATCH] Update ipv4 bogus-priv to RFC6303 zones
RFC6303 specifies & recommends following zones not be forwarded
to g
Hi Simon & list,
Ok, here's the controversial idea. Can we consider enabling
'bogus-priv' by default and have an additional option say 'allow-priv'
to now disable?
My feeling is that not forwarding 'link-local' type requests upstream by
default is a cleaner way of having things configured.
On 16/09/15 15:48, Nickolai Dobrynin wrote:
> Hello world!
>
> I can't get IPv6 working with dnsmasq. My ISP supports IPv6 "natively",
> but when I run 'ping6 -c 1 google.com' on a client, I get "Network
> unreachable".
> When I ping a host that's IPv4-only, the message becomes "unknown host".
Hi All,
dnsmasq 2.75
Putting 'dhcp-option=ntp-server,0.0.0.0' in dnsmasq.conf is throwing an
error "bad dhcp-option at line 73 of /etc/dnsmasq.conf" Replacing it
with 'dhcp-option=42,0.0.0.0' allows dnsmasq to start and behave
properly. I've noticed similar behaviour with 'netbios-ns' (option
Hi All,
I've been looking at providing NTP server addresses to my DHCPv6 clients
using dnsmasq. 2 RFCs seem applicable, Simple NTP provision RFC4075
defines option 31 and known to dnsmasq as 'sntp-server'. RFC5908
defines a more flexible/complicated provision mechanism using option 56,
known to
On 10/09/15 22:13, Simon Kelley wrote:
> On 10/09/15 10:39, Kevin Darbyshire-Bryant wrote:
>> Hi All,
>>
>> dnsmasq 2.75
>>
>> Putting 'dhcp-option=ntp-server,0.0.0.0' in dnsmasq.conf is throwing an
>> error "bad dhcp-option at line 73 of /etc/dnsm
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:
plementation 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
On 07/05/2015 13:54, Simon Kelley wrote:
On 07/05/15 10:41, Toke Høiland-Jørgensen wrote:
Simon Kelley si...@thekelleys.org.uk writes:
It's difficult to see how that would work in practise for DNS. Take
the Google-public-DNS example. It's clearly not sane for Google's
servers to do PMTU on
Continues to work here on my iPhone hiding behind openwrt cc trunk
dnsmasq2.73rc7
Were I not on the iPhone I could do some dig'age :-)
--
Cheers,
ke...@darbyshire-bryant.me.uk
Sent from my phone, apologies for brevity, spelling top posting
On 6 May 2015, at 20:21, Dave Taht
Chaps,
If I may interject:
On 02/04/2015 22:21, Dave Taht wrote:
On Thu, Apr 2, 2015 at 1:20 PM, Simon Kelley si...@thekelleys.org.uk wrote:
On 02/04/15 19:41, Dave Taht wrote:
A) Not clear what happens if it tries to write it while the jffs
filesystem is still being cleaned
Not sure I
On 25/02/2015 09:14, Gavin Hill wrote:
As a quick update, I tried changing
dhcp-range=192.168.1.1,192.168.1.99,static,48h
to
dhcp-range=192.168.1.1,192.168.1.99,static,infinite
Things slowed down a little and I’m seeing fewer log entries, but it
still doesn’t explain why the 48h entry
On 14 Feb 2015, at 14:47, Simon Kelley si...@thekelleys.org.uk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/02/15 12:01, Kevin Darbyshire-Bryant wrote:
The principle I agree with. I'm wondering about the mechanics of
accessing this NVRAM 'last good time
On 11 Feb 2015, at 22:02, Simon Kelley si...@thekelleys.org.uk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/02/15 18:28, Kevin Darbyshire-Bryant wrote:
On 09/02/2015 16:02, Simon Kelley wrote:
On 09/02/15 13:21, Kevin Darbyshire-Bryant wrote:
Further to my
On 09/02/2015 16:02, Simon Kelley wrote:
On 09/02/15 13:21, Kevin Darbyshire-Bryant wrote:
Further to my previous email I've cobbled something together, and
it even appears to work. There's quite a bit of coding guesswork
going on here and I really shouldn't be let anywhere near a C
Sorry, I told you I shouldn't be let anywhere near a C compiler. Here's
a patch that actually works! (previously missing a return in dnssec.c)
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 40323ed..1687305 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -239,7 +239,8 @@ struct event_desc {
Hi Simon,
I've no idea how to go about coding this but I've an idea/requirement
for something along these lines. It's similar to 'dnssec-no-timecheck'
chicken egg but a bit more automated.
1) Set a 'check signature time' flag as false.
2) If flag is false, then check the current time of day.
On 22/01/2015 09:09, Kevin Darbyshire-Bryant wrote:
In addition: include the inotify build status as part of the version
string:
diff --git a/src/config.h b/src/config.h
index cdca231..eaa0423 100644
--- a/src/config.h
+++ b/src/config.h
@@ -425,6 +425,10 @@ static char *compile_opts
On 23/01/2015 14:07, Simon Kelley wrote:
Yes, that's fine. It'll be a couple of days before I have time to do
the work.
Cheers,
Simon.
On 22/01/15 09:09, Kevin Darbyshire-Bryant wrote:
Hi Simon
I'm wondering if you'd consider putting the new 'inotify' related
code as a compile time
Hi Simon
I'm wondering if you'd consider putting the new 'inotify' related code
as a compile time option please. Unfortunately there are a few router
based projects that rely on old kernels without inotify support. I've
included a patch that I've hopefully generated coded correctly that
wraps
On 25/04/2014 09:37, David Joslin wrote:
Hi Kevin and thanks for the help.
Apologies for delay in reply.
Is it possible to upgrade the dnsmasq version on the router without
waiting for the author of the tomato firmware to include a later
version in a release of his firmware (and you mentioned
On 21/01/2014 10:40, Martin Babutzka wrote:
Hello,
We are using this great piece of software so far as DNS cacher but
want to implement it also as IPv6 server by now. DHCPv4 is handled by
another software at the moment (isc-dhcp-server) but we think the
dnsmasq 2.62-3 is quite suitable for
Hi Simon,
I think there's a bug in the quiet-dhcp option. In essence no dhcpv4 logging
is performed unless the log option is also enabled. I think the code should be:
diff --git a/src/rfc2131.c b/src/rfc2131.c
index 0ee7c90..dd67509 100644
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@
On 08/10/2013 12:09, Vladislav Grishenko wrote:
snip
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
On 08/10/2013 11:42, Simon Kelley wrote:
This is definitely a bug.
Sorry Simon!
Historically, the prefix-length in the dhcp-range has had to match the
prefix length configured into the interface. This was carried over
from DHCPv4. If, as an experiment, you stop using constructed ranges
and
On 05/10/2013 22:43, Quintus wrote:
Am Sat, 5 Oct 2013 14:21:26 +0100
schrieb Kevin Darbyshire-Bryant ke...@darbyshire-bryant.me.uk:
Hi All,
Hi Kevin,
dnsmasq2.67rc3 - possibly odd behaviour, probably I misunderstand :-)
I have an interface that has a /64 on it. dnsmasq.conf has amongst
Hi All,
dnsmasq2.67rc3 - possibly odd behaviour, probably I misunderstand :-)
I have an interface that has a /64 on it. dnsmasq.conf has amongst
other things
dhcp-range=::100, ::F::, constructor:br0, ra-names, 64, 12h
enable-ra
This picks up the /64 prefix, allocates a DHCPv6 range
On 22/05/2013 22:43, Moritz Warning wrote:
Sorry for the delay - life is busy. :)
Actually the ip address of br-private is of type prefix::1
root@OpenWrt:~# ip -6 address show dev br-private
8: br-private: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500
inet6 fdef:17a0:ffb1:1::1/64 scope
Sorry top posted I know. However constructor options requires interface to have
host address match the start point of your constructor option before it will
pick up the prefix.
So BR-private must have address prefix::1 so it matches the constructor
range.
Hope that helps
Kevin
--
Cheers,
On 02/05/2013 17:54, Kevin Darbyshire-Bryant wrote:
Suggest an alternative, given that constructing a DHCP range based on
any address in a prefix is not desirable.
H, what about seeing if the interface in question has an address
inside the DHCP constructed range and if it does then use
On 02/05/2013 09:36, Simon Kelley wrote:
On 01/05/13 16:26, Kevin Darbyshire-Bryant wrote:
Hi Simon,
I find myself confused by the use of the constructor option for building
DHCPv6 address ranges.
edited dnsmasq.conf file:
enable-ra
dhcp-range=tag:br0,::1, ::, constructor:br0, ra
On 02/05/2013 13:02, Kevin Darbyshire-Bryant wrote:
Specifying the router's LAN IPv6 address as the start of the range was
not how I anticipated this option to work. And I don't think you do
either based upon your above description. So is this an oversight or
some tomato based wierdness
On 02/05/2013 13:09, Kevin Darbyshire-Bryant wrote:
Ahhh! Right, a clue: Changing
enable-ra
dhcp-range=tag:br0,::100, :::::, constructor:br0,
ra-names, 12h
to
enable-ra
dhcp-range=::100, :::::, constructor:br0, ra-names, 12h
makes it work as expected
On 02/05/2013 17:00, Simon Kelley wrote:
It is how I expected it to work, exactly.
DHCP-PD client gets prefix, and assigns prefix::1 to LAN interface.
dnsmasq gives addresses between
prefix::2 and prefix::whateveryouwant
to clients on the LAN.
Which (contrived case) isn't ideal if for
Does anyone else see Apple iDevices making lots of repeated DHCP renewal
requests in their dnsmasq log files?
Kevin
smime.p7s
Description: S/MIME Cryptographic Signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
snip
Ahh, but there's the rub, the first instance of dhcp-option=br0,...
is generated automatically by the router software and cannot be changed,
it's why we need to be able to override it.
Ok. will have to think harder about this, in that case.
Sorry!
But I'm now concerned about your
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
On 27/03/2013 17:40, Kevin Darbyshire-Bryant wrote:
Hi Simon,
snip
Right, now that I've had the problem further clarified to me, here's the
real issue.
In essence, dnsmasq when parsing options uses the values from the first
instance of a parameter and not (as before) the last.
Bug? Feature
On 21/03/2013 10:08, Simon Kelley wrote:
snip
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
On 10/02/2013 15:49, Vladislav Grishenko wrote:
Hi, Kevin
probably it's because while dnsmasq upgrading, tomato-specific patches
were rollbacked/missed, one of them includes custom lease expiration
time. if you're interested, take a look at dnsmasq changes in recent
asuswrt fws. thay have
101 - 142 of 142 matches
Mail list logo
