The idea of this option was already discussed years ago on the mailing
list:
https://dnsmasq-discuss.thekelleys.org.narkive.com/ZoFQNaGo/always-ignore-client-identifier#post4
In our production environnement, we discovered that some devices are
using 'client identifier' not unique at all, resulting on IP addresses
conflicts between several devices (we saw up to four devices using same
IP address).
The root cause is probably a buggy operating system/configuration of
decices, but this patch add a configuration workaround on server side
when fixing clients is impossible.
Signed-off-by: Charles Daymand <charles.daymand@wifirst.fr>
Signed-off-by: Florent Fourcot <florent.fourcot@wifirst.fr>
If the cache size is very large, the malloc() call will overflow
on 32 bit platforms and dnsmasq will crash. Limit to an order of
magnitude less.
Thanks to Lili Xu for spotting this.
Hi Simon,
master has a build error when building without HAVE_DHCPv6
option.c: In function 'dhcp_context_free':
option.c:1042:15: error: 'struct dhcp_context' has no member named 'template_interface'
free(ctx->template_interface);
Sadly, need to put in a little conditional compilation ifdef'erey
Simplest patch in the world attached
Cheers,
Kevin D-B
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
From 061eb8599636bb360e0b7fa5986935b86db39497 Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Date: Mon, 10 Dec 2018 10:07:33 +0000
Subject: [PATCH] option: fix non DHCPv6 build error
option.c: In function 'dhcp_context_free':
option.c:1042:15: error: 'struct dhcp_context' has no member named 'template_interface'
free(ctx->template_interface);
^~
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
This time I have a little bit more controversal patches. But I think
still useful. They fixes memory leaks that might occur in some cases.
Most dnsmasq errors is fatal, so it does not matter. But some are not.
Some parts are reloaded on SIGHUP signal, so it might leak more than once.
Some example when it changes the failures. Use dhcp-options file with
this content:
tag:error,vendor:redhat
option:ntp-server,1.2.3.4.5
option6:ntp-server,[:::]
Is not fatal and dnsmasq will start. On each reload command, it would
leak some memory. I validated it using valgrind --leak-check=full
dnsmasq -d. This patch fixes it. It introduces something that might be
considered constructor and destructor of selected structures.
In an era where everything has an MMU, this looks like
an anachronism, and it adds to (Ok, multiplies!) the
combinatorial explosion of compile-time options.
Make options bits derived from size and count. Use size of option bits
and last supported bit in computation. No new change would be required
when new options are added. Just change OPT_LAST constant.
This was the source of a large number of #ifdefs, originally
included for use with old embedded libc versions. I'm
sure no-one wants or needs IPv6-free code these days, so this
is a move towards more maintainable code.
But make auth-server required when any auth-zones are defined.
The "glue record" field in auth-server is needed to synthesise
SOA and NS records in auth zones, so the --auth-server has to
be specified. If makes sense, however to define one or more
auth-zones that appear within the normal recursive DNS service
without actually acting as an authoritative DNS server on
any interface. Hence making the interface field optional.
I got reported bug in Fedora [1], that cname is broken in new releases.
At first I though this was false report, but there is still new
regression in cname handling.
Before, it accepted alias with trailing dot. Not it would accept only
target, but not alias.
cname=alias.,target
is no longer valid. The issue is it will count size to skip after
canonicalize. If that ignores trailing dot, next name would be "". And
that is invalid and refused, dnsmasq refuses to start.
I also think that any whitespace like tab should be possible after
comma. So this fixes also 30858e3b9b.
Fix heap overflow in DNS code. This is a potentially serious
security hole. It allows an attacker who can make DNS
requests to dnsmasq, and who controls the contents of
a domain, which is thereby queried, to overflow
(by 2 bytes) a heap buffer and either crash, or
even take control of, dnsmasq.
Adds option to delay replying to DHCP packets by one or more seconds.
This provides a workaround for a PXE boot firmware implementation
that has a bug causing it to fail if it receives a (proxy) DHCP
reply instantly.
On Linux it looks up the exact receive time of the UDP packet with
the SIOCGSTAMP ioctl to prevent multiple delays if multiple packets
come in around the same time.
It is currently only possible to let the TFTP server serve a different
folder depending on the client's IP address.
However it isn't always possible to predict what the client's
IP address will be, especially in situations in which we are not
responsible for handing them out (e.g. proxy dhcp setups).
Extend the current --tftp-unique-root parameter to support having a
separate folder per MAC address instead.
The current --server syntax allows for binding to interface or
address. However, in some (admittedly special) cases it is useful to
be able to specify both. This commit introduces the following syntax
to support binding to both interface and address:
--server X.X.X.X@IP@interface#port
Based on my tests, the syntax is backwards compatible with the current
@IP/interface#port. The code will fail if two interface names are given.
v1->v2:
* Add man page description of the extended server syntax (thanks Simon Kelley)
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
The rev-server directive only handles the following CIDR prefixes
properly: /8, /16, /24, /32.
Any other value was silently converted to /16 which could result in
unexpected behaviour.
This patch rejects any other value instead of making a silent
conversion.
[ excerpt from the man page ]
The rev-server directive provides a syntactic sugar to make specifying
address-to-name queries easier. For example
--rev-server=1.2.3.0/24,192.168.0.1 is exactly equivalent to
--server=/3.2.1.in-addr.arpa/192.168.0.1
It is not mentioned in the man page but the only prefixes that the
directive properly handles when dealing with IPv4 are /8, /16 and /24.
Specifying anything else as the same effect as specifying /16.
It is not a big deal for subnets on non-octet boundaries since they
cannot be represented using a single in-addr.arpa address. However, it
is unconvenient for /32 prefix while the analogous server directive
behaves as expected. E.g. the following server directive work
as expected:
server=/42.10.168.192.in-addr.arpa/1.2.3.4
but the following does not:
rev-server=192.168.10.42/32,1.2.3.4
and, in practice, the later behaves the same as:
server=/168.192.in-addr.arpa/1.2.3.4
This strange behaviour is fixed by accepting /32 CIDR prefixes as a
valid value. Any other value will still be considered the same as /16.
