Re: [Dnsmasq-discuss] Make dnsmasq distinguish local IPs

2020-07-22 Thread Simon Kelley
I think this is the crux.

dnsmasq is listening on the wildcard address and accepting packets which
 arrive from lo. lo has address 127.0.0.20 (amongst others) and
therefore dnsmasq is deciding that queries is sends to 127.0.0.20 will
end up back at itself, and refusing to do that because it's a bad thing
to do. It doesn't know that you are gaming obscure kernel behaviour to
send 127.0.0.20 somewhere else.

How many addresses are on lo? If it's a reasonable number, can you just
enumerate all of them _apart_ from 127.0.0.20 as listen_address configs,
and miss out the interface=lo from the config. That should do what you
want. Failing that, an except-address config, analogous to
except-interface would do the trick, but doesn't exist. :(

Cheers,

Simon.




On 21/07/2020 18:15, László Károlyi wrote:
> dnsmasq needs to listen on all IPs on the lo0 interface _except_ for the
> one unbound also listens on (in this case, 127.0.0.20), so that the
> jailed processes have dnsmasq to communicate with, and then dnsmasq can
> query unbound for 'outside' DNS resolution on its own jail IP. The
> latter happens via IPv6 only now, as dnsmasq refuses to use 127.0.0.20
> with its current config, however according to sockstat, it listens on
> the wildcard interface despite its log message:
> 
> USER COMMAND    PID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS
> nobody   dnsmasq    99396 4  udp4   *:53  *:*
> nobody   dnsmasq    99396 5  tcp4   *:53  *:*
> nobody   dnsmasq    99396 6  udp6   *:53  *:*
> nobody   dnsmasq    99396 7  tcp6   *:53  *:*
> nobody   dnsmasq    99396 10 dgram  (not connected)
> 
> Unbound listens on 127.0.0.20:
> 
> USER COMMAND    PID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS
> unbound  unbound    29892 3  udp6   2a01:4f8:241:15df::32:53 *:*
> unbound  unbound    29892 4  tcp6   2a01:4f8:241:15df::32:53 *:*
> unbound  unbound    29892 5  udp4   127.0.0.20:53 *:*
> unbound  unbound    29892 6  tcp4   127.0.0.20:53 *:*
> 
> When testing, dnsmasq responds to all internal hostname queries on
> 127.0.0.x except for 127.0.0.20, so it seems to listen on all
> interfaces. FreeBSD kernel gives preference to the IP-bound
> (non-wildcard) socket when connecting to that socket for querying, see
> querying an inner jail name, jail-mariadb:
> 
> # host jail-mariadb 127.0.0.1
> Using domain server:
> Name: 127.0.0.1
> Address: 127.0.0.1#53
> Aliases:
> 
> jail-mariadb has address 127.0.0.24
> jail-mariadb has IPv6 address 2a01:4f8:241:15df::21
> 
> # host jail-mariadb 127.0.0.5
> Using domain server:
> Name: 127.0.0.5
> Address: 127.0.0.5#53
> Aliases:
> 
> jail-mariadb has address 127.0.0.24
> jail-mariadb has IPv6 address 2a01:4f8:241:15df::21
> 
> # host jail-mariadb 127.0.0.20
> Using domain server:
> Name: 127.0.0.20
> Address: 127.0.0.20#53
> Aliases:
> 
> Host jail-mariadb not found: 3(NXDOMAIN)
> 
> Both 127.0.0.1 and 127.0.0.5 is a response from dnsmasq, but 127.0.0.20
> is a response from unbound. This is desired, in order for the jailed
> processes to be able to use DNS resolution from within.
> 
> What I'm trying to achieve is to make dnsmasq query 127.0.0.20 knowing
> the facts above, as specified in the /usr/local/etc/dnsmasq-resolv.conf:
> 
> nameserver 127.0.0.20
> nameserver 2a01:4f8:241:15df::32
> 
> Basically, the jails talk to their own assigned internal IPs when
> querying (not 127.0.0.1, that won't work because the DNS response gets
> dropped as the response comes from the jail's internal IP and not
> 127.0.0.1), it's why dnsmasq has to listen on them. Then dnsmasq will
> talk to the unbound jail's IP address (127.0.0.20), when querying for
> outside DNS.
> 
> Sounds complicated, but this is what I'd like to get done, so it would
> work with both IPv6 AND IPv4.
> 
> Cheers,
> --
> László Károlyi
> http://linkedin.com/in/karolyi
> 
> On 2020-07-21 17:00, Petr Menšík wrote:
>> How should unbound listen on lo0 if dnsmasq is already listening there?
>> I do not know BSD. Linux would not permit dnsmasq listening on wildcard
>> socket and unbound listening on the same port.
>>
>> I think listen-address would listen just on 127.0.0.1. interface=lo0
>> should not be necessary. At least on Linux kernel, it means listening on
>> ANY IPv4/IPv6 address assigned to lo0. That would mean unbound needs
>> different port to listen on or different interface. I think that is not
>> what you want.
>>
>> What is contents of /usr/local/etc/dnsmasq-resolv.conf?
>> I think no-resolv should be used as well to prevent reading
>> /etc/resolv.conf.
> 
> ___
> 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] TCP DNS requests fail with "communications error" / "end of file"

2020-07-22 Thread Simon Kelley
On 20/07/2020 14:11, Jinn Ko wrote:
> Hi,
> 
> While using dnsmasq as embedded in the pi-hole project I came across an issue 
> with how TCP
> DNS requests are handled over Wireguard interfaces.
> 
> A ticket was raised in the FTL project 
> (https://github.com/pi-hole/FTL/issues/824) and the
> conclusion was that the issue is in dnsmasq.  It seems the logic of 
> determining the incoming
> interface fails and the connection is closed and reset before FTL can handle 
> it, which seems
> to put the issue in the dnsmasq codebase.
> 
> A key detail is that the Wireguard interface is configured with the same IP 
> as the default
> interface, but with a more specific subnet mask.  For example where eth0 has 
> the default
> route it may be configured with 10.3.2.1/24, while the Wireguard interface 
> would have the
> address 10.3.2.1/32.  Having a different IP on the two interfaces does not 
> cause any issues.

Is this something as simple as needing to have dnsmasq listening on both
eth0 and the wireguard interface?

Can you describe exactly what's going on around dnsmasq.c line 1815 and
in the loopback_exception() function, to cause client_ok to be set to
zero? I can't easily access your logging patches, and I don't have a
pihole installation, so I can't easily reproduce this or understand
exactly what the logging means. I'm interested in what interface_index
is returned from  tcp_interface(), what interface name that translates
to, what interface indexes are in the daemon->interfaces linked list
that gets tested against, and if that test fails, what happens in
loopback_exception()

Cheers,

Simon

> 
> See the above linked FTL ticket for how we came to the conclusion, along with 
> PCAPs and
> custom logging output that was put in place to determine what is going wrong.
> 
> How can I help get this resolved?
> 
> Thanks,
> Jinn
> 
> ___
> 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] return responses without qname

2020-07-22 Thread Simon Kelley
I'm not sure that this is the correct solution to the problem.

I'd argue that this is an unbound issue: A reply to a DNS query that
doesn't echo the qname surely cannot be considered a valid reply?
I'm not sure why unbound would do that.

The query-id is only 16 bits, so can't be considered enough to uniquely
identify queries. Also, this provides a very easy DoS attack vector:
just firehose qname-less replies at the dnsmasq instance with random ids
and you're more-or-less guaranteed to fail a reasonable proportion of
DNS queries in progress.


Cheers,

Simon.





On 20/07/2020 15:04, Petr Menšík wrote:
> Hi,
> 
> found out even latest dnsmasq is not able to forward reply, when it does
> not contain qname in response body. I discovered it when testing
> RHEL/CentOS 7, which has Unbound 1.6.6. If you send non-recursive query
> to it, it responds with REFUSED. But no query name copied in response.
> 
> dig itself can handle it well. But dnsmasq does not forward such query back.
> 
> Steps to reproduce:
> start unbound < 1.7.0, listening on localhost
> start dnsmasq with:
> bind-interfaces
> listen-address=127.0.0.2
> 
> It can be tested with unbound configured on localhost. Then use:
> dig @127.0.0.2 +norec localhost
> 
> It would always fail with timeout, because dnsmasq discards the reply. I
> attached my attempt to fix the issue. It just provides null hash, which
> is then supported by cache lookup.
> 
> Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1826691
> Github link: https://github.com/InfrastructureServices/dnsmasq/pull/6
> 
> 
> ___
> 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] Announce: dnsmasq-2.82

2020-07-19 Thread Simon Kelley
I just publish version 2.82 of dnsmasq. This fixes a nasty problem
introduced in 2.81 which causes random crashes on systems where there's
significant DNS activity over TCP. It also fixes DNSSEC validation
problems with zero-TTL DNSKEY and DS records.

http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.82.tar.gz

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.82rc1

2020-07-12 Thread Simon Kelley
I've just tagged the first release-candidate for dnsmasq-2.82.

http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.82rc1.tar.gz

This has some (but not all) the patches left over from 2.81, and a
couple of new trivial fixes, but most importantly, it should fix a
source of random crashes which crept into 2.81.

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q2/014123.html

It's this which is the motivation for a reasonably rapid 2.82 release.

Please download and test, as you can.


Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] BOGUS DNSSEC responses

2020-07-12 Thread Simon Kelley
On 09/07/2020 09:07, László Károlyi wrote:
> Thanks for your response again.
> 
> I'm not an expert in DNSSEC, so I can't answer you the first point. As
> for the second point, I attached my (pretty milktoast) unbound.conf, not
> much changes in there; hoping it could give a clue.

It's not giving me a clue, I'm afraid. In any case, I've fixed dnsmasq
to handle zero-TTL DNSKEY and DS records,

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=7e194a0a7d483932eb3f416b8f26131ade588acc

and made an 2.82 release-candidate at

http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.82rc1.tar.gz

Please could you check if that fixes things?



cheers,

Simon.

> 
> Edit: Resending the unbound.conf zipped since the unzipped version it
> got held up by mailman.
> 
> Cheers,
> --
> László Károlyi
> https://linkedin/com/in/karolyi
> 
> On 06.07.20 23:05, Simon Kelley wrote:
>> OK, I can see the proximate cause of the problem, but I'm not sure
>> what's causing it and I'm not sure how behaviour needs to change.
>>
>> The proximate cause is that the upstream server (unbound, I think.) is
>> returning answers to queries for DNSKEY records with time-to-live as
>> zero. Time-to-live zero means "use this once, but don't cache it" so
>> dnsmasq doesn't cache it. But the DNSSEC validation process in dnsmasq
>> depends on data like DNSKEYs being cached: that's the path by which it
>> gets to the correct place for doing the validation. Hence the validation
>> failures.
>>
>> Two questions arise.
>>
>> 1) Is dnsmasq wrong to fail validation with DNSKEYS with TTL zero. I
>> think that answer to that is probably "yes", if only on grounds of "be
>> forgiving in what you accept". The fix is fairly simple.
>>
>> 2) Why is Unbound returning DNSKEY records with TTL zero, over and over
>> again? Is there something in your unbound config that causes that?
>>
>>
>> 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] Fwd: [PATCH] Makefile: make variables overridable

2020-07-12 Thread Simon Kelley
On 12/07/2020 18:53, John Ericson wrote:
> Hi, I am another NixOS maintainer.
> 
> Yes, it is true that ?= in makefiles is somewhat rare, and that we can work 
> around this other ways. But it was I who proposed the ?= change on our 
> side[1], so let say why I think it's the right choice:
> 
> Most C packages don't use "?=" and do
>  FOO ?= foo
> but instead do have a configure script, so they do
>  FOO = @FOO@
> with regular "=". However that configure script *does* silently consume 
> environment variables, so the effect is the same.
> 
> I wouldn't request upstream add a configure script is nothing is needed, and 
> I don't even like the implicitness of environment variables myself. But the 
> fact is it is the standard for distros to communicate information to all the 
> myriad build systems[2], so I advocate this change so distros can remove 
> extra packaging hacks.
> 
> The variable we need to override is PKG_CONFIG. One may right point out that 
> other distros don't rename pkg-config, but that's because most derivations 
> don't support cross compilation. NixOS does, but NixOS is not the only one: 
> See also Exerho and their dnsmasq packaging[3] which has the same 
> workarounds. We hope that cross compilation becomes less niche, but that 
> means more people and projects will be affected by these sorts of things.

I don't like taking random stuff from an uncontrolled namespace which is
what the Unix environment is. I'd argue that Exerho's approach is the
right one: there's a list of exactly what is being used from the
environment, right there, and an adaptation layer if the same thing has
different names in the build system and the makefile.

I would note, however, that the dnsmasq makefile doesn't set the value
of CC at all, and uses it direct from the environment, if set. I guess
that one, at least is universal.

Looking at some random source trees floating in my home directory,
neither libnettle nor BIND seem to import stuff will-nilly from the
environment.


Cheers,

Simon.




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Ability to not bind :: for DNS when binding wildcard

2020-07-06 Thread Simon Kelley
On 06/07/2020 14:05, Matthias May wrote:

> Hi Dominik
> 
> Well the system in question has
> net.ipv6.conf.all.disable_ipv6 = 1
> thus the expected output would be that no IPv6 bindings exist at all.
> I kind of understand that when IPv6 is disabled, that one would not expect to 
> see :::53 in netstat -nlp
> On the other hand i also see that if no IPv6 address exist on the system, 
> there is not much that can be done with :::53.
> In the end probably more a cosmetic issue.
> I was thinking into the direction that create_wildcard_listeners checks by 
> itself if the system has IPv6
> enabled/disabled, and also expose this as a manual know for an user to set.
> 


I'd rather have something that checked the value of
net.ipv6.conf.all.disable_ipv6 than yet another configuration option.

A patch which


1) Added a function in src/util.c to check the value of something under
/proc/sys

2) Added code to call that and avoid the bind in create_wildcard_listeners


both taking into account that this has to compile on platforms other
than linux (#ifdef HAVE_LINUX_NETWORK)


would be fine.


Cheers,

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] Fix buffer overflow in TCP requests

2020-07-06 Thread Simon Kelley
On 30/06/2020 20:22, Frank wrote:
> Resending this because I realized I sent it to Simon rather than the list:
> 
> Hi Simon,
> 
> This bug is fairly easy to reproduce. It can take 10 mins or more to
> reproduce a crash so I suggest checking the length you get in
> cache_recv_insert. If the domains being used are > 4 characters, this
> will catch the bug the first time it occurs. That usually happens
> within a minute. Something like this:
> 
> if (m > MAXDNAME) abort();
> 

OK, that makes sense.  EINTR or EAGAIN are possible, but rare. Does the
fix in 2.82test1 work for you? If so I think I'll work towards a 2.82
release before doing anything else, just to nail this.


Simon.


> Then bombard dnsmasq with TCP queries:
> 
> docker run --rm -v /root/dns_queries:/dns_queries
> aiys0211/flamethrower_v0.10.2 -f
> /dns_queries/queryfile-example-100thousand -l 1000 -c 20 -q 10 -d 300
> -p 53 -P tcp 
> 
> I used the first 100 thousand entries from here:
> https://www.dns-oarc.net/files/dnsperf/data/queryfile-example-10million-201202.gz
> 
> Frank
> 
> On Sun, Jun 28, 2020 at 1:58 PM Simon Kelley  wrote:
>>
>> That's a nasty bug, and could explain what pi-hole users are seeing.
>>
>> If I understand things correctly, this bug will only manifest itself
>> when the write() or read() syscalls return EINTR ir EAGAIN, which is
>> possible, but not common, hence the bugs wasn't detected earlier.
>>
>> Frank, did you find a way to reproduce this on demand, or just capture
>> sporadic instances?
>>
>> I've applied Frank's patch, but immediately superseded it with a more
>> general clean-up which should have the same effect. I've tagged a
>> 2.82test1 release with this. If that fixes the problem for pi-hole, I
>> plan to go to 2.82 fairly quickly: I don't want this hanging around.
>>
>> It's slightly ironic that the original change in 2.81 is to fix a
>> theoretical hang which I've never actually seen and cannot reproduce,
>> but it introduced a really crash bug.
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>>
>> On 18/06/2020 22:42, Dominik wrote:
>>> Hey Frank, dear list-members,
>>>
>>> thanks for your proposed fix. The Pi-hole team adopted dnsmasq v2.81
>>> early on and we're seeing reports for mysterious crashes scattered all
>>> over the dnsmasq code since the very first days of releasing our latest
>>> version. Crashes reports show several locations, e.g., in_zone(),
>>> iface_check() and even main() in a few places. TCP forks were always
>>> happening sometime (not necessarily immediately) before a crash.
>>> Running dnsmasq in debug mode (prevents forking) stopped any crashes.
>>>
>>> So far, we haven't had the time to dig into this ourselves properly,
>>> however, your description perfectly matches with my preliminary
>>> conclusion for one week ago:
>>>> the dangling pointer is in **all** bug reports known so far in the
>>> daemon pointer
>>> (https://github.com/pi-hole/FTL/issues/805#issuecomment-643157367)
>>>
>>> The addition of TCP forks being able to add cache replies in dnsmasq
>>> v2.81 is what is causing this code (which has been like this for along
>>> time) to become problematic. I recently looked at the same code but
>>> missed the chance that the byte may be still in the pipe. This is a
>>> very good catch!
>>>
>>> I'm writing this mail to raise awareness that this appears to be a high
>>> severity bug as it can easily lead to anything between indeterminable
>>> behavior to fatal failures (typically the case). Even when the bug can
>>> only be triggered under certain conditions, it recently caused over 200
>>> posts on the Pi-hole issue ticket system (Github). Crashes due to this
>>> have been reported independently by several (more than 20) individual
>>> users.
>>> Best
>>> Dominik
>>>
>>> On Wed, 2020-06-17 at 19:52 -0700, Frank wrote:
>>>> Hello,
>>>>
>>>> This patch fixes a buffer overflow in TCP requests. Since the read is
>>>> not actually being retried, the byte written by the child can be left
>>>> in the pipe. When that happens, cache_recv_insert() reads the length
>>>> of the name, which is now multiplied by 256 due to the extra 0 byte
>>>> (8 bit shift) and results in daemon->namebuff being overflowed.
>>>> Namebuff is immediately before the daemon struct in memory so it ends
>>>> up corrupting the beginning of the daemon struc

Re: [Dnsmasq-discuss] BOGUS DNSSEC responses

2020-07-06 Thread Simon Kelley
OK, I can see the proximate cause of the problem, but I'm not sure
what's causing it and I'm not sure how behaviour needs to change.

The proximate cause is that the upstream server (unbound, I think.) is
returning answers to queries for DNSKEY records with time-to-live as
zero. Time-to-live zero means "use this once, but don't cache it" so
dnsmasq doesn't cache it. But the DNSSEC validation process in dnsmasq
depends on data like DNSKEYs being cached: that's the path by which it
gets to the correct place for doing the validation. Hence the validation
failures.

Two questions arise.

1) Is dnsmasq wrong to fail validation with DNSKEYS with TTL zero. I
think that answer to that is probably "yes", if only on grounds of "be
forgiving in what you accept". The fix is fairly simple.

2) Why is Unbound returning DNSKEY records with TTL zero, over and over
again? Is there something in your unbound config that causes that?


Cheers,

Simon.






On 06/07/2020 09:50, László Károlyi wrote:
> So, this was done faster as I thought.
> 
> I've uploaded the file to wetransfer since it's 3MB and I don't want an
> outcry from people on here about me sending huge emails:
> https://we.tl/t-mlLySN7n0f
> 
> In that dump, you will probably see obsswitcher.com,
> updates.spamassassin.org and api.foursquare.com failed requests. I
> didn't look into it in detail, but the sheer size should indicate a lot
> of failed requests.
> 
> Cheers,
> --
> László Károlyi
> http://linkedin.com/in/karolyi
> 
> On 2020-07-06 00:41, László Károlyi wrote:
>> Hey Simon,
>>
>> thanks for your response.
>>
>> Yes, my bad, I should have said at the outset that I use the latest
>> dsmasq in FreeBSD with the latest official (12.1-RELEASE-p6) release on
>> the latest patch level. So, dnsmasq is "2.81_2,1" , as defined here:
>>
>> https://www.freshports.org/dns/dnsmasq/
>>
>> I use NTP to keep the time in sync on my box, the output of ntpq -n -p is:
>>
>>  remote   refid  st t when poll reach   delay   offset 
>> jitter
>> ==
>>  0.freebsd.pool. .POOL.  16 p    -   64    0    0.000   +0.000  
>> 0.000
>> -162.159.200.1   10.71.10.44  3 u   49 1024  377    5.077   -2.686  
>> 0.288
>> *193.158.22.13   .MBGh.   1 u  217 1024  377   11.921   -1.232  
>> 0.298
>> +85.209.49.104   35.73.197.144    2 u   81 1024  377    2.780   -0.842  
>> 0.242
>> +185.120.22.12   130.149.17.21    2 u  384 1024  377    5.404   -0.482  
>> 0.384
>> -212.18.3.19 212.18.1.106 2 u  122 1024  377    6.106   -1.292  
>> 0.260
>>
>> Basically as you can see, no egregious time differences (delay is in
>> milliseconds). As for the domains, my domain is kept in cloudflare, they
>> provide the DNSSEC records as well. I don't know if that's the case for
>> github and/or updates.spamassassin.org, which I also see failing.
>>
>> I'll set the flags and logfile you provided, and will wait until the
>> error occurs again, and then I'll touch base again with you. It should
>> take a day or two at most, the sometimes failing cronjob runs hourly.
>>
>> Best Regards,
>> --
>> László Károlyi
>> https://linkedin/com/in/karolyi
>>
>> On 05.07.20 23:17, Simon Kelley wrote:
>>> Just a stab in the dark: are you sure that the clocks on these machines
>>> are accurate? DNSSEC signatures have validity periods and when I checked
>>> obsswitcher.com its start-of-validity time was only an hour or so before
>>> the time when I checked, so a bad clock would explain what you're seeing.
>>>
>>> Failing that, you don't say what version of dnsmasq you're running.
>>> PLease make sure you upgrade to 2.81 if you're running older code. That
>>> fixes lots of DNSSEC bugs.
>>>
>>> If 2.81 still shows the problem, set the following dnsmasq configuration
>>>
>>> dumpfile=
>>> dumpmask=0x00C0
>>>
>>> run the test again and send me the resulting dumps.
>>>
>>>
>>> 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 mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] BOGUS DNSSEC responses

2020-07-05 Thread Simon Kelley
Just a stab in the dark: are you sure that the clocks on these machines
are accurate? DNSSEC signatures have validity periods and when I checked
obsswitcher.com its start-of-validity time was only an hour or so before
the time when I checked, so a bad clock would explain what you're seeing.

Failing that, you don't say what version of dnsmasq you're running.
PLease make sure you upgrade to 2.81 if you're running older code. That
fixes lots of DNSSEC bugs.

If 2.81 still shows the problem, set the following dnsmasq configuration

dumpfile=
dumpmask=0x00C0

run the test again and send me the resulting dumps.


Cheers,

Simon.


On 04/07/2020 17:37, László Károlyi wrote:

> Hey,
> 
> I have a FreeBSD box where jails communicate with dnsmasq outside to
> resolve each other's addresses (they get different IPs on
> redeployments), and dnsmasq communicates with unbound where it needs to
> resolve outside domains.
> 
> When running stuff from cron within the jails, sometimes hostnames don't
> resolve and I started to investigate on the problem by turning debug log
> on with dnsmasq. As it turns out, it complains about domain DNSSEC
> errors, where they are properly configured. This happens with my domain
> (attached in the logs), and outher domains (github,
> updates.spamassassin.org) as well. I'm somewhat clueless as to why it
> happens, so please see the log attached, with my own domain,
> obsswitcher.com. What happens here is, I've set up a cronjob with curl
> to run until it succeeds, that is:
> 
> while true; do curl -s 'https://obsswitcher.com/' && break || date; done
> 
> Sometimes hostname resolution succeeds at first time, sometimes it takes
> 200+ tries until it succeeds once, and quits. The attached log is the
> one where it happened 200+ times before succeeding.
> 
> Any help is appreciated.
> 
> Cheers,
> --
> László Károlyi
> http://linkedin.com/in/karolyi
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [Bugreport] => man page => key '-S, --local, --server' => typo

2020-07-05 Thread Simon Kelley
On 26/06/2020 21:11, Geert Stappers wrote:
> On Fri, Jun 26, 2020 at 01:42:42PM +, a...@protonmail.com wrote:
>> Hello, world!
>>
>> See: 
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=man/dnsmasq.8;h=a2a60d5e2b3d4d8a3a944d8f451afd97b4ca1033;hb=HEAD
>> See line 431
>>
>> Sentence about key '-S' contains odd count square brackets: 7 left and 6 
>> right.
>>
>> 7 left: [ [ [ [ [ [ [
>> 6 right: ] ]] ] ]]
>> -S, --local, 
>> --server=[/[]/[domain/]][[#][@|[#]]
> [   ]
>[[   ]
>[[#]
>   -S, --local, 
> --server=[/[]/[domain/]][[#]][@|[#]]
> [   ]
>[[   ]]
>  ^
>  
>> Expected behavior: the number of left brackets is equal to the number of 
>> right brackets.
> 
> 
> 
> Groeten
> Geert Stappers
> 

Patch applied. Thanks both.

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Static leases issues

2020-06-29 Thread Simon Kelley
On 08/06/2020 17:18, Bruno BEAUFILS wrote:
> Hello everyone,
> 
> I have got a static leases issue with dnsmasq 2.80-1 installed as
> Debian Buster package.
> 
> I search the man page and the mailing list archives without any
> success. Thus I try here.
> 
> Here is short summary of what I have.
> 
> I am on a simple LAN with a screenless host running dnsmasq. It is the
> only, and thus main, DHCP server on the network.
> 
> I use the dhcp-authoritative option in dnsmasq configuration.
> 
> It offers a dhcp-range looking like that...
> 
> dhcp-range=192.168.0.200,192.168.0.250,12h
> 
> ...and a bunch of static lease looking like something like that 
> 
> dhcp-host=xx:xx:xx:xx:xx:xx,id:*,192.168.0.2,somename
> 
> I want to use a new USB-ethernet adpator on a new laptop.
> 
> On the first connection the host get a IP from the open range
> (192.168.0.203) as it is visible in the logs:
> 
> Jun  7 17:38:29 b3 dnsmasq-dhcp[12907]: DHCPDISCOVER(eth1) 
> 12:34:56:78:9a:bc
> Jun  7 17:38:29 b3 dnsmasq-dhcp[12907]: DHCPOFFER(eth1) 192.168.0.203 
> 12:34:56:78:9a:bc
> Jun  7 17:38:29 b3 dnsmasq-dhcp[12907]: DHCPDISCOVER(eth1) 
> 12:34:56:78:9a:bc
> Jun  7 17:38:29 b3 dnsmasq-dhcp[12907]: DHCPOFFER(eth1) 192.168.0.203 
> 12:34:56:78:9a:bc
> Jun  7 17:38:29 b3 dnsmasq-dhcp[12907]: DHCPREQUEST(eth1) 192.168.0.203 
> 12:34:56:78:9a:bc
> Jun  7 17:38:29 b3 dnsmasq-dhcp[12907]: DHCPACK(eth1) 192.168.0.203 
> 12:34:56:78:9a:bc mechra
> 
> After the first connection I am able to log on the server and add a
> dhcp-host specific to that host. For that I did the following things
> in order :
> 
> 1. stop the dnsmasq server
> 
> 2. remove the leases file
> 
> 3. modify the dnsmasq configuration in order to add the dhcp-host
>option
> 
> dhcp-host=00:23:4d:df:a1:d1,id:*,192.168.0.15,somefancyname,24h
> 
> 4. start the dnsmasq server
> 
> After that I unplug the adaptor from the laptop and replug it in order
> for it to get the new IP from the static lease. Unfortunately I always
> get the same "old" adress (192.168.0.203), as the log shows (because
> the client asked it):
> 
> juin  7 18:05:23 b3 dnsmasq-dhcp[29360]: DHCPREQUEST(eth1) 192.168.0.203 
> 12:34:56:78:9a:bc
> juin  7 18:05:23 b3 dnsmasq-dhcp[29360]: DHCPACK(eth1) 192.168.0.203 
> 12:34:56:78:9a:bc mechra
> 
> I thought the dnsmasq should have refused the client request of using
> 192.168.0.203 (through a DHCPNAK for instance) and sent it a new
> OFFER with the correct static (192.168.0.15).
> 
> Did I miss something (aka this is normal behavior but I misconfigured
> the whole stuff certainly because I did not understand the
> documentation well enough) or am I struggling with some kind of bug?
> 
> Just in case it matters: all host used in the description are running Debian.
> 

Dnsmasq does have code to do exactly what you want, but I think by
unpluging and replugging the adapter, you're frustrating that because
the DHCP client is going to "SELECTING" mode. Ie it's saying to the DHCP
server "I want this address (the address it had before)" and the DHCP
server has to comply, as long as the address is valid. If you can get
the DHCP server to RENEW the lease (either by making leases short, or
finding a control on the DHCP client) then the renewal will fail and a
DHCPNAK will be sent, which should force the client back to DHCPDISCOVER
state and it will find the new address. The same thing should happen in
INIT-REBOOT state, which I'd expect the client to move to on the
unplug-replug cycle.


The state diagram for a client is here:

https://tools.ietf.org/html/rfc2131#page-35

If you can grab a packet dump of the DHCPREQUEST packet being sent, that
would be useful. If it has both SERVER_IDENTIFIER and REQUESTED_IP
options, then that would explain the behaviour, and put the spotlight on
the client. Actually, a dump of the whole exchange would be useful.


Simon.



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] Fix buffer overflow in TCP requests

2020-06-28 Thread Simon Kelley
That's a nasty bug, and could explain what pi-hole users are seeing.

If I understand things correctly, this bug will only manifest itself
when the write() or read() syscalls return EINTR ir EAGAIN, which is
possible, but not common, hence the bugs wasn't detected earlier.

Frank, did you find a way to reproduce this on demand, or just capture
sporadic instances?

I've applied Frank's patch, but immediately superseded it with a more
general clean-up which should have the same effect. I've tagged a
2.82test1 release with this. If that fixes the problem for pi-hole, I
plan to go to 2.82 fairly quickly: I don't want this hanging around.

It's slightly ironic that the original change in 2.81 is to fix a
theoretical hang which I've never actually seen and cannot reproduce,
but it introduced a really crash bug.


Cheers,

Simon.




On 18/06/2020 22:42, Dominik wrote:
> Hey Frank, dear list-members,
> 
> thanks for your proposed fix. The Pi-hole team adopted dnsmasq v2.81
> early on and we're seeing reports for mysterious crashes scattered all
> over the dnsmasq code since the very first days of releasing our latest
> version. Crashes reports show several locations, e.g., in_zone(),
> iface_check() and even main() in a few places. TCP forks were always
> happening sometime (not necessarily immediately) before a crash.
> Running dnsmasq in debug mode (prevents forking) stopped any crashes.
> 
> So far, we haven't had the time to dig into this ourselves properly,
> however, your description perfectly matches with my preliminary
> conclusion for one week ago:
>> the dangling pointer is in **all** bug reports known so far in the
> daemon pointer
> (https://github.com/pi-hole/FTL/issues/805#issuecomment-643157367)
> 
> The addition of TCP forks being able to add cache replies in dnsmasq
> v2.81 is what is causing this code (which has been like this for along
> time) to become problematic. I recently looked at the same code but
> missed the chance that the byte may be still in the pipe. This is a
> very good catch!
> 
> I'm writing this mail to raise awareness that this appears to be a high
> severity bug as it can easily lead to anything between indeterminable
> behavior to fatal failures (typically the case). Even when the bug can
> only be triggered under certain conditions, it recently caused over 200
> posts on the Pi-hole issue ticket system (Github). Crashes due to this
> have been reported independently by several (more than 20) individual
> users.
> Best
> Dominik
> 
> On Wed, 2020-06-17 at 19:52 -0700, Frank wrote:
>> Hello,
>>
>> This patch fixes a buffer overflow in TCP requests. Since the read is
>> not actually being retried, the byte written by the child can be left
>> in the pipe. When that happens, cache_recv_insert() reads the length
>> of the name, which is now multiplied by 256 due to the extra 0 byte
>> (8 bit shift) and results in daemon->namebuff being overflowed.
>> Namebuff is immediately before the daemon struct in memory so it ends
>> up corrupting the beginning of the daemon struct.
>>
>> diff --git a/src/dnsmasq.c b/src/dnsmasq.c
>> index 6481de8..457dea3 100644
>> --- a/src/dnsmasq.c
>> +++ b/src/dnsmasq.c
>> @@ -1887,7 +1887,7 @@ static void check_dns_listeners(time_t now)
>>single byte comes back up the pipe, which
>>is sent by the child after it has closed
>> the
>>netlink socket. */
>> -   retry_send(read(pipefd[0], , 1));
>> +   while (retry_send(read(pipefd[0], , 1)));
>>  #endif
>> break;
>>   }
>> @@ -1928,7 +1928,7 @@ static void check_dns_listeners(time_t now)
>>  #ifdef HAVE_LINUX_NETWORK
>>   /* See comment above re netlink socket. */
>>   close(daemon->netlinkfd);
>> - retry_send(write(pipefd[1], , 1));
>> + while (retry_send(write(pipefd[1], , 1)));
>>  #endif
>> }
>>
>> Frank
>>
>>
>> ___
>> 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] No forgetting logic when using hostsdir

2020-05-19 Thread Simon Kelley
On 17/05/2020 11:28, Kevin 'ldir' Darbyshire-Bryant wrote:
> The man page sayeth: 
> (http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html)
> 
> --hostsdir=
> Read all the hosts files contained in the directory. New or changed files are 
> read automatically. See --dhcp-hostsdir for details.
> 
> --dhcp-hostsdir=
> This is equivalent to --dhcp-hostsfile, except for the following. The path 
> MUST be a directory, and not an individual file. Changed or new files within 
> the directory are read automatically, without the need to send SIGHUP. If a 
> file is deleted or changed after it has been read by dnsmasq, then the host 
> record it contained will remain until dnsmasq receives a SIGHUP, or is 
> restarted; ie host records are only added dynamically.
> 
> 
> To re-iterate:
> 
> Host entries from dynamically read files will remain in dnsmasq’s memory if 
> removed from those file/s unless dnsmasq is persuaded to forget them, either 
> by SIGHUP or a complete restart.
> 
> Personally I would find it a welcome option if dnsmasq could also dynamically 
> forget entries.  I suspect it is not as simple as it sounds otherwise it 
> would have been implemented.




   Wot he said. Deleting such entries individually
is difficult, the only easy way is a complete cache-empty, and reload
everything.


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] No DHCPOffer back but DHCPDiscover is being received by UML machine

2020-04-28 Thread Simon Kelley
I tested with kernel 5.4 running under qemu, and don't see this problem.
Any progress bisecting the issue?


I committed the workaround patch:

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4890bcdea2cc0d9ecc21a0e39ed388a650a4ce42

Simon.


On 23/04/2020 21:05, Josh H wrote:
> Hi there,
> 
> I'm not sure of a way of testing it with a real network device, but I'm
> happy to attempt to build a older UML kernel and test it from there. As
> I said in my original email, the last fully known working build was way
> back in kernel 3.2 and a lot has changed since then, so it could very
> well be a kernel issue and due to the edge use case, no one has ever
> really come across it. Is there a kernel version you'd like me to try
> out? Debian has a standard usermodelinux package which contains prebuilt
> UML images with kernel versions of 4.9, 4.19 or 5.5 if they'd be handy?
> https://tracker.debian.org/pkg/user-mode-linux.
> 
> Thanks for the support,
> Josh
> 
> On Thu, 23 Apr 2020 at 20:30, Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> Ok, so Josh ran the strace and sent me the results as requested.
> 
> The interesting bit us here.
> 
> recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(68),
> sin_addr=inet_addr("0.0.0.0")}, msg_namelen=16,
> 
> msg_iov=[{iov_base="\1\1\6\0\310\261\311+\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\366\226}H"...,
> iov_len=548}], msg_iovlen=1, msg_control=[{cmsg_len=24,
> cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO,
> cmsg_data={ipi_ifindex=if_nametoindex("eth0"),
> ipi_spec_dst=inet_addr("192.168.1.1"),
> ipi_addr=inet_addr("255.255.255.255")}}], msg_controllen=24,
> msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 300
> recvmsg(4, {msg_namelen=16}, 0)         = -1 EAGAIN (Resource
> temporarily unavailable)
> 
> 
> 
> The first call to recvmsg has the MSG_PEEK and MSG_TRUNC flags set.
> MSG_TRUNC causes the result to be the actual length of the received
> packet, even if it's longer than  supplied buffer (548) and MSG_PEEK is
> defined as:
> 
> 
>  MSG_PEEK
>        This  flag  causes the receive operation to return data from the
>        beginning of the receive queue without removing that  data  from
>        the queue.  Thus, a subsequent receive call will return the same
>        data.
> 
> So this allows the buffer to be expanded if necessary and then recvmsg
> gets called again when the buffer is big enough, to actually get the
> data and remove it from the queue. In this case the packet is 300 bytes
> long and the buffer is already 548 bytes, so no expansion is needed, we
> just do the call again, without the MSG_PEEK|MSG_TRUNC flags. That's the
> second call to recvmsg, which returns EAGAIN - the socket is
> no-blocking, and this return says there's no packet queued. It looks
> like the kernel is ignoring the MSG_PEEK flag, and dequeueing the data
> on the first call.
> 
> I think this is a kernel bug.
> 
> Josh, does this work with an older kernel or with a real network device,
> rather than the UML virtual device? It would be good to work out where
> the regression happened.
> 
> 
> Simon.
> 
> On 16/04/2020 15:40, Josh H wrote:
> >
> >     First, answer a simple question the answer to which I may have
> missed.
> >     Is dnsmasq logging the receipt of DHCPDISCOVER messages? Can
> we see the
> >     whole log showing that?
> >
> >
> > Based on the config I provided at the initial message, I have the log
> > file writing to /var/log/dnsmasq.log. This is the whole content of
> that
> > file:
> >
> > root@dns:~# cat /var/log/dnsmasq.log
> > Apr 16 15:36:50 dnsmasq[1695]: started, version 2.80 DNS disabled
> > Apr 16 15:36:50 dnsmasq[1695]: compile time options: IPv6 GNU-getopt
> > DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> > loop-detect inotify dumpfile
> > Apr 16 15:36:50 dnsmasq-dhcp[1695]: DHCP, IP range 192.168.1.3 --
> > 192.168.1.8, lease time 12h
> >
> > No mention of the DHCPDiscover being acknowledged.
> >
> >     The next stage is to run dnsmasq under strace (check back here
> if you
> >     need instructions on that) and see what system calls it's making.
> >
> >
> > What command would I need to run for this? And what service is best to
> > upload the strace result, pastebin?
> >
> > Thanks,
> > Josh 
> 

Re: [Dnsmasq-discuss] TFC 7440

2020-04-27 Thread Simon Kelley



On 27/04/2020 21:56, Jeff Silverman wrote:
> People,
> 
> I am working for a large software company.
> 
> For performance reasons, they feel they have to have RFC 7440
> compatibility, for speed.  I have not found an open source TFTP server
> that implements RFC 7440, so they are going to use Windows Deployment
> Server (WDS).  That makes me sad.
> 
> Is RFC 7440 on the roadmap?

It's not on the roadmap. Would "large software company" like to sponsor
addition of RFC 7440 functionality to dnsmasq?

Simon.

> 
> --
> Jeff Silverman, Linux sysadmin
> to five three for phive niner too tree won ate
> jeffsilverm 4t gmail.c0m
> http://www.commercialventvac.com
> See my portfolio of writings and talks
> 
> ___
> 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] No DHCPOffer back but DHCPDiscover is being received by UML machine

2020-04-24 Thread Simon Kelley
Having looked at the docs for UML, I doubt that this is a UML problem,
it looks like a pure kernel (in this case, the one running under UML)
problem.

As such a regression test on those three kernels would therefore be useful.

Googling for combinations of recvmsg MSG_PEEK regression UDP MSG_TRUNK
shows a few possibles over the last few years, but no obvious smoking gun.

Assuming we've diagnosed the kernel misbehaviour correctly, the code in
dnsmasq could be changed to work-around the problem at the expense of a
small probability packet drop, which is not a problem in this case.

I'll look at doing that.

Simon.


On 23/04/2020 21:05, Josh H wrote:
> Hi there,
> 
> I'm not sure of a way of testing it with a real network device, but I'm
> happy to attempt to build a older UML kernel and test it from there. As
> I said in my original email, the last fully known working build was way
> back in kernel 3.2 and a lot has changed since then, so it could very
> well be a kernel issue and due to the edge use case, no one has ever
> really come across it. Is there a kernel version you'd like me to try
> out? Debian has a standard usermodelinux package which contains prebuilt
> UML images with kernel versions of 4.9, 4.19 or 5.5 if they'd be handy?
> https://tracker.debian.org/pkg/user-mode-linux.
> 
> Thanks for the support,
> Josh
> 
> On Thu, 23 Apr 2020 at 20:30, Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> Ok, so Josh ran the strace and sent me the results as requested.
> 
> The interesting bit us here.
> 
> recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(68),
> sin_addr=inet_addr("0.0.0.0")}, msg_namelen=16,
> 
> msg_iov=[{iov_base="\1\1\6\0\310\261\311+\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\366\226}H"...,
> iov_len=548}], msg_iovlen=1, msg_control=[{cmsg_len=24,
> cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO,
> cmsg_data={ipi_ifindex=if_nametoindex("eth0"),
> ipi_spec_dst=inet_addr("192.168.1.1"),
> ipi_addr=inet_addr("255.255.255.255")}}], msg_controllen=24,
> msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 300
> recvmsg(4, {msg_namelen=16}, 0)         = -1 EAGAIN (Resource
> temporarily unavailable)
> 
> 
> 
> The first call to recvmsg has the MSG_PEEK and MSG_TRUNC flags set.
> MSG_TRUNC causes the result to be the actual length of the received
> packet, even if it's longer than  supplied buffer (548) and MSG_PEEK is
> defined as:
> 
> 
>  MSG_PEEK
>        This  flag  causes the receive operation to return data from the
>        beginning of the receive queue without removing that  data  from
>        the queue.  Thus, a subsequent receive call will return the same
>        data.
> 
> So this allows the buffer to be expanded if necessary and then recvmsg
> gets called again when the buffer is big enough, to actually get the
> data and remove it from the queue. In this case the packet is 300 bytes
> long and the buffer is already 548 bytes, so no expansion is needed, we
> just do the call again, without the MSG_PEEK|MSG_TRUNC flags. That's the
> second call to recvmsg, which returns EAGAIN - the socket is
> no-blocking, and this return says there's no packet queued. It looks
> like the kernel is ignoring the MSG_PEEK flag, and dequeueing the data
> on the first call.
> 
> I think this is a kernel bug.
> 
> Josh, does this work with an older kernel or with a real network device,
> rather than the UML virtual device? It would be good to work out where
> the regression happened.
> 
> 
> Simon.
> 
> On 16/04/2020 15:40, Josh H wrote:
> >
> >     First, answer a simple question the answer to which I may have
> missed.
> >     Is dnsmasq logging the receipt of DHCPDISCOVER messages? Can
> we see the
> >     whole log showing that?
> >
> >
> > Based on the config I provided at the initial message, I have the log
> > file writing to /var/log/dnsmasq.log. This is the whole content of
> that
> > file:
> >
> > root@dns:~# cat /var/log/dnsmasq.log
> > Apr 16 15:36:50 dnsmasq[1695]: started, version 2.80 DNS disabled
> > Apr 16 15:36:50 dnsmasq[1695]: compile time options: IPv6 GNU-getopt
> > DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> > loop-detect inotify dumpfile
> > Apr 16 15:36:50 dnsmasq-dhcp[1695]: DHCP, IP range 192.168.1.3 --
> > 192.168.1.8, lease time 12h
> >
> > No mention of the DHCPDiscover being acknowledged.
> >
> >     The nex

Re: [Dnsmasq-discuss] DHCPv6 with IPv4 address in last 32 bits of IPv6 address: ideas?

2020-04-23 Thread Simon Kelley



On 23/04/2020 20:49, Simon Kelley wrote:
> 

> According to RFC 4291 Para 2.2, a mixed representation is possible, for
> instance ipv6-mapped IPv4 addresses can be written as
> 
> ::.1.2.3.4
> 
> So you could use something like 2a01:ac00::$something:98.98.98.98
> 
> and not have problems if octets in your address are greater than 99.
> 
> Dnsmasq uses the standard libc address-parsing functions which should
> support this format, BUT the option parsing code may have difficulty
> recognizing such addresses as IPv6 addresses, I shall take a look..
> 
> 


Replying to myself, the mixed-mode IPv6 address representation works in
dhcp-host, so

dhcp-host=hostname,98.98,98.98,[2a01:ac00::$something:98.98.98.98]

works fine.

Such addresses don't work in dhcp-option, but I just pushed a patch to
the git repo which addresses that.


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 with IPv4 address in last 32 bits of IPv6 address: ideas?

2020-04-23 Thread Simon Kelley



On 21/04/2020 14:58, William Edwards wrote:
> Hello,
> 
> I am working on replacing static IP addresses in our network by static
> DHCP leases (which is in turn preparation for PXE). For IPv4, this is
> easily doable, but for IPv6 this is a bit of a challenge because of the
> following:
> 
> In our case, all services directly attached to the internet are
> dual-stack. We make IPv6 addresses easy to remember by placing
> corresponding /32s in the last 32 bits of /128s. For example,
> 98.98.98.98's dual-stack IPv6 address would become
> 2a01:ac00::$something:98:98:98:98. That way, we only have to remember
> our prefix and the IPv4 address, increasing IPv6 adoption rates.
> 
> Of course, when providing our network with IPv6 addresses by DHCP, this
> will become a bit of a challenge. I would not expect dnsmasq to support
> this very specific way of assigning IPv6 addresses, but I am wondering
> if others on the mailing list use a similar address format, and if so,
> how they have automated this. Especially as I would have to link the
> IPv6 and IPv4 addresses on the DHCP side.
> 
> Ideas are welcome.
> 


According to RFC 4291 Para 2.2, a mixed representation is possible, for
instance ipv6-mapped IPv4 addresses can be written as

::.1.2.3.4

So you could use something like 2a01:ac00::$something:98.98.98.98

and not have problems if octets in your address are greater than 99.

Dnsmasq uses the standard libc address-parsing functions which should
support this format, BUT the option parsing code may have difficulty
recognizing such addresses as IPv6 addresses, I shall take a look..



Simon.




Dnsmasq uses that standard libc address parsing functions, so such addresses

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Dnsmasq-controller for Kubernetes

2020-04-23 Thread Simon Kelley
I have no experience of Kubernetes, but this sure looks useful to my
untrained eye, thanks.

Simon.



On 21/04/2020 11:44, kvaps wrote:
> Hi, I'm using Dnsmasq in Kubernetes as DNS- and DHCP-server to organize
> network-booting server farm for long time.
> 
> At this moment I glad to introduce dnsmasq-controller for Kubernetes, to
> dynamically reconfigure dnsmasq any time when new hosts and
> Netboot-servers added.
> 
> Dnsmasq-controller also uses leader election to prevent running multiple
> DHCP-servers in one time.
> 
> Hopefully you'll find this useful:
> https://github.com/kvaps/dnsmasq-controller/
> 
> - kvaps
> 
> ___
> 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] No DHCPOffer back but DHCPDiscover is being received by UML machine

2020-04-23 Thread Simon Kelley
Ok, so Josh ran the strace and sent me the results as requested.

The interesting bit us here.

recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(68),
sin_addr=inet_addr("0.0.0.0")}, msg_namelen=16,
msg_iov=[{iov_base="\1\1\6\0\310\261\311+\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\366\226}H"...,
iov_len=548}], msg_iovlen=1, msg_control=[{cmsg_len=24,
cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO,
cmsg_data={ipi_ifindex=if_nametoindex("eth0"),
ipi_spec_dst=inet_addr("192.168.1.1"),
ipi_addr=inet_addr("255.255.255.255")}}], msg_controllen=24,
msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 300
recvmsg(4, {msg_namelen=16}, 0) = -1 EAGAIN (Resource
temporarily unavailable)



The first call to recvmsg has the MSG_PEEK and MSG_TRUNC flags set.
MSG_TRUNC causes the result to be the actual length of the received
packet, even if it's longer than  supplied buffer (548) and MSG_PEEK is
defined as:


 MSG_PEEK
   This  flag  causes the receive operation to return data from the
   beginning of the receive queue without removing that  data  from
   the queue.  Thus, a subsequent receive call will return the same
   data.

So this allows the buffer to be expanded if necessary and then recvmsg
gets called again when the buffer is big enough, to actually get the
data and remove it from the queue. In this case the packet is 300 bytes
long and the buffer is already 548 bytes, so no expansion is needed, we
just do the call again, without the MSG_PEEK|MSG_TRUNC flags. That's the
second call to recvmsg, which returns EAGAIN - the socket is
no-blocking, and this return says there's no packet queued. It looks
like the kernel is ignoring the MSG_PEEK flag, and dequeueing the data
on the first call.

I think this is a kernel bug.

Josh, does this work with an older kernel or with a real network device,
rather than the UML virtual device? It would be good to work out where
the regression happened.


Simon.

On 16/04/2020 15:40, Josh H wrote:
> 
> First, answer a simple question the answer to which I may have missed.
> Is dnsmasq logging the receipt of DHCPDISCOVER messages? Can we see the
> whole log showing that?
> 
> 
> Based on the config I provided at the initial message, I have the log
> file writing to /var/log/dnsmasq.log. This is the whole content of that
> file:
> 
> root@dns:~# cat /var/log/dnsmasq.log
> Apr 16 15:36:50 dnsmasq[1695]: started, version 2.80 DNS disabled
> Apr 16 15:36:50 dnsmasq[1695]: compile time options: IPv6 GNU-getopt
> DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> loop-detect inotify dumpfile
> Apr 16 15:36:50 dnsmasq-dhcp[1695]: DHCP, IP range 192.168.1.3 --
> 192.168.1.8, lease time 12h
> 
> No mention of the DHCPDiscover being acknowledged.
> 
> The next stage is to run dnsmasq under strace (check back here if you
> need instructions on that) and see what system calls it's making.
> 
> 
> What command would I need to run for this? And what service is best to
> upload the strace result, pastebin?
> 
> Thanks,
> Josh 
> 
> On Thu, 16 Apr 2020 at 12:49, Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> 
> 
> On 15/04/2020 19:27, Josh H wrote:
> 
> > It's difficult for me to share the config outright as I'm using a
> > modified version of netkit that I've updated to a much newer kernel
> > - http://netkit-ng.github.io/. The netkit version that is available on
> > that link is the one that worked with dnsmasq just fine, and that
> > version was 2.62 and kernel 3.2. However I've updated it and am
> running
> > 2.80 and kernel 5.6. 
> >
> > Anything else I can provide you with that might help? It's a very
> unique
> > setup so I appreciate  it's probably not the easiest thing to try and
> > debug. 
> >
> 
> First, answer a simple question the answer to which I may have missed.
> Is dnsmasq logging the receipt of DHCPDISCOVER messages? Can we see the
> whole log showing that?
> 
> The next stage is to run dnsmasq under strace (check back here if you
> need instructions on that) and see what system calls it's making.
> 
> 
> Simon.
> 
> 
> ___
> 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
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Failure of dnsmasq v2.81 in docker (qemu emulated armhf hardware)

2020-04-19 Thread Simon Kelley
On 19/04/2020 06:19, Dominik wrote:
> On Wed, 2020-04-15 at 21:34 +0200, Dominik wrote:
>> A possible solution seems to be what Petr Gotthard suggested
>> (dnsmasq-discuss /Thu Mar 19 13:16:11 GMT 2020/):
>>
>>> +#ifdef NETLINK_NO_ENOBUFS
>>>setsockopt(daemon->netlinkfd, SOL_NETLINK,
>>> NETLINK_NO_ENOBUFS, , sizeof(opt)) == -1 ||
>>> +#endif
> 
> Patch attached which restored dnsmasq operation for us.
> 
> Have a nice weekend!
> Best regards,
> Dominik
> 

Hmm, leaving aside that the patch, if NETLINK_NO_ENOBUFS is not defined
in the system headers, stops calling  getsockname() on kernels older
than 2.6.30, this isn't really much of a fix. The presence or absence of
NETLINK_NO_ENOBUFS in the system headers is only coincidentally related
to whether qemu-user supports the syscall.

The best we can do is to convert the setsockopt() failure into a warning
rather than a hard failure, or fix qemu-user, of course.



http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=913fa15fb1d11f50aeb7a9a1f68de5af0eac0419


Simon.





___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] No DHCPOffer back but DHCPDiscover is being received by UML machine

2020-04-18 Thread Simon Kelley
On 16/04/2020 15:40, Josh H wrote:
> 
> First, answer a simple question the answer to which I may have missed.
> Is dnsmasq logging the receipt of DHCPDISCOVER messages? Can we see the
> whole log showing that?
> 
> 
> Based on the config I provided at the initial message, I have the log
> file writing to /var/log/dnsmasq.log. This is the whole content of that
> file:
> 
> root@dns:~# cat /var/log/dnsmasq.log
> Apr 16 15:36:50 dnsmasq[1695]: started, version 2.80 DNS disabled
> Apr 16 15:36:50 dnsmasq[1695]: compile time options: IPv6 GNU-getopt
> DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> loop-detect inotify dumpfile
> Apr 16 15:36:50 dnsmasq-dhcp[1695]: DHCP, IP range 192.168.1.3 --
> 192.168.1.8, lease time 12h
> 
> No mention of the DHCPDiscover being acknowledged.
> 
> The next stage is to run dnsmasq under strace (check back here if you
> need instructions on that) and see what system calls it's making.
> 
> 
> What command would I need to run for this? And what service is best to
> upload the strace result, pastebin?


sudo strace -o /tmp/logfile /usr/bin/dnsmasq -d


Probably best to email the result to me direct.



Cheers,

Simon.

> 
> Thanks,
> Josh 
> 
> On Thu, 16 Apr 2020 at 12:49, Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> 
> 
> On 15/04/2020 19:27, Josh H wrote:
> 
> > It's difficult for me to share the config outright as I'm using a
> > modified version of netkit that I've updated to a much newer kernel
> > - http://netkit-ng.github.io/. The netkit version that is available on
> > that link is the one that worked with dnsmasq just fine, and that
> > version was 2.62 and kernel 3.2. However I've updated it and am
> running
> > 2.80 and kernel 5.6. 
> >
> > Anything else I can provide you with that might help? It's a very
> unique
> > setup so I appreciate  it's probably not the easiest thing to try and
> > debug. 
> >
> 
> First, answer a simple question the answer to which I may have missed.
> Is dnsmasq logging the receipt of DHCPDISCOVER messages? Can we see the
> whole log showing that?
> 
> The next stage is to run dnsmasq under strace (check back here if you
> need instructions on that) and see what system calls it's making.
> 
> 
> Simon.
> 
> 
> ___
> 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
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] No DHCPOffer back but DHCPDiscover is being received by UML machine

2020-04-16 Thread Simon Kelley


On 15/04/2020 19:27, Josh H wrote:

> It's difficult for me to share the config outright as I'm using a
> modified version of netkit that I've updated to a much newer kernel
> - http://netkit-ng.github.io/. The netkit version that is available on
> that link is the one that worked with dnsmasq just fine, and that
> version was 2.62 and kernel 3.2. However I've updated it and am running
> 2.80 and kernel 5.6. 
> 
> Anything else I can provide you with that might help? It's a very unique
> setup so I appreciate  it's probably not the easiest thing to try and
> debug. 
> 

First, answer a simple question the answer to which I may have missed.
Is dnsmasq logging the receipt of DHCPDISCOVER messages? Can we see the
whole log showing that?

The next stage is to run dnsmasq under strace (check back here if you
need instructions on that) and see what system calls it's making.


Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] No DHCPOffer back but DHCPDiscover is being received by machine

2020-04-14 Thread Simon Kelley


On 14/04/2020 18:51, Josh H wrote:
> Hi there,
> 
> I'm receiving no DHCPOffer back from my DHCPDiscover. However, I can
> tcpdump the machine running dnsmasq and it is receiving the DHCPOffer
> packets. 
> 
> Here's my very very simple dnsmasq.conf
> # To disable dnsmasq's DNS server functionality.
> port=0
> 
> # To enable dnsmasq's DHCP server functionality.
> dhcp-range=192.168.1.3,192.168.1.8,255.255.255.240,12h
> 
> # Set gateway as Router. Following two lines are identical.
> #dhcp-option=option:router,192.168.0.1
> dhcp-option=3,192.168.0.1
> 
> # Set DNS server as Router.
> dhcp-option=6,192.168.0.1
> 
> # Logging.
> log-facility=/var/log/dnsmasq.log   # logfile path.
> log-async
> log-queries # log queries.
> log-dhcp    # log dhcp related messages.
> 
> Here's the contents of /var/log/dnsmasq.log after running dhclient on a
> machine connected to the subnet:
> Apr 14 18:36:57 dnsmasq[1702]: started, version 2.80 DNS disabled
> Apr 14 18:36:57 dnsmasq[1702]: compile time options: IPv6 GNU-getopt
> DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> loop-detect inotify dumpfile
> Apr 14 18:36:57 dnsmasq-dhcp[1702]: DHCP, IP range 192.168.1.3 --
> 192.168.1.8, lease time 12h
> 

So, nothing logged indicating that the DHCPDiscover has been recieved?
If not, my guess would be an iptables rules blocking incoming packets
sent to 255.255.255.255.

> I can see the service running with netstat -anp4:
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address           Foreign Address        
> State       PID/Program name    
> udp        0      0 0.0.0.0:67             
>  0.0.0.0:*                           1702/dnsmasq        
> udp        0      0 0.0.0.0:1701           
>  0.0.0.0:*                           1607/xl2tpd         
> 
> There are no firewalls setup anywhere on my network for the moment. I
> have been able to get isc-dhcp-server to successfully allocate DHCP
> requests just fine however, so I don't think it's anything broken with
> DHCP in general. I'm running Linux kernel 5.6.2 and using dnsmasq from
> Debian Bullseye.

Working on ISC but not dnsmasq reinforces my diagnosis: dhcpd bypasses
iptables for such packets, dnsmasq doesn't.



Cheers,

Simon.


> 
> Hopefully someone can work out my issue!
> Thank you very much!
> 
> ___
> 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] Prefix delegation with DNSmasq

2020-04-12 Thread Simon Kelley
I'd split your /56 into as many /64s as you need, and set up routing as
required (either static or using some routing daemon). Run dnsmasq
centrally, and use DHCpv6 relays to proxy DHCPv6 requests from the
router on each /64 network back to the central dnsmasq instance.

Simon.


On 12/04/2020 18:20, Oliver Freyermuth wrote:
> Am 12.04.20 um 19:01 schrieb Simon Kelley:
>> The first question is, how static are your global addresses? Making a
>> network which can survive renumbering is a lot more difficult than one
>> with known and fixed addresses.
> 
> Luckily, they are completely static :-). 
> 
> Cheers,
>   Oliver
> 
>>
>>
>> Simon.
>>
>>
>>
>> On 12/04/2020 17:20, Oliver Freyermuth wrote:
>>> Dear DNSmasqers,
>>>
>>> I have a setup in mind and wonder whether dnsmasq is the correct tool 
>>> (since I have not found the necessary functionality in the documentation 
>>> yet). 
>>>
>>> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless 
>>> autoconfiguration) in several /64 networks. 
>>> There are several subnets (currently NATed IPv4), such as — for example — a 
>>> WireGuard VPN network, or a local isolated subnet. 
>>> While with IPv4, the answer was the use of private addresses and NAT every 
>>> time, potentially using a DHCP fowarder, for IPv6, the answer should be to 
>>> use Global Unicast addresses everywhere (right?). 
>>> How do I approach this correctly? 
>>>
>>> Three options come to mind to handle such subnets:
>>> - Use ULAs and NAT (but that does not feel like IPv6...). 
>>> - Delegate a prefix from the large network (where we'd use dnsmasq) to the 
>>> "gateway" machine, which then would be a router. 
>>>   However, I am not aware if dnsmasq can delegate prefixes? 
>>> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure 
>>> if that scales well to a larger number of machines? 
>>> - Use static routes on the central machine which send the /64 subnet to the 
>>> "gateways" and use dnsmasq on the gateways. 
>>>   Am I missing something here, or should that "just work"?
>>>
>>> Is anybody aware of a best-practice guide here (please RTFM me)? Is dnsmasq 
>>> the correct tool? 
>>>
>>> Cheers and thanks for any guidance,
>>> Oliver
>>>
>>> ___
>>> 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] Prefix delegation with DNSmasq

2020-04-12 Thread Simon Kelley
The first question is, how static are your global addresses? Making a
network which can survive renumbering is a lot more difficult than one
with known and fixed addresses.


Simon.



On 12/04/2020 17:20, Oliver Freyermuth wrote:
> Dear DNSmasqers,
> 
> I have a setup in mind and wonder whether dnsmasq is the correct tool (since 
> I have not found the necessary functionality in the documentation yet). 
> 
> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless 
> autoconfiguration) in several /64 networks. 
> There are several subnets (currently NATed IPv4), such as — for example — a 
> WireGuard VPN network, or a local isolated subnet. 
> While with IPv4, the answer was the use of private addresses and NAT every 
> time, potentially using a DHCP fowarder, for IPv6, the answer should be to 
> use Global Unicast addresses everywhere (right?). 
> How do I approach this correctly? 
> 
> Three options come to mind to handle such subnets:
> - Use ULAs and NAT (but that does not feel like IPv6...). 
> - Delegate a prefix from the large network (where we'd use dnsmasq) to the 
> "gateway" machine, which then would be a router. 
>   However, I am not aware if dnsmasq can delegate prefixes? 
> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure if 
> that scales well to a larger number of machines? 
> - Use static routes on the central machine which send the /64 subnet to the 
> "gateways" and use dnsmasq on the gateways. 
>   Am I missing something here, or should that "just work"?
> 
> Is anybody aware of a best-practice guide here (please RTFM me)? Is dnsmasq 
> the correct tool? 
> 
> Cheers and thanks for any guidance,
>   Oliver
> 
> ___
> 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] Announce: dnsmasq-2.81

2020-04-11 Thread Simon Kelley
After 18 long months, tonight I released dnsmasq 2.81.

The next release should happen to a shorter timescale.

http://thekelleys.org.uk/dnsmasq/dnsmasq-2.81.tar.gz


Enjoy.

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts

2020-04-09 Thread Simon Kelley


On 09/04/2020 16:47, Jake Howard wrote:
> Hi,
> 
> Thanks for the clarification! Yeah definitely sounds like it's Docker's
> iptables /magic/ causing the issues here.
> 
> Any thoughts on a solve? Either on my end our a code change? Is using
> the destination address correct, or should it really be using the
> source? Configuration would probably help this one!

Using the destination address is definitely correct: the point of this
is to reply to the DNS query with an answer which is "nearest" to the
source of the DNS query, by returning the address of the interface the
query arrives on, and not the addresses of other interfaces within the
machine. If it changes to using the source address, then a whole slew of
cases which work now would break. Namely where the source of the query
is on another network and the path from the source to the host running
dnsmasq includes a router.

I don't know is the above is an issue for your use case. If not, an
option to use source addresses might make sense. Do you absolutely need
this to work, because of incomplete routing, or is it a minor
optimisation? If the former, completing the routing tables might be an
easier fix.


Simon.



> 
> Thanks,
> - Jake Howard
> 
> On Wed, 8 Apr 2020, at 16:44, Simon Kelley wrote:
>> On 06/04/2020 17:35, Jake Howard wrote:
>> > Hello,
>> > 
>> > Here's an info dump, which hopefully gives a bit more context:
>> > 
>> > Hosts file:
>> > 
>> > 192.168.1.200 some.domain
>> > 10.23.0.2 some.domain
>> > 
>> > Log entry:
>> > 
>> > Apr  6 17:03:58 dnsmasq[549]: query[A] some.domain from 192.168.1.92
>> > Apr  6 17:03:58 dnsmasq[549]: /hosts.conf some.domain is 192.168.1.200
>> > Apr  6 17:03:58 dnsmasq[549]: /hosts.conf some.domain is 10.23.0.2
>> > 
>> > 
>> > Local Shell:
>> > 
>> > $ dig some.domain @10.23.0.2 +short
>> > 192.168.1.200
>> > 10.23.0.2
>> > 
>> > $ dig some.domain @192.168.1.200 +short
>> > 192.168.1.200
>> > 10.23.0.2
>> > 
>> > (Local machine is on both the10. and 192.168. networks just fine)
>> > 
>> > Network setup inside the container (ip a):
>> > 
>> > 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
>> > group default qlen 1000
>> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> >     inet 127.0.0.1/8 scope host lo
>> >    valid_lft forever preferred_lft forever
>> > 121: eth0@if122:  mtu 1500 qdisc
>> > noqueue state UP group default
>> >     link/ether 02:42:ac:1c:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>> >     inet 172.28.0.2/16 brd 172.28.255.255 scope global eth0
>> >    valid_lft forever preferred_lft forever
>> > 
>> > Can't say i'm entirely sure what "destination address of the query" is,
>> > and how / why it differs from the source address shown in the log. If
>> > it's using the return address it can see, it's possible it's using the
>> > 172.28 address, and hence isn't switching correctly?
>> > 
>> > How is the destination address calculated, is there something I can do
>> > to make this work as needed? Alternatively, is something in dnsmasq not
>> > playing correctly?
>> > 
>> > Thanks!
>>
>> The destination address is the address after @ in your dig commands. The
>> query has source address 192.168.1.92 (that's what's logged) and
>> destination address 10.23.0.2 or  192.168.1.200 which were the packet
>> gets delivered to. It's that which is used to do the localisation in
>> dnsmasq.
>>
>> The problem is that neither of those addresses appears on the interface,
>> that's 172.28.0.2. So all that scary iptables stuff from docker that Dan
>> posted above is rewriting the source address of the packets originally
>> to  either addresse to 172.28.0.2 and in the process, loosing the
>> information which dnsmasq could use to distinguish them.
>>
>> Simon.
>>
>>
>>
>> > 
>> > On Sun, 5 Apr 2020, at 21:49, Simon Kelley wrote:
>> >>
>> >>
>> >> On 05/04/2020 14:48, Jake Howard wrote:
>> >> >>
>> >> >> Dnsmasq uses the _destination_ address of the query. I'm not
>> familiar
>> >> >> with Docker. Is it using NAT?
>> >> > 
>> >> > Can't say i'm especially familiar with Docker's networking stack,
>> but it
>> >> > definitely looks and feels like something NAT-ish to me!
>> >> > Int

Re: [Dnsmasq-discuss] [PATCH] src/dnsmasq.c: Labeled a lonely #endif

2020-04-06 Thread Simon Kelley
On 05/04/2020 17:07, Geert Stappers wrote:
> diff --git a/src/dnsmasq.c b/src/dnsmasq.c
> index 0f73782..878167c 100644
> --- a/src/dnsmasq.c
> +++ b/src/dnsmasq.c
> @@ -2112,6 +2112,4 @@ int delay_dhcp(time_t start, int sec, int fd, uint32_t 
> addr, unsigned short id)
>  
>return 0;
>  }
> -#endif
> -
> - 
> +#endif /* HAVE_DHCP */

Patch applied. Thanks.

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts

2020-04-04 Thread Simon Kelley
On 31/03/2020 13:51, Jake Howard wrote:
> Hello!
> 
> Had a breakthrough on what's going on, and it's down to a caveat I
> missed when reading the man page on localise-queries:
> 
>> Return answers to DNS queries from /etc/hosts and *--interface-name*
> which depend on the interface over which the query was received.
> 
> And of course, this issue has to do with docker. With Docker, even
> though the container is listening on 2 different interfaces, and 2
> different IPs, the inner container, and thus dnsmasq, only sees 1
> interface, with all addresses coming from it. Hence localisation isn't
> quite working.
> 
> If I run dnsmasq with the exact same config but on the host, where it
> can see the different interfaces, works perfectly!
> 
> Testing was done in 2.79 and 2.76, with a config file practically
> identical to your CLI arguments.
> 
> Technically, there's not a bug here per-say, but it'd be really handy if
> there was a way of looking at the source IP when determining which
> record to return rather than just the interface?

Dnsmasq uses the _destination_ address of the query. I'm not familiar
with Docker. Is it using NAT?


Simon.


> 
> Thanks!
> 
> On Mon, 30 Mar 2020, at 20:42, Simon Kelley wrote:
>> On 28/03/2020 20:38, Jake Howard wrote:
>> > Hi,
>> > 
>> > My intention is to have 1 dnsmasq instance, accessible over 2 interfaces
>> > (listening on all), and have the response to a query differ based on the
>> > interface, and therefore its incoming IP. From what i've read, that's
>> > exactly what localise-queries is meant to do, but it doesn't appear to
>> > be unless I put the entries into /etc/hosts directly.
>>
>>
>> OK, what you're expecting to happen and what I'm expecting to happen are
>> the same. That's good.
>>
>> I just did a quick test, and it seems to work fine for me. The
>> example.com addresses are in /tmp/hosts.
>>
>>
>> srk@holly:~/dnsmasq/dnsmasq$ src/dnsmasq -d --log-queries
>> --localise-queries -p 1 --addn-hosts=/tmp/hosts
>> dnsmasq: started, version 2.81rc4-5-gd162bee cachesize 150
>> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n
>> no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC
>> loop-detect inotify dumpfile
>> dnsmasq: reading /etc/resolv.conf
>> dnsmasq: using nameserver 127.0.1.1#53
>> dnsmasq: read /etc/hosts - 9 addresses
>> dnsmasq: read /tmp/hosts - 2 addresses
>> dnsmasq: query[A] example.com from 127.0.0.1
>> dnsmasq: /tmp/hosts example.com is 192.168.151.43
>> dnsmasq: /tmp/hosts example.com is 192.168.150.43
>> dnsmasq: query[A] example.com from 192.168.150.49
>> dnsmasq: /tmp/hosts example.com is 192.168.150.43
>>
>>
>> If it's not working for you, that's a bug, but we need to find what it
>> is about your setup that tickles the bug.
>>
>> Can you boil it down to the simplest configuration that displays the
>> problem, and also specify which version of dnsmasq you're using?
>>
>>
>> cheers,
>>
>> Simon.
>>
>>
>> > 
>> > Thanks,
>> > - Jake Howard
>> > 
>> > On Sat, 28 Mar 2020, at 17:59, Simon Kelley wrote:
>> >> On 19/03/2020 21:47, Jake Howard wrote:
>> >> > Hello!
>> >> > 
>> >> > Is `localise-queries` meant to work against entries added via 
>> >> > `addn-hosts`? Querying a record returns both IPs, but always in the
>> >> same 
>> >> > order. The order is correctly fixed when the records are put in 
>> >> > `/etc/hosts` directly.
>> >>
>> >>
>> >> Yes, localise-queries  works with entries added via addn-hosts, but it
>> >> doesn't have anything to do with the order that records appear, so that
>> >> doesn't address your problem. What are you trying to achieve?
>> >>
>> >>
>> >> Simon.
>> >>
>> >>
>> >> > 
>> >> > Config:
>> >> > 
>> >> > ```
>> >> > localise-queries
>> >> > no-resolv
>> >> > cache-size=1
>> >> > log-queries
>> >> > log-facility=/var/log/pihole.log
>> >> > local-ttl=2
>> >> > log-async
>> >> > server=8.8.8.8
>> >> > server=8.8.4.4
>> >> > server=1.1.1.1
>> >> > server=1.0.0.1
>> >> > interface=eth0
>> >> > server=/use-application-dns.net/
>> >> > 
>> >

Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts

2020-03-30 Thread Simon Kelley
On 28/03/2020 20:38, Jake Howard wrote:
> Hi,
> 
> My intention is to have 1 dnsmasq instance, accessible over 2 interfaces
> (listening on all), and have the response to a query differ based on the
> interface, and therefore its incoming IP. From what i've read, that's
> exactly what localise-queries is meant to do, but it doesn't appear to
> be unless I put the entries into /etc/hosts directly.


OK, what you're expecting to happen and what I'm expecting to happen are
the same. That's good.

I just did a quick test, and it seems to work fine for me. The
example.com addresses are in /tmp/hosts.


srk@holly:~/dnsmasq/dnsmasq$ src/dnsmasq -d --log-queries
--localise-queries -p 1 --addn-hosts=/tmp/hosts
dnsmasq: started, version 2.81rc4-5-gd162bee cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n
no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC
loop-detect inotify dumpfile
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 127.0.1.1#53
dnsmasq: read /etc/hosts - 9 addresses
dnsmasq: read /tmp/hosts - 2 addresses
dnsmasq: query[A] example.com from 127.0.0.1
dnsmasq: /tmp/hosts example.com is 192.168.151.43
dnsmasq: /tmp/hosts example.com is 192.168.150.43
dnsmasq: query[A] example.com from 192.168.150.49
dnsmasq: /tmp/hosts example.com is 192.168.150.43


If it's not working for you, that's a bug, but we need to find what it
is about your setup that tickles the bug.

Can you boil it down to the simplest configuration that displays the
problem, and also specify which version of dnsmasq you're using?


cheers,

Simon.


> 
> Thanks,
> - Jake Howard
> 
> On Sat, 28 Mar 2020, at 17:59, Simon Kelley wrote:
>> On 19/03/2020 21:47, Jake Howard wrote:
>> > Hello!
>> > 
>> > Is `localise-queries` meant to work against entries added via 
>> > `addn-hosts`? Querying a record returns both IPs, but always in the
>> same 
>> > order. The order is correctly fixed when the records are put in 
>> > `/etc/hosts` directly.
>>
>>
>> Yes, localise-queries  works with entries added via addn-hosts, but it
>> doesn't have anything to do with the order that records appear, so that
>> doesn't address your problem. What are you trying to achieve?
>>
>>
>> Simon.
>>
>>
>> > 
>> > Config:
>> > 
>> > ```
>> > localise-queries
>> > no-resolv
>> > cache-size=1
>> > log-queries
>> > log-facility=/var/log/pihole.log
>> > local-ttl=2
>> > log-async
>> > server=8.8.8.8
>> > server=8.8.4.4
>> > server=1.1.1.1
>> > server=1.0.0.1
>> > interface=eth0
>> > server=/use-application-dns.net/
>> > 
>> > addn-hosts=/etc/vpn-hosts.conf
>> > localise-queries
>> > 
>> > ```
>> > 
>> > This is from pihole, but AFAIK that shouldn't make a difference if I'm 
>> > modifying the config directly.
>> > 
>> > Would appreciate some input, or being told i'm wrong!
>> > 
>> > Thanks,
>> > 
>> > - Jake Howard
>> > 
>> > 
>> > 
>> > 
>> > ___
>> > 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 mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH 1/1] Allow overriding of ubus service name.

2020-03-28 Thread Simon Kelley
Patch applied, thanks.


Simon.


On 20/03/2020 21:18, Oldřich Jedlička wrote:
> Same as for the dbus, allow specifying ubus service name (namespace) on
> the command line as an optional argument to --enable-ubus option.
> 
> Signed-off-by: Oldřich Jedlička 
> ---
>  man/dnsmasq.8 |  7 +--
>  src/config.h  |  1 +
>  src/dnsmasq.h |  1 +
>  src/option.c  | 14 +++---
>  src/ubus.c|  3 ++-
>  5 files changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
> index 2032a37..034e3cf 100644
> --- a/man/dnsmasq.8
> +++ b/man/dnsmasq.8
> @@ -366,10 +366,13 @@ been built with DBus support. If the service name is 
> given, dnsmasq
>  provides service at that name, rather than the default which is 
>  .B uk.org.thekelleys.dnsmasq
>  .TP 
> -.B --enable-ubus
> +.B --enable-ubus[=]
>  Enable dnsmasq UBus interface. It sends notifications via UBus on
>  DHCPACK and DHCPRELEASE events. Furthermore it offers metrics.
> -Requires that dnsmasq has been built with UBus support.
> +Requires that dnsmasq has been built with UBus support. If the service
> +name is given, dnsmasq provides service at that namespace, rather than
> +the default which is
> +.B dnsmasq
>  .TP
>  .B \-o, --strict-order
>  By default, dnsmasq will send queries to any of the upstream servers
> diff --git a/src/config.h b/src/config.h
> index b002560..7d08f7d 100644
> --- a/src/config.h
> +++ b/src/config.h
> @@ -50,6 +50,7 @@
>  #define RANDFILE "/dev/urandom"
>  #define DNSMASQ_SERVICE "uk.org.thekelleys.dnsmasq" /* Default - may be 
> overridden by config */
>  #define DNSMASQ_PATH "/uk/org/thekelleys/dnsmasq"
> +#define DNSMASQ_UBUS_NAME "dnsmasq" /* Default - may be overridden by config 
> */
>  #define AUTH_TTL 600 /* default TTL for auth DNS */
>  #define SOA_REFRESH 1200 /* SOA refresh default */
>  #define SOA_RETRY 180 /* SOA retry default */
> diff --git a/src/dnsmasq.h b/src/dnsmasq.h
> index f747868..b47ef74 100644
> --- a/src/dnsmasq.h
> +++ b/src/dnsmasq.h
> @@ -1063,6 +1063,7 @@ extern struct daemon {
>unsigned int duid_enterprise, duid_config_len;
>unsigned char *duid_config;
>char *dbus_name;
> +  char *ubus_name;
>char *dump_file;
>int dump_mask;
>unsigned long soa_sn, soa_refresh, soa_retry, soa_expiry;
> diff --git a/src/option.c b/src/option.c
> index 9ffd7fc..1f698da 100644
> --- a/src/option.c
> +++ b/src/option.c
> @@ -238,7 +238,7 @@ static const struct myoption opts[] =
>  { "caa-record", 1, 0 , LOPT_CAA },
>  { "dns-rr", 1, 0, LOPT_RR },
>  { "enable-dbus", 2, 0, '1' },
> -{ "enable-ubus", 0, 0, LOPT_UBUS },
> +{ "enable-ubus", 2, 0, LOPT_UBUS },
>  { "bootp-dynamic", 2, 0, '3' },
>  { "dhcp-mac", 1, 0, '4' },
>  { "no-ping", 0, 0, '5' },
> @@ -428,7 +428,7 @@ static struct {
>{ 'z', OPT_NOWILD, NULL, gettext_noop("Bind only to interfaces in use."), 
> NULL },
>{ 'Z', OPT_ETHERS, NULL, gettext_noop("Read DHCP static host information 
> from %s."), ETHERSFILE },
>{ '1', ARG_ONE, "[=]", gettext_noop("Enable the DBus interface 
> for setting upstream servers, etc."), NULL },
> -  { LOPT_UBUS, OPT_UBUS, NULL, gettext_noop("Enable the UBus interface."), 
> NULL },
> +  { LOPT_UBUS, ARG_ONE, "[=]", gettext_noop("Enable the UBus 
> interface."), NULL },
>{ '2', ARG_DUP, "", gettext_noop("Do not provide DHCP on this 
> interface, only provide DNS."), NULL },
>{ '3', ARG_DUP, "[=tag:]...", gettext_noop("Enable dynamic address 
> allocation for bootp."), NULL },
>{ '4', ARG_DUP, "set:,", gettext_noop("Map MAC address 
> (with wildcards) to option set."), NULL },
> @@ -1881,7 +1881,15 @@ static int one_opt(int option, char *arg, char 
> *errstr, char *gen_err, int comma
>else
>   daemon->dbus_name = DNSMASQ_SERVICE;
>break;
> -  
> +
> +case LOPT_UBUS: /* --enable-ubus */
> +  set_option_bool(OPT_UBUS);
> +  if (arg)
> + daemon->ubus_name = opt_string_alloc(arg);
> +  else
> + daemon->ubus_name = DNSMASQ_UBUS_NAME;
> +  break;
> +
>  case '8': /* --log-facility */
>/* may be a filename */
>if (strchr(arg, '/') || strcmp (arg, "-") == 0)
> diff --git a/src/ubus.c b/src/ubus.c
> index c7f6b19..5f81287 100644
> --- a/src/ubus.c
> +++ b/src/ubus.c
> @@ -38,7 +38,7 @@ static struct ubus_object_type ubus_object_type =
>UBUS_OBJECT_TYPE("dnsmasq", ubus_object_methods);
>  
>  static struct ubus_object ubus_object = {
> -  .name = "dnsmasq",
> +  .name = NULL,
>.type = _object_type,
>.methods = ubus_object_methods,
>.n_methods = ARRAY_SIZE(ubus_object_methods),
> @@ -94,6 +94,7 @@ void ubus_init()
>return;
>  }
>  
> +  ubus_object.name = daemon->ubus_name;
>ret = ubus_add_object(ubus, _object);
>if (ret)
>  {
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] NETLINK_NO_ENOBUFS not defined on old platforms

2020-03-28 Thread Simon Kelley
On 20/03/2020 02:18, Roy Marples wrote:
> On 19/03/2020 22:01, Simon Kelley wrote:
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0506a5ed4e56863627c54aedad30ad61221292ef
>>
>>
>>
>> should handle both old kernel header files and old kernels, in any
>> combination.
> 
> I really dislike this approach because it makes the assumption that no
> other symbol will take No 5.

Linux is pretty hot on ABI backwards compatibilty, so I doubt that there
has been any other netlink sockopt with number 5 in the past, or if that
sockopt disappears in the future any other opt would re-use it. Anyone
adding sockopts to a private kernel and picks the next free number,
rather than one at the end of the range or a defined private space needs
their bumps felt: it's obvious that it's going to clash with the
mainline kernel. I could #ifdef all the code if NETLINK_NO_ENOBUFS isn't
defined, and that would only lose us the ability to build against old
headers and still get the fix on a new enough kernel. It's probably not
a big loss, but it addresses a problem that seems unlikely.

Note that the code checks the kernel version, so if you build on old
headers and run on an old kernel, then despite the code assuming sockopt
5, it won't call setsockopt(5) when running on the old kernel.


This code is Linux-only, so what BSD does doesn't count.

Simon.


> 
> Whilst this might be true for generic linux, is it true for customised
> linux?
> Or to put it another way I can point to many examples cross BSD where
> the ioctls differ in number but not name.
> 
> You might take the view "So what? We just support generic linux.".
> 
> I have started to take the hard stance with Arch Linux which shipped
> latest kernel headers and support that on an old LTS kernel. It's not
> maintainable because I've had 3 instances where dhcpcd used to do this
> and then promptly crashed on newer kernels because they had customised
> headers.
> 
> Modern software should not need this hack. Either #ifdef around it or
> require userland headers to define it. Don't hardcode it as it's not
> userlands responsibility to do it.
> 
> See the similar case where OpenBSD removed a ioctl but let it in the
> header - even worse!!
> 
> Roy
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Nameserver dot

2020-03-28 Thread Simon Kelley
On 20/03/2020 14:29, William Edwards wrote:
>> This sounds like a bug, doing auth DNS without an auth-server statement
>> is a recent addition, and I probably forgot this effect on secondary
>> servers. Will take a look in the next day or two.
> 
> No worries. What's important to me is that only entries in 'auth-sec-servers' 
> are returned as NS records, being my public DNS servers.
> Thanks,
> William

I just pushed

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=b43585c34baf0c5eb478aa07423da534b2118536

which addresses this.

If --auth-server is a complete configuration

auth-server=dnsmasq.example.com,eth0

then dnsmasq.example.com will appear in the NS RRset and dnsmasq will
act as a nameserver for the domain on queries via eth0

IF instead, there's no interface or address specification, then the
domain will NO LONGER appear in the NS RRset, only the entries in
auth-sec-servers will. Under these circumstances, the only use made of
the domain in auth-server is to fill in the MNAME field in the SOA RR,
so it makes most sense for it to be the name of whichever of the
auth-sec-servers is acting as "primary".

That seems to make sense.

As a workaround, with 2.80, just pick which of your servers is primary
and remove it from the --auth-sec-servers list and add it as
--auth-server. Remember to undo that when you upgrade to 2.81


Cheers,

Simon.





> 
> 
> On 20/03/2020 08:25, William Edwards wrote:
>>
>>> Op 20 mrt. 2020 om 00:23 heeft Simon Kelley  het 
>>> volgende geschreven:
>>>
>>>> On 19/03/2020 17:23, William Edwards wrote:
>>>> Hi,
>>>>
>>>> I have auth-sec-servers set to:
>>>> 'auth-sec-servers=nsauth0.cyberfusion.nl,nsauth1.cyberfusion.be,nsauth2.cyberfusion.nu,nsauth3.cyberfusion.nl'
>>>>
>>>> These nameservers are shown, but I am also getting back an NS record
>>>> consisting of '.':
>>>>
>>>> ---
>>>> ;; ANSWER SECTION:
>>>> vlan5.hosts.cyberfusion.space. 600 IN NS nsauth1.cyberfusion.be.
>>>> vlan5.hosts.cyberfusion.space. 600 IN NS .
>>>> vlan5.hosts.cyberfusion.space. 600 IN NS nsauth0.cyberfusion.nl.
>>>> vlan5.hosts.cyberfusion.space. 600 IN NS nsauth2.cyberfusion.nu.
>>>> vlan5.hosts.cyberfusion.space. 600 INNSnsauth3.cyberfusion.nl.
>>>> --
>>>>
>>>> Where does 'NS .' come from?
>>>
>>> The --auth-server configuration, probably.  What does that look like?
>>
>> I did not specify an ‘auth-server’ directive. I did so, and now, the first 
>> NS record indeed is no longer a dot.
>>
>> This brings me to the next question: how do I prevent dnsmasq from even 
>> showing itself in NS records? dnsmasq will not answer queries to the 
>> internet.
>>
>>>
>>>
>>> Simon.
>>>
>>>
>>>>
>>>> Met vriendelijke groeten,
>>>>
>>>> William Edwards
>>>> T. 040 - 711 44 96
>>>> E. wedwa...@cyberfusion.nl
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>> ___
>>>> 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 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] Fwd: dnsmasq localise-queries + addn-hosts

2020-03-28 Thread Simon Kelley
On 19/03/2020 21:47, Jake Howard wrote:
> Hello!
> 
> Is `localise-queries` meant to work against entries added via 
> `addn-hosts`? Querying a record returns both IPs, but always in the same 
> order. The order is correctly fixed when the records are put in 
> `/etc/hosts` directly.


Yes, localise-queries  works with entries added via addn-hosts, but it
doesn't have anything to do with the order that records appear, so that
doesn't address your problem. What are you trying to achieve?


Simon.


> 
> Config:
> 
> ```
> localise-queries
> no-resolv
> cache-size=1
> log-queries
> log-facility=/var/log/pihole.log
> local-ttl=2
> log-async
> server=8.8.8.8
> server=8.8.4.4
> server=1.1.1.1
> server=1.0.0.1
> interface=eth0
> server=/use-application-dns.net/
> 
> addn-hosts=/etc/vpn-hosts.conf
> localise-queries
> 
> ```
> 
> This is from pihole, but AFAIK that shouldn't make a difference if I'm 
> modifying the config directly.
> 
> Would appreciate some input, or being told i'm wrong!
> 
> Thanks,
> 
> - Jake Howard
> 
> 
> 
> 
> ___
> 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] SOA serial increase

2020-03-28 Thread Simon Kelley
On 20/03/2020 11:15, William Edwards wrote:
> Hi Simon!
>> If you don't explicitly set the serial, then it should start at the
>> current epoch  time (ie seconds since 1/1/1970) which avoids the problem
>> unless you average more than one new DHCP lease per second.
> After setting 'auth-server', this behaviour has been 'fixed'.
> Without 'auth-server':
> --
> vlan5.hosts.cyberfusion.space. 600 IN    SOA    . . 1 1200 180 1209600 600
> --
> With 'auth-server':
> --
> vlan5.hosts.cyberfusion.space. 600 IN    SOA    
> vlan5.hosts.cyberfusion.space. hostmaster.vlan5.hosts.cyberfusion.space. 
> 1584702843 1200 180 1209600 600
> --
> So this seems like a combination of 1) possibly some room for improvement in 
> docs (there is little mention of serials there at all) and 2) working too 
> late at night.
> William


The forthcoming 2.81 release errors in startup is auth-server is not set
under these circumstances.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=08933475abd0580cff747e3d1e0db3865207a200


Cheers,

Simon.

> 
> On 20/03/2020 08:18, William Edwards wrote:
>>
>> Op 20 mrt. 2020 om 00:39 heeft Simon Kelley > <mailto:si...@thekelleys.org.uk>> het volgende geschreven:
>>
>>> On 19/03/2020 17:28, William Edwards wrote:
>>>> Hello,
>>>>
>>>> Does dnsmasq increase SOA serial when adding a new DNS record after DHCP
>>>> lease is requested?
>>>
>>> Yes.
>>>
>>>>
>>>> I am not sure because docs say '--auth-soa' allows for specifying serial.
>>>
>>> It does, but it's optional: dnsmasq will generate one for you. If you do
>>> specify a serial, it will still get incremented after a new DHCP lease
>>> is created.
>>
>> Thanks.
>>
>> I noticed that serial is reset back to 1 when dnsmasq is restarted. This
>> would cause the serial to be lower on dnsmasq than its slaves after a
>> restart, even when DHCP leases are handed out and DNS records are added.
>>
>> Is this intentional behaviour?
>>
>>>
>>>
>>> Cheers,
>>>
>>> Simon.
>>>
>>>>
>>>> Met vriendelijke groeten,
>>>>
>>>> William Edwards
>>>> T. 040 - 711 44 96
>>>> E. wedwa...@cyberfusion.nl <mailto:wedwa...@cyberfusion.nl>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> 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
>>>>
>>>
>>>
>>> ___
>>> 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
>>
>> ___
>> 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 mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] TFTP storage issue prevents other dnsmasq services (DHCP/DNS) to run

2020-03-26 Thread Simon Kelley
On 26/03/2020 09:15, Ercolino De Spiacico wrote:
> It seems like enabling TFTP like:
> 
> enable-tftp
> tftp-root=/mnt/usb/TFTP
> dhcp-boot=pxelinux.0,,192.168.0.1
> 
> But experiencing an system storage issue (usb failure, unable to mount,
> etc) takes the full dnsmasq down e.g. prevent from running at all
> 
> Can I suggest for dnmasq to take a softer approach when this happens and
> just skip the TFTP process execution rather than affect all the other
> internal services like DHCP and DNS?


This is much easier said than done, because file read/write can't be
done in a non-blocking way in Unix/Linux. AFAIK all ordinary files are
by definition  non-blocking, and if they do block on the underlying
device, that's just tough; there's no way to get your process scheduled
again until the drive returns data.

I think the lesson from this is: don't put any files dnsmasq accesses
(tftp sources, DHCP lease file, log files, configuration files) on
devices that may go away: copy the data to an internal drive.

> 
> More than else it's that "external factor" that sucks in this situation.


Agreed, and your message will lie in the list archive as a warning to
anyone else tripping over the same gotcha. That's a good thing.


Cheers,


Simon.

> 
> Thanks
> 
> ___
> 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] Still investigating delay on first dns query - more info

2020-03-26 Thread Simon Kelley
On 23/03/2020 13:25, Chris Green wrote:
> I'm still trying to work out why the first DNS query to dnsmasq
> running on a server on my LAN suffers a 5 second delay but subsequent
> requests don't see the delay.  
> 
> I'm running dnsmasq version 2.76 on a Raspberry Pi.  The systems
> seeing the delay when they send a query are (mostly) running xubuntu
> 19.10.
> 
> The delay only occurs when querying names on the LAN, requests for
> external names run normally.  It makes no difference whether I give a fully
> qualified name or just the machine name (the domain gets added by the
> 'search' option in /etc/resolv.con anyway).
> 
> It appears to be something to do with IPV6 and  records (or lack
> of them) that causes the issue but I'm still stumped as to how to fix
> it.  
> 
> Having set 'log-queries=extra' in /etc/dnsmasq.conf I see the
> following in /var/log/syslog when I query (using 'host') the name
> 'esprimo' twice from my laptop after booting (booting the laptop that
> is).
> 
> First 'host esprimo':-
> Mar 23 12:59:06 newdns dnsmasq[4256]: 54 192.168.1.92/56886 query[A] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 54 192.168.1.92/56886 /etc/hosts 
> esprimo.zbmc.eu is 192.168.1.3
> Mar 23 12:59:06 newdns dnsmasq[4256]: 55 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 55 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 56 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 56 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 57 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 57 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 58 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 58 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 59 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 59 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 60 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 60 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 61 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 61 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 62 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 62 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 63 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 63 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 64 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 64 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 65 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 65 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 66 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 66 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 67 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 67 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 68 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 68 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 69 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 69 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 70 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 70 192.168.1.92/37906 config 
> esprimo.zbmc.eu is NODATA-IPv6
> Mar 23 12:59:06 newdns dnsmasq[4256]: 71 192.168.1.92/37906 query[] 
> esprimo.zbmc.eu from 192.168.1.92
> Mar 23 12:59:06 newdns dnsmasq[4256]: 71 192.168.1.92/37906 config 
> 

Re: [Dnsmasq-discuss] Nameserver dot

2020-03-20 Thread Simon Kelley
This sounds like a bug, doing auth DNS without an auth-server statement
is a recent addition, and I probably forgot this effect on secondary
servers. Will take a look in the next day or two.

Simon.


On 20/03/2020 08:25, William Edwards wrote:
> 
>> Op 20 mrt. 2020 om 00:23 heeft Simon Kelley  het 
>> volgende geschreven:
>>
>>> On 19/03/2020 17:23, William Edwards wrote:
>>> Hi,
>>>
>>> I have auth-sec-servers set to:
>>> 'auth-sec-servers=nsauth0.cyberfusion.nl,nsauth1.cyberfusion.be,nsauth2.cyberfusion.nu,nsauth3.cyberfusion.nl'
>>>
>>> These nameservers are shown, but I am also getting back an NS record
>>> consisting of '.':
>>>
>>> ---
>>> ;; ANSWER SECTION:
>>> vlan5.hosts.cyberfusion.space. 600 IN NS nsauth1.cyberfusion.be.
>>> vlan5.hosts.cyberfusion.space. 600 IN NS .
>>> vlan5.hosts.cyberfusion.space. 600 IN NS nsauth0.cyberfusion.nl.
>>> vlan5.hosts.cyberfusion.space. 600 IN NS nsauth2.cyberfusion.nu.
>>> vlan5.hosts.cyberfusion.space. 600 INNSnsauth3.cyberfusion.nl.
>>> --
>>>
>>> Where does 'NS .' come from?
>>
>> The --auth-server configuration, probably.  What does that look like?
> 
> I did not specify an ‘auth-server’ directive. I did so, and now, the first NS 
> record indeed is no longer a dot.
> 
> This brings me to the next question: how do I prevent dnsmasq from even 
> showing itself in NS records? dnsmasq will not answer queries to the internet.
> 
>>
>>
>> Simon.
>>
>>
>>>
>>> Met vriendelijke groeten,
>>>
>>> William Edwards
>>> T. 040 - 711 44 96
>>> E. wedwa...@cyberfusion.nl
>>>
>>>
>>>
>>>  
>>>
>>> ___
>>> 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 mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] SOA serial increase

2020-03-20 Thread Simon Kelley
If you don't explicitly set the serial, then it should start at the
current epoch  time (ie seconds since 1/1/1970) which avoids the problem
unless you average more than one new DHCP lease per second.

Not sure which you are seeing it reseting to zero: no RTC and starting
dnsmasq before running NTP, maybe?


Simon.


On 20/03/2020 08:18, William Edwards wrote:
> 
> Op 20 mrt. 2020 om 00:39 heeft Simon Kelley  <mailto:si...@thekelleys.org.uk>> het volgende geschreven:
> 
>> On 19/03/2020 17:28, William Edwards wrote:
>>> Hello,
>>>
>>> Does dnsmasq increase SOA serial when adding a new DNS record after DHCP
>>> lease is requested?
>>
>> Yes.
>>
>>>
>>> I am not sure because docs say '--auth-soa' allows for specifying serial.
>>
>> It does, but it's optional: dnsmasq will generate one for you. If you do
>> specify a serial, it will still get incremented after a new DHCP lease
>> is created.
> 
> Thanks.
> 
> I noticed that serial is reset back to 1 when dnsmasq is restarted. This
> would cause the serial to be lower on dnsmasq than its slaves after a
> restart, even when DHCP leases are handed out and DNS records are added.
> 
> Is this intentional behaviour?
> 
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>>
>>> Met vriendelijke groeten,
>>>
>>> William Edwards
>>> T. 040 - 711 44 96
>>> E. wedwa...@cyberfusion.nl <mailto:wedwa...@cyberfusion.nl>
>>>
>>>
>>>
>>>  
>>>
>>> ___
>>> 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
>>>
>>
>>
>> ___
>> 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
> 
> ___
> 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] Nameserver dot

2020-03-19 Thread Simon Kelley
On 19/03/2020 17:23, William Edwards wrote:
> Hi,
> 
> I have auth-sec-servers set to:
> 'auth-sec-servers=nsauth0.cyberfusion.nl,nsauth1.cyberfusion.be,nsauth2.cyberfusion.nu,nsauth3.cyberfusion.nl'
> 
> These nameservers are shown, but I am also getting back an NS record
> consisting of '.':
> 
> ---
> ;; ANSWER SECTION:
> vlan5.hosts.cyberfusion.space. 600 IN NS nsauth1.cyberfusion.be.
> vlan5.hosts.cyberfusion.space. 600 IN NS .
> vlan5.hosts.cyberfusion.space. 600 IN NS nsauth0.cyberfusion.nl.
> vlan5.hosts.cyberfusion.space. 600 IN NS nsauth2.cyberfusion.nu.
> vlan5.hosts.cyberfusion.space. 600 IN    NS    nsauth3.cyberfusion.nl.
> --
> 
> Where does 'NS .' come from?

The --auth-server configuration, probably.  What does that look like?


Simon.


> 
> Met vriendelijke groeten,
> 
> William Edwards
> T. 040 - 711 44 96
> E. wedwa...@cyberfusion.nl
> 
> 
> 
>  
> 
> ___
> 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] SOA serial increase

2020-03-19 Thread Simon Kelley
On 19/03/2020 17:28, William Edwards wrote:
> Hello,
> 
> Does dnsmasq increase SOA serial when adding a new DNS record after DHCP
> lease is requested?

Yes.

> 
> I am not sure because docs say '--auth-soa' allows for specifying serial.

It does, but it's optional: dnsmasq will generate one for you. If you do
specify a serial, it will still get incremented after a new DHCP lease
is created.


Cheers,

Simon.

> 
> Met vriendelijke groeten,
> 
> William Edwards
> T. 040 - 711 44 96
> E. wedwa...@cyberfusion.nl
> 
> 
> 
>  
> 
> ___
> 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] NETLINK_NO_ENOBUFS not defined on old platforms

2020-03-19 Thread Simon Kelley
On 19/03/2020 21:01, Petr Gotthard wrote:
>> Thanks.
>>
>> FWIW in case it gets too silent
>>  resend the patch as `git format-patch` artifact
> 
> Oops, sorry. Let me resend it right away.

No need. I'm working on a slightly more elaborate alternative.


Simon.


> 
> 
>>From f669af70871b80ab7ecf250ea56160a3378f2d94 Mon Sep 17 00:00:00 2001
> From: Petr Gotthard 
> Date: Thu, 19 Mar 2020 21:47:28 +0100
> Subject: [PATCH] Fix build on old platforms without NETLINK_NO_ENOBUFS
> 
> ---
>  src/netlink.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/netlink.c b/src/netlink.c
> index a1ca5d1..0237b9c 100644
> --- a/src/netlink.c
> +++ b/src/netlink.c
> @@ -79,7 +79,9 @@ void netlink_init(void)
>  }
> 
>if (daemon->netlinkfd == -1 ||
> +#ifdef NETLINK_NO_ENOBUFS
>setsockopt(daemon->netlinkfd, SOL_NETLINK, NETLINK_NO_ENOBUFS, , 
> sizeof(opt)) == -1 ||
> +#endif
>getsockname(daemon->netlinkfd, (struct sockaddr *), ) == -1)
>  die(_("cannot create netlink socket: %s"), NULL, EC_MISC);
> 
> --
> 2.17.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


Re: [Dnsmasq-discuss] [PATCH 0/1] Fix resource leak on ubus_init failure.

2020-03-19 Thread Simon Kelley
On 18/03/2020 21:24, Oldřich Jedlička wrote:
> Hi,
> 
> This is my first patch here. I discovered one resource leak in ubus_init, when
> ubus_add_object fails - the ubus connection stays open. I added a patch, see
> follow-up email. (Hopefully git send-email sends it.)
> 
> Regards,
> Oldrich.
> 
> Oldřich Jedlička (1):
>   Fixed resource leak on ubus_init failure.
> 
>  src/ubus.c | 1 +
>  1 file changed, 1 insertion(+)
> 


Many thanks, patch applied.


Cheers,


Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] NETLINK_NO_ENOBUFS not defined on old platforms

2020-03-19 Thread Simon Kelley
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0506a5ed4e56863627c54aedad30ad61221292ef


should handle both old kernel header files and old kernels, in any
combination.



Cheers,

Simon.


On 19/03/2020 13:16, Petr Gotthard wrote:
> Hello,
> 
> The commit
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=1627d577af03cdf747285e79fa747b6aaae8033f
> 
> introduced NETLINK_NO_ENOBUFS, which is not available on some ancient 
> platforms (which are however still in use).
> 
> The build of 2.81rc4 fails on these platforms now.
> Would it be possible to have #ifdefs around that, please?
> 
> 
> Regards,
> Petr
> 
> diff -Nru dnsmasq-2.81rc4/src/netlink.c dnsmasq-2.81rc4.modified/src/netlink.c
> --- dnsmasq-2.81rc4/src/netlink.c   2020-03-19 13:54:37.804346907 +0100
> +++ dnsmasq-2.81rc4.modified/src/netlink.c  2020-03-19 13:53:14.868860449 
> +0100
> @@ -79,7 +79,9 @@
>  }
> 
>if (daemon->netlinkfd == -1 ||
> +#ifdef NETLINK_NO_ENOBUFS
>setsockopt(daemon->netlinkfd, SOL_NETLINK, NETLINK_NO_ENOBUFS, , 
> sizeof(opt)) == -1 ||
> +#endif
>getsockname(daemon->netlinkfd, (struct sockaddr *), ) == -1)
>  die(_("cannot create netlink socket: %s"), NULL, EC_MISC);
> 
> 
> ___
> 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] TTL in nested wild card CNAME

2020-03-18 Thread Simon Kelley


On 18/03/2020 00:30, Sasha Litvak wrote:
> Simon,
> 
> Hosts in domain .consul are resolved by DNS servers forwarding requests
> to a consul clusters.  I also have hard coded direct consul server
> records for .consul in dnsmasq config.  Nothing in /etc/hosts . Consul
> returns records with  TTL 0 .  I perhaps wrongly thought it meant they
> are not cached.  That is why I added ttl-min 5s.

That's you problem then. Make the .consul records TTL 5 and the problem
will go away. In TTLs, 0 is "forever".

S.

> 
> On Tue, Mar 17, 2020, 10:46 AM Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> On 17/03/2020 01:31, Sasha Litvak wrote:
> > I couldn't find a specific answer anywhere so hopefully someone has a
> > clue on this list
> >
> > We are using dnsmasq on our servers as a caching dns solution.
> >
> > Most of our domains are resolved by a wildcard record like this
> >
> > $TTL 3600       ; 1 hour
> >                         A       10.10.10.23
> > $ORIGIN example.net <http://example.net>.
> > *                       CNAME   excontainers
> > excontainers    CNAME   exservice.service.consul
> >
> > dnsmasq handles resolution of .consul domain directly but the DNS
> > server itself also forwards .consul to consul servers.
> ^
> 
> 
> Can you elaborate? How does dnsmasq handle the resolution of the .consul
> domain? If you have something like
> 
> 10.0.48.13 exservice.service.consul
> 
> in /etc/hosts
> 
> then that defines, effectively, an immortal record for
> exservice.service.consul, so a CNAME chain of two records, each with a
> TTL of one hour, would result in that answer being returned for an hour.
> 
> >
> > I added min-ttl 5s to decrease the number of queries to consul
> >
> > So when I do dig foo.example.net <http://foo.example.net> 
> @127.0.0.1 <http://127.0.0.1> I get
> >
> > foo.example.net <http://foo.example.net>. 3600 IN CNAME
> excontainers.example.net <http://excontainers.example.net>.
> > excontainers.example.net <http://excontainers.example.net>. 3600
> IN CNAME exservice.service.consul.
> > exservice.service.consul. 5 IN A 10.0.48.13
> 
> This might be misleading: is you do that query to dnsmasq with a clean
> cache, it will forward the query upstream, and return the complete
> result it gets, including the A record with a 5s TTL, but further
> queries from the cache would return a 0 (infinite) TTL for the A record
> of it's defined locally.
> 
> The fix for this is to define the .consul A record using --host-record,
> which allows you to specify the 5s TTL.
> 
> 
> 
> >
> > Now we often need to migrate subdomains by pointing them to a
> > different consul cluster.  So our script uses nsupdate and creates a
> > dynamic DNS record resulting in this reply
> >
> > foo.example.net <http://foo.example.net>. 60 IN CNAME 
> exservice2.service.consul.
> >  exservice2.service.consul. 5 IN A 10.0.48.35
> >
> > So we have a record that is more explicit and it takes precedence over
> > wild card.   On servers with little traffic, domain switch happens
> > within a few seconds, but on the main busy server with 100s of queries
> > a second, it takes an hour for dnsmasq to change its cache.  We see
> > dnsmasq sending requests to the DNS server getting correct new records
> > but still sending the old cached records to a client.
> >
> > When we are going back from distinct to default wild card (removing
> > distinct record in DNS) cache change happens almost immediately (a
> > couple of seconds) regardless of how busy the server is.
> >
> > Sorry for the long description but I would like to find out a reason
> > why during switching from wild card to more explicit record dnsmasq
> > cache update takes such a long time.
> >
> 
> I'm guessing at exactly what's going on here: more details would be
> useful, but if I guessed right, that's the solution.
> 
> 
> Simon.
> 
> 
> ___
> 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
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] stop-dns-rebind and IPv6

2020-03-17 Thread Simon Kelley
On 17/03/2020 21:48, Dominik wrote:
> Patch attached.


and applied. Thanks.

Simon.


> 
> On 17.03.20 21:54, Simon Kelley wrote:
>>
>> On 11/03/2020 07:55, Dominik wrote:
>>> Hey Buck,
>>>
>>> dnsmasq blocks all IPv4 address replies in the "private" subnets when 
>>> enabling stop-dns-rebind. For IPv6, it blocks only the IPv4-mapped address 
>>> ranges matching said private subnets.
>>>
>>> Neither ULAs nor LLs (link-locals) are blocked in the IPv6 range. I agree 
>>> this should be added.
>>>
>>> I can provide a patch for this, maybe tomorrow, if this is wanted. However, 
>>> I'm afraid it might already be too late for 2.81, cfm. Simon.
>> Apologies for that late reply. A patch sometime this week should be fine
>> for 2.81.
>>
>> Simon.
>>
>>> Best,
>>> Dominik
>>>
>>> Am 11. März 2020 00:47:02 MEZ schrieb buckh...@weibsvolk.org:
>>>> I am using dnsmasq version pi-hole-2.80 as embedded in Pi-hole, with my
>>>>
>>>> router set as its sole upstream server (server=192.168.178.1#53).
>>>>
>>>> When evaluating DNS rebind protection provided by dnsmasq (by adding 
>>>> stop-dns-rebind), I observed that dnsmasq correctly detects and 
>>>> suppresses IPv4 answers, but fails to do the same for IPv6 ULA
>>>> addresses 
>>>> (maybe even for IPv6 in general).
>>>>
>>>> E.g. "nslookup wpad.fritz.box" from a Windows client results in the 
>>>> following log entries:
>>>>
>>>> 09:58:08 dnsmasq[20063]: query[A] wpad.fritz.box from 192.168.178.200
>>>> 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
>>>> 09:58:08 dnsmasq[20063]: possible DNS-rebind attack detected: 
>>>> wpad.fritz.box
>>>> 09:58:08 dnsmasq[20063]: query[] wpad.fritz.box from
>>>> 192.168.178.200
>>>> 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
>>>> 09:58:08 dnsmasq[20063]: reply wpad.fritz.box is 
>>>> fd00::2ba:dcff:feca:fe00
>>>>
>>>> Shouldn't IPv6 ULA and link-local addresses also be suppressed?
>>>> Does dnsmasq exhibit this behaviour by intention, or could this be seen
>>>>
>>>> as a possible gap in rebind protection?
>>>>
>>>> Kind regards,
>>>>
>>>> Buck
>>>>
>>>>
>>>>
>>>> ___
>>>> 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] 'tidying' unused variable warnings

2020-03-17 Thread Simon Kelley
I'm inclined not to take these, on the grounds that complicated
preprocessor stuff is a greater evil than false-positive warnings on
unusual platforms for build configurations.

Simon.


On 10/03/2020 10:25, Kevin 'ldir' Darbyshire-Bryant wrote:
> Hi Simon,
> 
> Feel free to throw these patches away!  Prompted by the recent unused var 
> warning fixes when building on macos, I pondered if the warning suppression 
> was a bit too global.  Some warnings are prompted by not including some code 
> (e.g. DHCPV6 vs no DHCPV6) and I wondered if the warning suppression should 
> be made (inverse) conditional.  It means that if some future change genuinely 
> ends up with us not using a variable we will get a warning.
> 
> Probably done at the same time as the whitespace cleanup, if at all :-)
> 
> Cheers,
> 
> Kevin D-B
> 
> gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> ___
> 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] stop-dns-rebind and IPv6

2020-03-17 Thread Simon Kelley


On 11/03/2020 07:55, Dominik wrote:
> Hey Buck,
> 
> dnsmasq blocks all IPv4 address replies in the "private" subnets when 
> enabling stop-dns-rebind. For IPv6, it blocks only the IPv4-mapped address 
> ranges matching said private subnets.
> 
> Neither ULAs nor LLs (link-locals) are blocked in the IPv6 range. I agree 
> this should be added.
> 
> I can provide a patch for this, maybe tomorrow, if this is wanted. However, 
> I'm afraid it might already be too late for 2.81, cfm. Simon.

Apologies for that late reply. A patch sometime this week should be fine
for 2.81.

Simon.

> 
> Best,
> Dominik
> 
> Am 11. März 2020 00:47:02 MEZ schrieb buckh...@weibsvolk.org:
>> I am using dnsmasq version pi-hole-2.80 as embedded in Pi-hole, with my
>>
>> router set as its sole upstream server (server=192.168.178.1#53).
>>
>> When evaluating DNS rebind protection provided by dnsmasq (by adding 
>> stop-dns-rebind), I observed that dnsmasq correctly detects and 
>> suppresses IPv4 answers, but fails to do the same for IPv6 ULA
>> addresses 
>> (maybe even for IPv6 in general).
>>
>> E.g. "nslookup wpad.fritz.box" from a Windows client results in the 
>> following log entries:
>>
>> 09:58:08 dnsmasq[20063]: query[A] wpad.fritz.box from 192.168.178.200
>> 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
>> 09:58:08 dnsmasq[20063]: possible DNS-rebind attack detected: 
>> wpad.fritz.box
>> 09:58:08 dnsmasq[20063]: query[] wpad.fritz.box from
>> 192.168.178.200
>> 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
>> 09:58:08 dnsmasq[20063]: reply wpad.fritz.box is 
>> fd00::2ba:dcff:feca:fe00
>>
>> Shouldn't IPv6 ULA and link-local addresses also be suppressed?
>> Does dnsmasq exhibit this behaviour by intention, or could this be seen
>>
>> as a possible gap in rebind protection?
>>
>> Kind regards,
>>
>> Buck
>>
>>
>>
>> ___
>> 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] [PATCH] DHCPv6 - List or Range reservation for single host

2020-03-17 Thread Simon Kelley


On 10/03/2020 14:25, Petr Menšík wrote:


> That is a pity. Is there anything I can help to include it in 2.81? If
> you have any objections to part of it or whole concept, please say so. I
> would rebase the change again.
> 
> I was added to Fedora as downstream in late summer [1], have not yet
> seen any new bug related to it. It seems not broken entirely, maybe it
> just works.
> 
> Anyway, if there is anything I can do, please let me know. Feel free to
> add me into CC.
>>
>

Could you get me a rebased patch this week?

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

2020-03-17 Thread Simon Kelley
On 17/03/2020 01:31, Sasha Litvak wrote:
> I couldn't find a specific answer anywhere so hopefully someone has a
> clue on this list
> 
> We are using dnsmasq on our servers as a caching dns solution.
> 
> Most of our domains are resolved by a wildcard record like this
> 
> $TTL 3600   ; 1 hour
> A   10.10.10.23
> $ORIGIN example.net.
> *   CNAME   excontainers
> excontainersCNAME   exservice.service.consul
> 
> dnsmasq handles resolution of .consul domain directly but the DNS
> server itself also forwards .consul to consul servers.
^


Can you elaborate? How does dnsmasq handle the resolution of the .consul
domain? If you have something like

10.0.48.13 exservice.service.consul

in /etc/hosts

then that defines, effectively, an immortal record for
exservice.service.consul, so a CNAME chain of two records, each with a
TTL of one hour, would result in that answer being returned for an hour.

> 
> I added min-ttl 5s to decrease the number of queries to consul
> 
> So when I do dig foo.example.net  @127.0.0.1 I get
> 
> foo.example.net. 3600 IN CNAME excontainers.example.net.
> excontainers.example.net. 3600 IN CNAME exservice.service.consul.
> exservice.service.consul. 5 IN A 10.0.48.13

This might be misleading: is you do that query to dnsmasq with a clean
cache, it will forward the query upstream, and return the complete
result it gets, including the A record with a 5s TTL, but further
queries from the cache would return a 0 (infinite) TTL for the A record
of it's defined locally.

The fix for this is to define the .consul A record using --host-record,
which allows you to specify the 5s TTL.



> 
> Now we often need to migrate subdomains by pointing them to a
> different consul cluster.  So our script uses nsupdate and creates a
> dynamic DNS record resulting in this reply
> 
> foo.example.net. 60 IN CNAME  exservice2.service.consul.
>  exservice2.service.consul. 5 IN A 10.0.48.35
> 
> So we have a record that is more explicit and it takes precedence over
> wild card.   On servers with little traffic, domain switch happens
> within a few seconds, but on the main busy server with 100s of queries
> a second, it takes an hour for dnsmasq to change its cache.  We see
> dnsmasq sending requests to the DNS server getting correct new records
> but still sending the old cached records to a client.
> 
> When we are going back from distinct to default wild card (removing
> distinct record in DNS) cache change happens almost immediately (a
> couple of seconds) regardless of how busy the server is.
> 
> Sorry for the long description but I would like to find out a reason
> why during switching from wild card to more explicit record dnsmasq
> cache update takes such a long time.
> 

I'm guessing at exactly what's going on here: more details would be
useful, but if I guessed right, that's the solution.


Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] dnsmasq and option 78

2020-03-10 Thread Simon Kelley
The DHCP option parsing doesn't know about this option and can't cope
with it. The fallback is to just pass the value of the bytes which make
up the option  as hex, so for your example of


1,192.168.5.14

you'll need

dhcp-option-force=78,01:c0:a8:05:0e

It would be good to address such "mixed type" options, but that's for
future releases, the above is your only option for now.


Cheers,

Simon.


On 09/03/2020 12:09, Kristian Evensen wrote:
> Hello,
> 
> I am trying to configure dnsmasq to export DHCP option 78 (rfc2610) to
> the clients on my network, but I am struggling to make it work. My
> problems seems to be caused by the "Mandatory" byte that has to be
> part of the option.
> 
> My initial attempt was to add the following to dnsmasq.conf:
> dhcp-option-force=78,1,192.168.5.14
> 
> However, this caused dnsmasq to fail with the following error message:
> Mon Mar  9 11:55:55 2020 daemon.crit dnsmasq[3232]: bad IPv4 address
> at line 38 of /etc/dnsmasq.conf
> 
> I then tried to replace "1" with 0x01 and 1b, but in my packet capture
> I see that the values are sent as strings (so "0x01" and "1b"). I then
> tried to just add 1 (so dhcp-option-force=78,1), which worked in the
> sense that dnsmasq did not fail to start and an integer was sent to my
> client.
> 
> Has anyone managed to configure dnsmasq to export option 78 or know
> how to combine an integer with an address list? My router is running
> dnsmasq verson 2.80.
> 
> Thanks in advance for any 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] space two point eighty one

2020-03-08 Thread Simon Kelley
On 05/03/2020 21:05, Geert Stappers wrote:

> `git diff` is huge, almost 22000 lines.  Yes, a huge clean-up.
> 
> 
> I love to see that in the 2.81 release of dnsmasq.
> 
>  git commit -am "Removed useless whitespace" --author "Geert Stappers 
> "
> 
> 

I just spent a couple of hours playing with the options to GNU ident, to
see if I could get it to clean up not just whitespace but also any
identing other more subtle problems, on the grounds that if we're going
to make a huge formatting commit, we should do it just once.

My conclusion is that there is some stuff in there that needs to be
fixed, but I can't make ident work in a way where I'm happy to run it
automatically. I therefore plan to do this.

1) Run ident once over the code with the best options I have, then fix
up the small amount of stuff it does which I don't like (mainly
line-breaks). That should also remove trailing spaces and tabs and
trailing blank lines from files. I'll use Geerts scripts to make sure.

2) Commit that.

3) Add git hooks to expand or similar to keep the whitespace stuff clean
going forward.

This is not something I'm going  to do for 2.81, sorry Geert. It's too
big a change for this late in the cycle.


Cheers,

Simon.




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] Add DHCPv6 NTP server option handling

2020-03-08 Thread Simon Kelley
On 07/03/2020 00:02, Vladislav Grishenko wrote:
> 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.
> 

It's in for 2.81rc3


Cheers,

Simon.


> Hi Kevin,
> FYI
> 
> 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 mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

2020-03-08 Thread Simon Kelley
On 06/03/2020 22:10, Petr Menšík wrote:
> Hi Simon,
> 
> I have been adapting this feature to earlier releases and discovered one
> error with prefixed address assignment. When it is calculating number of
> addresses from prefixlen, it rotates only 32bit int instead of 64b uint.
> Only result is assigned to 64b variable.
> 
> Two examples:
> 
> dhcp-host=[2000::1230:0:0/92],correct-prefix
> dhcp-host=[2000::1234:5678:0/92],incorrect-prefix
> 
> If prefix length is lower than 96, the result is zero. It means
> incorrect-prefix is not refused as it should. Fix is simple, attaching
> patch with it. Just rotate 64b int. It is just minor issue, but would be
> nice to fix it before 2.81 is released.
> 
> Thanks!
> 
>

Patch applied, thanks.


I'm well aware that there's some important work of yours to fix the
problem  of interfaces changing index which is not in 2.81. That's not
forgotten, but I need you assistance with it, and planned to defer to
2.82 (which will be much quicker than 2.81). If we can get it done now,
and you really want it in 2.81 then I'm not ruling that out.


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.81rc2 findings on macos

2020-03-08 Thread Simon Kelley
On 06/03/2020 09:52, Kevin 'ldir' Darbyshire-Bryant wrote:
> Hi Simon,
> 
> Some findings for you when building on 2.81rc2 on MacOS Catalina.  Don’t know 
> how much of this is new as I only tried it as an experiment :-)
> 
> This definitely looks wrong :-)
> 
> rfc3315.c:1711:28: warning: use of logical '&&' with constant operand 
> [-Wconstant-logical-operand]
> if (!(addr_list->flags && ADDRLIST_DECLINED)
> 
> 
> $ make
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c cache.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c rfc1035.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c util.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c option.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c forward.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c network.c
> network.c:786:23: warning: unused parameter 'fd' [-Wunused-parameter]
> int tcp_interface(int fd, int af)
>   ^
> network.c:786:31: warning: unused parameter 'af' [-Wunused-parameter]
> int tcp_interface(int fd, int af)
>   ^
> network.c:1156:54: warning: unused parameter 'intname' [-Wunused-parameter]
> int local_bind(int fd, union mysockaddr *addr, char *intname, unsigned int 
> ifindex, int is_tcp)
>  ^
> 3 warnings generated.
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c dnsmasq.c
> dnsmasq.c:1862:9: warning: unused variable 'a' [-Wunused-variable]
> char a;
>  ^
> dnsmasq.c:1913:10: warning: unused variable 'a' [-Wunused-variable]
>   char a = 0;
>^
> 2 warnings generated.
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c dhcp.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c lease.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c rfc2131.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c netlink.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c dbus.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c bpf.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c helper.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c tftp.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c log.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c conntrack.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c dhcp6.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c rfc3315.c
> rfc3315.c:1711:28: warning: use of logical '&&' with constant operand 
> [-Wconstant-logical-operand]
> if (!(addr_list->flags && ADDRLIST_DECLINED) ||
>^  ~
> rfc3315.c:1711:28: note: use '&' for a bitwise operation
> if (!(addr_list->flags && ADDRLIST_DECLINED) ||
>^~
>&
> rfc3315.c:1711:28: note: remove constant to silence this warning
> if (!(addr_list->flags && ADDRLIST_DECLINED) ||
>   ~^~~~
> 1 warning generated.
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c dhcp-common.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c outpacket.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c radv.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c slaac.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c auth.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c ipset.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c domain.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c dnssec.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c blockdata.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c tables.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c loop.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c inotify.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c poll.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c rrfilter.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c edns0.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c arp.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c crypto.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c dump.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c ubus.c
> cc -Wall -W -O2   -DVERSION='"2.81rc2"'   -c metrics.c
> cc  -o dnsmasq cache.o rfc1035.o util.o option.o forward.o network.o 
> dnsmasq.o dhcp.o lease.o rfc2131.o netlink.o dbus.o bpf.o helper.o tftp.o 
> log.o conntrack.o dhcp6.o rfc3315.o dhcp-common.o outpacket.o radv.o slaac.o 
> auth.o ipset.o domain.o dnssec.o blockdata.o tables.o loop.o inotify.o poll.o 
> rrfilter.o edns0.o arp.o crypto.o dump.o ubus.o metrics.o
> 
> Cheers,
> 
> Kevin D-B
> 
> gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

Yes, the 

Re: [Dnsmasq-discuss] Performance statistics of upstream DNS servers?

2020-03-06 Thread Simon Kelley



On 06/03/2020 20:46, fiber...@mail.com wrote:
> Hi all!
> 
> Are performance statistics collected on DNS request responses from upstream 
> DNS servers?
> 
> For example if I configure 8.8.8.8 and 1.1.1.1 as DNS servers, can I look up 
> the statistics on how well (min/max/avg msecs) each of them are performing on 
> DNS requests?
> 

The cache sump (send SIGUSR1 to dnsmasq) tells you how many queries were
handled by each server, and how mant no-replies there were, but not timing.

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Feature request: add one DNS cache statistic

2020-03-05 Thread Simon Kelley
On 03/03/2020 09:03, Wim Nelis wrote:
> Hello,
> 
> 
> If the cache statistics are requested, the maximum cache size is
> returned together with the number of insertions and the number of
> deletions before expiration of the cache entry (live freed aka
> evictions). The request is to add preferably the actual cache size or
> alternatively the number of deletions due to expiration of the cache entry.
> 
> Currently one can only see that the cache is too small if the number of
> live freed entries becomes too large. The opposite, the cache is too
> big, is not visible. This can be advantageous to know in a
> resource-limited environment.
> 
> The suggested alternative is based on the assumption that the actual
> size equals the total insertions minus the live freed entries minus the
> expired freed entries.
> 
> 

I think what you probably need here is the maximum cache occupancy, ie
if entries are thrown out of the cache as soon as the expire, what is
the maximum number of cache entries, ever. Unfortunately, that's kind of
difficult to determine, because expired entries only get removed
opportunistically, unless there's pressure for cache space. The maximum
cache occupancy would include a load of already-expired entries which
will never be used again, but which have not been deleted because
finding them takes resources, and there's no need because we've not run
short of cache space.


Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] dnsmasq not returning A record for a CNAME with a server= config

2020-03-05 Thread Simon Kelley
On 04/03/2020 23:13, Jean-Francois Pirus wrote:
> The issue is as follows:
> 
> A CNAME returned by a server= specified upstream server does not return
> any A record to client even though DNS is setup correctly.
> (A record is from a different domain, not using the server= config)
> 
> dnsmasq server config:
> server=/example.private/X.X.X.X
> 
> On upstream server X.X.X.X DNS is setup as
> servername.example.private CNAME  servername.example.com.
> 
> On server Z.Z.Z.Z DNS is setup as
> servername.example.com A Y.Y.Y.Y
> 
> 
> Client queries dnsmasq server for servername.example.private
> ie:
> dig servername.example.private
> answer is 
> servername.example.private CNAME  servername.example.com.
> 
> Should be
> servername.example.private CNAME  servername.example.com.
> servername.example.com A Y.Y.Y.Y
> 
> Is there some setting I'm missing?
> 
> Thanks.
> 

This runs up against a significant limitation of dnsmasq: all the parts
of an answer have to come from the same source. This is mentioned in the
man page for local CNAME records, where it specifies that the CNAME
cannot point to a name which comes from an upstream server, which is a
example of the more general principle which you've run into: a CNAME
cannot point to a records which comes from a different server.


Sorry, but you'll either have to solve the problem another way, or use
another DNS server.


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] way to inject static host wireguard ip into dnsmasq.leases untill dhcp renewal

2020-03-05 Thread Simon Kelley
On 04/03/2020 18:54, Jelle de Jong wrote:
> Hello everybody,
> 
> I have a setup with wireguard vpn clients that sadly need a static IP.
> 
> I got a script running to detect if the host is connected.
> 
> I want to tell dnsmasq the IP of the host so I can use the dns resolve
> of dnsmasq as kind of lease.
> 
> Then when dnsmasq provides a DHCP IP to this host it should overwrite
> the IP again that was manually injected in dnsmasq.
> 
> So I do want it to work as a IP lease but let it rotate between the last
> active IP (DHCP from dnsmasq or static IP from wireguard).
> 
> Any sane we of doing this?
> 


Would the simplest way be to tell dnsmasq to lease static address when
the host does DHCP? Make your script update /etc/hosts and send SIGHUP
to dnsmasq to re-load it.


Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] space two point eighty one

2020-03-05 Thread Simon Kelley
On 05/03/2020 21:05, Geert Stappers wrote:
> On Thu, Mar 05, 2020 at 09:46:21PM +0100, Geert Stappers wrote:
>> Previous-Subject: Re: [Dnsmasq-discuss] Announce: dnsmasq-2.81rc1
>> In-Reply-To: <46b01ef6-df07-44ed-86ba-ccbd2efdb...@darbyshire-bryant.me.uk>
>> On Tue, Mar 03, 2020 at 09:07:15AM +, Kevin 'ldir' Darbyshire-Bryant 
>> wrote:
>>> On 3 Mar 2020, at 06:31, Geert Stappers  wrote:
>>>> On Mon, Mar 02, 2020 at 10:39:26PM +, Simon Kelley wrote:
>>>>>
>>>>> ... and let me know ... if there are any loose ends I missed.
>>>>>
>>>>
>>>> In 
>>>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013757.html
>>>> is
>>>>   int count, new;
>>>> -  struct dhcp_config *config, *candidate;
>>>> +  struct dhcp_config *config, *candidate;
>>>>   struct hwaddr_config *conf_addr;
>>>
>>> Not sure I understand the relevance Geert but as is common with these
>>> sort of non obvious replacements, there’s a ‘rogue’ white space
>>> at the end of the replaced line which is removed by its replacement.
>>  
>> Yes, that is the problem:  rogue white space is considered irrelevant
>>
>> I plea for removal of unneeded ' ' and ' '.
>>
>> That removal can be done with:
>>
>> sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
>> sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
>> sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
>> sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
>> sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
>> sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
>> sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
> 
> Numbers from output of `wc` increased.
> 
> 
>> sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
>> sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
> 
> Output of `wc` is stable.
> 
> At this point you probably want to do `git diff`
> and will see that trailing-space-only-lines are removed.
> 
> 
>> sed --in-place -e 's/^[ \t]*$//' src/*.c ; git diff | wc
> 
> Lines that had only spaces or tabs got that white space removed.
> 
>  
>> sed --in-place -e 's/^[ \t]*$//' src/*.c ; git diff | wc
>> sed --in-place -e 's/^[ \t]*$//' src/*.c ; git diff | wc
> 
> Output of `wc` is stable.
> 
> `git diff` is huge, almost 22000 lines.  Yes, a huge clean-up.
> 
> 
> I love to see that in the 2.81 release of dnsmasq.
> 
>  git commit -am "Removed useless whitespace" --author "Geert Stappers 
> "
> 
> 

The obvious problem with doing that is that for ever more, when I run
"git blame" 22000 lines will have the source "Removed useless whitespace".

I have a feeling someone once posted a solution to that, but I don't
have time to trawl back and find it. Can anyone help?


Simon.




signature.asc
Description: OpenPGP digital signature
___
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.81rc1

2020-03-05 Thread Simon Kelley
On 04/03/2020 22:29, Matthias Andree wrote:
> Am 02.03.20 um 23:39 schrieb Simon Kelley:
>> It's almost 18 months since the last release of dnsmasq, which is far
>> too long.
>>
>> I've done my best over the last couple of weeks to tie up loose-ends, so
>> that a 2.81 release can happen. There are ongoing development efforts,
>> but they may have to wait for the 2.82 release, which I intend to be
>> much sooner after 2.81.
>>
>> So, I've just tagged 2.81rc1, get it from git, or at
>>
>> http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.81rc1.tar.gz
>>
>> and let me know 1) if there are any showstopping bugs. or 2) there are
>> are any loose ends I missed.
>>
>> Once those, if any, are dealt with, we shall have a new release!
> 
> Simon,
> 
> good to see progress towards a new release.
> 
> Unfortunately, dnsmasq 2.81rc1 doesn't compile under FreeBSD OOTB, and I
> don't have much time to investigate run-time behaviour, so I hope the
> info below helps. The patches I use are at
> https://svnweb.freebsd.org/ports/head/dns/dnsmasq-devel/files, but the
> warning issue at the end of this email isn't fixed by them.
> 
> The SOL_TCP is non-portable and it also contradicts POSIX and Linux
> manpages, - unless we use SOL_SOCKET, we're supposed to use
> getprotoent(3) to get the magic number for "TCP level", whereas POSIX
> suggests to use IPPROTO_TCP.
> 
> Best read these error messages with a __fixed-width__ font.
> 
>> gmake[3]: Entering directory
>> '/usr/ports.svn/dns/dnsmasq-devel/work/dnsmasq-2.81rc1/src'
>> cc -O2 -pipe  -Wall -Wno-unused-value -Wno-unused-parameter
>> -Wno-unused-variable -Wno-unused-function -DHAVE_LIBIDN2 -DHAVE_DBUS
>> -DHAVE_LUASCRIPT -DHAVE_DNSSEC -I/usr/local/include -DLIBICONV_PLUG
>> -fstack-protector-strong -fno-strict-aliasing  -O2 -pipe  -Wall
>> -Wno-unused-value -Wno-unused-parameter -Wno-unused-variable
>> -Wno-unused-function -DHAVE_LIBIDN2 -DHAVE_DBUS -DHAVE_LUASCRIPT
>> -DHAVE_DNSSEC -I/usr/local/include -DLIBICONV_PLUG
>> -fstack-protector-strong -fno-strict-aliasing 
>> -DLOCALEDIR='"/usr/local/share/locale"' -DVERSION='"2.81rc1"'
>> -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include  
>> -I/usr/local/include   -I/usr/local/include  -I/usr/local/include
>> -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include 
>> -I/usr/local/include/lua52 -DLIBICONV_PLUG -c network.c    
>> network.c:731:22: error: use of undeclared identifier 'SOL_TCP'
>>   setsockopt(fd, SOL_TCP, TCP_FASTOPEN, , sizeof(qlen));
>>  ^
>> 1 error generated.
>> gmake[3]: ***
>> [/usr/ports.svn/dns/dnsmasq-devel/work/dnsmasq-2.81rc1/Makefile:161:
>> network.o] Error 1
> 


Thanks, I applied your patch verbatim.

> The other things appears to be an improper reference, config->addr6
> appears to be the union and not its member. First clang:
> 
>> cc -O2 -pipe  -Wall -Wno-unused-value -Wno-unused-parameter
>> -Wno-unused-variable -Wno-unused-function -DHAVE_LIBIDN2 -DHAVE_DBUS
>> -DHAVE_LUASCRIPT -DHAVE_DNSSEC -I/usr/local/include -DLIBICONV_PLUG
>> -fstack-protector-strong -fno-strict-aliasing  -O2 -pipe  -Wall
>> -Wno-unused-value -Wno-unused-parameter -Wno-unused-variable
>> -Wno-unused-function -DHAVE_LIBIDN2 -DHAVE_DBUS -DHAVE_LUASCRIPT
>> -DHAVE_DNSSEC -I/usr/local/include -DLIBICONV_PLUG
>> -fstack-protector-strong -fno-strict-aliasing 
>> -DLOCALEDIR='"/usr/local/share/locale"' -DVERSION='"2.81rc1"'
>> -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include  
>> -I/usr/local/include   -I/usr/local/include  -I/usr/local/include
>> -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include 
>> -I/usr/local/include/lua52 -DLIBICONV_PLUG -c rfc3315.c    
>> rfc3315.c:1193:44: error: member reference base type 'struct addrlist
>> *' is not a structure or union
>>     if (have_config(config, CONFIG_ADDR6) &&
>> IN6_ARE_ADDR_EQUAL(>addr6, ))
>> 
>> ^
>> /usr/include/netinet6/in6.h:232:17: note: expanded from macro
>> 'IN6_ARE_ADDR_EQUAL'
>>     (memcmp(&(a)->s6_addr[0], &(b)->s6_addr[0], sizeof(struct
>> in6_addr)) == 0)
>>  ~~~^ ~~~
>> 1 error generated.
> GCC words the error differently:
> 
>> rfc3315.c: In function 'dhcp6_no_relay':
>> rfc3315.c:1193:44: error: 'config->addr6' is a pointer; did you mean
>> to use '->'?
>>  1193 |   if (have_c

Re: [Dnsmasq-discuss] [PATCH] remove self assignment on variable creatrion on stack

2020-03-02 Thread Simon Kelley
On 02/03/2020 21:45, Donald Sharp wrote:
> In C when declaring a variable on the stack, it is assigned
> what ever happens to be on the stack at the place the variable
> is accessed in memory from previous usage.  Let's explicitly call out a
> value instead of using whatever happens to be on the stack
> at the point of creation of the sav value.
> 
> Signed-off-by: Donald Sharp 
> ---
>  src/util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/util.c b/src/util.c
> index f058c92..02aa76b 100644
> --- a/src/util.c
> +++ b/src/util.c
> @@ -560,7 +560,7 @@ int parse_hex(char *in, unsigned char *out, int maxlen,
> int j, bytes = (1 + (r - in))/2;
> for (j = 0; j < bytes; j++)
>   { 
> -   char sav = sav;
> +   char sav = 0;
> if (j < bytes - 1)
>   {
> sav = in[(j+1)*2];
> 

Assigning the variable to itself suppresses a false-positive compiler
warning, but any sane compiler will not emit any code for this.
Assigning zero to the variable will need code and execution time.

The existing code is arguably better, since it makes clear that the
value of sav at this point doesn't matter.

Simon.




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] Announce: dnsmasq-2.81rc1

2020-03-02 Thread Simon Kelley
It's almost 18 months since the last release of dnsmasq, which is far
too long.

I've done my best over the last couple of weeks to tie up loose-ends, so
that a 2.81 release can happen. There are ongoing development efforts,
but they may have to wait for the 2.82 release, which I intend to be
much sooner after 2.81.

So, I've just tagged 2.81rc1, get it from git, or at

http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.81rc1.tar.gz

and let me know 1) if there are any showstopping bugs. or 2) there are
are any loose ends I missed.

Once those, if any, are dealt with, we shall have a new release!


Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] dnsmasq using 100% of cpu

2020-03-02 Thread Simon Kelley
On 02/03/2020 22:00, Geert Stappers wrote:
> On Mon, Feb 17, 2020 at 08:32:49PM +0000, Simon Kelley wrote:
>>
>>
>> On 17/02/2020 13:31, Donald Sharp wrote:
>>> Running:
>>>
>>> sharpd@eva:~/dnsmasq$ /sbin/dnsmasq --version
>>> Dnsmasq version 2.80  Copyright (c) 2000-2018 Simon Kelley
>>> Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua
>>> TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
>>> 
>>>
>>> When I install several hundred thousand routes into the kernel and
>>> remove them( or some variation thereof ), dnsmasq eventually ends up
>>> running 100% cpu:
>>>
>>> top - 18:45:18 up 1 day,  7:44,  1 user,  load average: 2.70, 2.65, 2.34
>>> Tasks: 424 total,   3 running, 421 sleeping,   0 stopped,   0 zombie
>>> %Cpu(s): 12.1 us,  6.9 sy,  0.0 ni, 80.2 id,  0.0 wa,  0.0 hi,  0.7 si,
>>>  0.0 st
>>> MiB Mem :  32131.3 total,  19483.6 free,   6620.3 used,   6027.4 buff/cache
>>> MiB Swap:  32718.0 total,  31693.0 free,   1025.0 used.  24698.2 avail Mem
>>>
>>>     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+
>>> COMMAND                            
>>>  293183 nobody    20   0   11040   2040   1688 R  99.7   0.0 148:48.40
>>> dnsmasq        
>>>
>>> strace output:
>>>
>>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
>>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> ...
>>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=PO^Cstrace: Process 293183
>>> detached
>>>
>>> I can pretty much make this happen at will.  What can I provide to help
>>> debug this?
>>
>> The first thing I'd like to know is what file descriptor 4 is, providing
>> us with the first (say) 500 or 1000 lines of strace output would help
>> with that.
>>
>>
>>>
>>> As a side note, I was not placing these routes into the default linux
>>> routing table.  Does dnsmasq need to be paying attention to these routes?
>>>
>>
>>
>> To save typing I've just pasted a comment from the code which explains
>> why adding routes affects dnsmasq
>>
>>  /* We arrange to receive netlink multicast messages whenever the
>> network route is added.
>>  If this happens and we still have a DNS packet in the buffer,
>> we re-send it.
>>  This helps on DoD links, where frequently the packet which
>> triggers dialling is
>>  a DNS query, which then gets lost. By re-sending, we can avoid
>> the lookup
>>  failing. */
>>
>>
>> I suspect that  the solution to this is to restrict the above to the
>> "main" routing table.
>>
> 
> Matching that with "[PATCH] Ignore routes in non-main tables"
>  ( 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013824.html )
> 
> 


That's a good solution. Donald, if you could supply an answer to the
question about what fd 4 is, that would still be useful too.


Simon.
> 
> Regards
> Geert Stappers
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] option.c: fix NO_DHCP6 build error

2020-03-02 Thread Simon Kelley
Opps. Patch applied.



Cheers,

Simon.


On 02/03/2020 10:00, Kevin Darbyshire-Bryant wrote:
> Errors encountered if building with 'NO_DHCP6' introduced by
> commit 137286e9baecf6a3ba97722ef1b49c851b531810
> 
> option.c: In function 'dhcp_config_free':
> option.c:1040:24: error: 'struct dhcp_config' has no member named 'addr6'; 
> did you mean 'addr'?
> for (addr = config->addr6; addr; addr = tmp)
> ^
> addr
> option.c: In function 'one_opt':
> option.c:3227:7: error: 'struct dhcp_config' has no member named 'addr6'; did 
> you mean 'addr'?
>   new->addr6 = NULL;
>^
>addr
> 
> Wrap new code in ifdef HAVE_DHCP6
> 
> Signed-off-by: Kevin Darbyshire-Bryant 
> ---
>  src/option.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/option.c b/src/option.c
> index 6e8bb8b..f8ba616 100644
> --- a/src/option.c
> +++ b/src/option.c
> @@ -1036,6 +1036,7 @@ static void dhcp_config_free(struct dhcp_config *config)
>if (config->flags & CONFIG_CLID)
>  free(config->clid);
>  
> +#ifdef HAVE_DHCP6
>if (config->flags & CONFIG_ADDR6)
>   {
> struct addrlist *addr, *tmp;
> @@ -1046,6 +1047,7 @@ static void dhcp_config_free(struct dhcp_config *config)
> free(addr);
>   }
>   }
> +#endif
>  
>free(config);
>  }
> @@ -3227,7 +3229,9 @@ static int one_opt(int option, char *arg, char *errstr, 
> char *gen_err, int comma
>   new->netid = NULL;
>   new->filter = NULL;
>   new->clid = NULL;
> +#ifdef HAVE_DHCP6
>   new->addr6 = NULL;
> +#endif
>  
>   while (arg)
> {
> 
O

___
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

2020-03-02 Thread Simon Kelley
Indeed. Note that this (and ED448) will not actually be compiled in
until Nettle 3.6, which add support for them, is released and installed.

Cheers,

Simon.



On 02/03/2020 11:16, Vladislav Grishenko wrote:
> 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


Re: [Dnsmasq-discuss] [PATCH] Ignore routes in non-main tables

2020-03-02 Thread Simon Kelley
Patch applied. That looks like the best available solution. Thanks.


Simon.



On 02/03/2020 16:23, Donald Sharp wrote:
> Route lookup in Linux is bounded by `ip rules` as well
> as the contents of specific routing tables.  With the
> advent of vrf's(l3mdev's) non-default tables are regularly being
> used for routing purposes.
> 
> dnsmasq listens to all route changes on the box and responds
> to each one with an event.  This is *expensive* when a full
> BGP routing table is placed into the linux kernel, moreso
> when dnsmasq is responding to events in tables that it will
> never actually need to respond to, since dnsmasq at this
> point in time has no concept of vrf's and would need
> to be programmed to understand them.  Help alleviate this load
> by reducing the set of data that dnsmasq pays attention to
> when we know there are events that are not useful at this
> point in time.
> 
> Signed-off-by: Donald Sharp 
> ---
>  src/netlink.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/netlink.c b/src/netlink.c
> index b63e8b6..d59bf62 100644
> --- a/src/netlink.c
> +++ b/src/netlink.c
> @@ -360,7 +360,9 @@ static void nl_async(struct nlmsghdr *h)
>failing. */ 
>struct rtmsg *rtm = NLMSG_DATA(h);
>
> -  if (rtm->rtm_type == RTN_UNICAST && rtm->rtm_scope == RT_SCOPE_LINK)
> +  if (rtm->rtm_type == RTN_UNICAST && rtm->rtm_scope == RT_SCOPE_LINK &&
> +   (rtm->rtm_table == RT_TABLE_MAIN ||
> +rtm->rtm_table == RT_TABLE_LOCAL))
>   queue_event(EVENT_NEWROUTE);
>  }
>else if (h->nlmsg_type == RTM_NEWADDR || h->nlmsg_type == RTM_DELADDR) 
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Very slow load time on systems with a large `ulimit -n`

2020-03-02 Thread Simon Kelley
On 02/03/2020 08:32, Arthur Darcet wrote:
> Hello,
> 
> As discussed here: https://github.com/pi-hole/FTL/issues/703
> 
> At startup, dnsmasq tries to close all file descriptors from 0 to
> `ulimit -n` (the maximum number of open files) - here
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/dnsmasq.c;h=573aac069b75b801ad1ddf5305af5010ca1ab88a;hb=HEAD#l151
> 
> On setups where this limit is high, this takes a large amount of time -
> or even "hangs" indefinitely. Docker sets this limit to ~1M for instance
> - and the kubernetes setup I am using (k3s) is setting it to "Infinity",
> which translates to 1073741816.
> 
> I would suggest switching over to something based on the actually open
> files - like was done for the rpm package: cf
> https://bugzilla.redhat.com/show_bug.cgi?id=1537564 and
> https://github.com/rpm-software-management/rpm/pull/444/files for an
> actual patch
> 
> Work around is to run a `ulimit -n 1024` before starting dnsmasq - but
> that's not really a clean solution.
> 
> Thanks!
> Arthur
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


Thanks for the heads-up.


http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0541a1adf7c25356e7bbd792a8d6ee217a0d92f3

followed by

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=48755ebf093543113de96747a7f5f78e0640b333

fixes this, at least on Linux.

Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] conf-dir load order and strict-order directive

2020-02-29 Thread Simon Kelley
On 29/02/2020 13:59, Salatiel Filho wrote:
> Thanks, Simon. I found your commit at
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013693.html
> ( 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ab53883c94f94958e22077c79ba1dae1850a475e
> ) and patched 2.80 with it.
> It appears to work, but I noticed two problems:
> 
> The first:
> I have two files in confdir: 10-stubby.conf and 20-nextdns.conf
> 
> # cat /var/dnsmasq.d/10-stubby.conf
> server=127.0.0.1#5453
> strict-order
> no-resolv
> 
> # cat /var/dnsmasq.d/20-nextdns.conf
> server=127.0.0.1#5342
> strict-order
> no-resolv
> 
> 
> After restart dnsmasq , the log shows:
> Sat Feb 29 10:50:44 2020 daemon.info dnsmasq[17671]: using nameserver
> 127.0.0.1#5342
> Sat Feb 29 10:50:44 2020 daemon.info dnsmasq[17671]: using nameserver
> 127.0.0.1#5453
> 
> The order appears to be reversed. The 127.0.0.1#5342 is being used
> even though it is added by the 20-nextdns.conf ( which should be
> loaded after 10-stubby.conf)

It's definitely loading the files in the correct order, (I checked) but
note the definition of --strict-order

 -o, --strict-order
   By  default,  dnsmasq  will  send queries to any of the upstream
   servers it knows about and tries  to  favour  servers  that  are
   known  to  be  up.  Setting this flag forces dnsmasq to try each
   query with each server strictly in  the  order  they  appear  in
   /etc/resolv.conf
^^^

It makes no promises about anything not appearing in /etc/resolv.conf.
Maybe it should, but it doesn't. (Or maybe the whole, sorry option
should be removed.)


> 
> The second problem is:
> If I delete /var/dnsmasq.d/20-nextdns.conf and send a HUP signal,
> dnsmasq does not notice that file was deleted and keep using
> 127.0.0.1#5342. If I restart ( instead of reload/HUP) it will work as
> expected.
> If i send a USR1 signal ( after  deletion ) I still see:
> Sat Feb 29 10:56:19 2020 daemon.info dnsmasq[17671]: server
> 127.0.0.1#5342: queries sent 67, retried or failed 0
> Sat Feb 29 10:56:19 2020 daemon.info dnsmasq[17671]: server
> 127.0.0.1#5453: queries sent 0, retried or failed 0
> 
> 

That's expected. You might find that

--servers-file=
   A  special  case  of  --conf-file which differs in two respects.
   Firstly, only --server and --rev-server are allowed in the  con‐
   figuration  file included. Secondly, the file is re-read and the
   configuration therein is updated when dnsmasq receives SIGHUP.


Is more to your taste (but you can only specify one servers-file.)


Simon.


> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Atenciosamente/Kind regards,
> Salatiel
> 
> On Tue, Feb 11, 2020 at 7:51 AM Simon Kelley  wrote:
>>
>> In all the released versions of dnsmasq, the order in which the files in
>> a conf-dir are loaded is indeterminate.
>>
>> The next dnsmasq release changes this to alphabetic order.
>>
>>
>> Simon.
>>
>>
>> On 11/02/2020 00:44, Salatiel Filho wrote:
>>> I am trying to understand the behaviour of conf-dir parameter.
>>> Although I am running dnsmasq inside openwrt, this is more a dnsmasq
>>> question than openwrt question.
>>>
>>> I have conf-dir=/tmp/dnsmasq.d
>>> This directory CAN contain files or not. The files, when exists,  are
>>> created by  the init scripts of two other services  (nextdns and
>>> stubby)
>>> When nextdns it creates 20-nextdns.conf and send a SIGHUP to dnsmasq (
>>> reload ). The content of the conf file is:
>>>
>>> # cat /var/dnsmasq.d/20-nextdns.conf
>>> server=127.0.0.1#5342
>>> strict-order
>>> no-resolv
>>>
>>> >From this moment on , the new requests will use nextdns server as
>>> upstream (127.0.0.1 port 5432) as expected.
>>>
>>> Now if I start the stubby service, it will create
>>> /var/dnsmasq.d/30-stubby.conf and reload dnsmasq.
>>> # cat /var/dnsmasq.d/30-stubby.conf
>>> server=127.0.0.1#5453
>>> strict-order
>>> no-resolv
>>>
>>>
>>> Now we have two files inside the conf-dir.
>>>
>>>
>>> Question number 1: Since we have strict-order, what server should be
>>> used? The one from the 20-nextdns.conf or the one from 30-stubby.conf
>>> ?  I suppose the order is  alphabetical, right ?
>>>
>>> Now comes the odd part. If I stop nextdns, the init script will delete
>>> the /var/dnsmasq.d/20-nextdns.conf and reload dnsmasq. As expected,
>>> the only upstream server will be the one from 30-stubby.conf 

Re: [Dnsmasq-discuss] Remove DSA-NSEC3-SHA1 & DSA DNSSEC algorithm as this is set to status MUST NOT implement in RFC 8624

2020-02-27 Thread Simon Kelley
Looks sensible, I've pushed the equivalent, and removed the
now-redundant DSA signature verification code too.

Simon.



On 24/02/2020 07:08, Loganaden Velvindron wrote:
> 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] dhcp-script not being called with "del"

2020-02-26 Thread Simon Kelley
On 23/02/2020 19:41, William Edwards wrote:
> Hi,
> 
> I have a 'dhcp-script'. It is being called with "add" and "old" upon
> requesting DHCP lease, but when a lease expires, it is not called with
> "del".
> 
> To test, I changed lease time to 1 minute and kept an eye on
> /var/lib/misc/dnsmasq.leases . After 1 minute, the lease disappeared
> from /var/lib/misc/dnsmasq.leases (thus expired). However, the
> 'dhcp-script' was not called.
> 
> How could I start researching this issue?
> 

For a start, be aware the dnsmasq enforces a minimum time of two minutes
on DHCP leases, so what you think is happening may not actually be
happening.



Making your script something like

#!/bin/bash
echo $* >>/tmp/logfile
env >>/tmp/logfile

is useful to see what's going on.

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] Add new extensible D-Bus signal

2020-02-20 Thread Simon Kelley
On 13/02/2020 13:58, Victorien Molle wrote:
> Hello Simon,
> 
> this is not the final patch. I rewrote the way to build extensible dictionary 
> to be able to
> add a vendorclass n times when in IPv6 mode.
> 
> Moreover, as I don't really work with IPv6, I don't know if the IPv6 part of 
> the code is correct.
> I faced multiple issues:
> 1) I don't really know how to configure dhclient to send n vendorclass 
> identifiers

Neither do I, but it seems to be possible using  dhcpcd, search for
"vendclass" in the dhcpcd.conf manpage.

> 2) when requesting an IPv6 against DNSMasq, it does not always emit a D-Bus 
> signal, 
>even if I erase the content of /var/lib/misc/dnsmasq.leases

Wiping the lease database is not obvious, you need to stop dnsmasq,
erase /var/lib/misc/dnsmasq.leases then restart dnsmasq.


> 3) if there is an IPv6 entry in the leases file, DNSMasq will emit a D-Bus 
> signal
>when starting/restarting/reloading DNSMasq

I think that's true for IPv4 leases too. Dnsmasq calls the dhcp-script
with an "old" event for all existing leases when it restarts, and the
D-Bus signal is called under the same circumstances. It would be
possible to change this is it was not considered sensible.
> 
> About entries in the dictionary, I currently added the 'IP mode' (IPv6 or 
> not) to
> be able to correctly parse the dictionary outside of DNSMasq (by a program 
> which would
> receive the D-Bus signal). I also want to know if the method I used to 
> create/populate
> the dictionary is OK for you.
> To be honest, I don't really know what I can add to this dictionary, so tell 
> me what you
> want to include in it.

Look at the --dhcp-script entry in the man page. That has a
comprehensive list of all the data that's made available to the script
that gets run when a lease changes. The same data should go to the D-Bus
signal that happens for the same reason.

the queue_script() function in src/helper.c and the calls to
grab_extradata should give you information about how to access the
various fields.


Cheers,

Simon.

> 
> Regards,
> Victorien
> 
> On Thu, Feb 13, 2020 at 02:33:15PM +0100, Victorien Molle wrote:
>> For our usage, we need to have more informations sent over D-Bus such as the 
>> interface
>> name, the vendor class identifier and the lease expiration time.
>>
>> To achieve this, we add a new D-Bus signal "DhcpLeaseNotification" which 
>> exports the
>> requested informations as a dictionnary.
>> It also has the advantage to be flexible if someone wants to add a new entry 
>> in the
>> future.
>>
>> Note: in order to get leases extradata be populated, we enabled this feature 
>> if D-Bus
>> is enabled in configuration file (this was enabled in the past only if a 
>> script was
>> ran on leases updates).
>>
>> Here is an example of the obtained result with a Python3 program:
>>
>> ''' Define our D-Bus callback '''
>> def cb(action, ipaddr, hwaddr, hostname, info):
>> print(f'Action: {action}')
>> print(f'IP: {ipaddr}')
>> print(f'Hostname: {hostname}')
>> for k in info:
>> print(f'{k}: {info.get(k)}')
>>
>> ''' Connect to signal DhcpLeaseNotification on interface 
>> uk.org.thekelleys.dnsmasq '''
>> DNSMasq.listen('DhcpLeaseNotification', callback=cb)
>>
>> ''' Run GLib loop '''
>> GLib.MainLoop().run()
>>
>> ''' When DNSMasq receives a DHCP request, here is the result: '''
>>
>> Action: DhcpLeaseAdded
>> IP: 192.168.1.100
>> Hostname: Nucleus.nucle.us
>> interface: br-mgmt
>> expiration: 43200
>> ipv6: 0
>> vendor_class: LaGrosseBiche
>>
>> Signed-off-by: Victorien Molle 
>> ---
>>  dbus/DBus-interface |   9 ++
>>  src/dbus.c  | 215 +++-
>>  src/dnsmasq.h   |   4 +-
>>  src/lease.c |   6 +-
>>  src/rfc2131.c   |  12 +--
>>  5 files changed, 233 insertions(+), 13 deletions(-)
>>
>> diff --git a/dbus/DBus-interface b/dbus/DBus-interface
>> index 954c5b9..ed42551 100644
>> --- a/dbus/DBus-interface
>> +++ b/dbus/DBus-interface
>> @@ -273,14 +273,23 @@ DhcpLeaseAdded
>>  ---
>>  
>>  This signal is emitted when a DHCP lease for a given IP address is created.
>> +This will also trigger the DhcpLeaseNotification signal.
>>  
>>  DhcpLeaseDeleted
>>  
>>  
>>  This signal is emitted when a DHCP lease for a given IP address is deleted.
>> +This will also trigger the DhcpLeaseNotification signal.
>>  
>>  DhcpLeaseUpdated
>>  
>>  
>>  This signal is emitted when a DHCP lease for a given IP address is updated.
>> +This will also trigger the DhcpLeaseNotification signal.
>> +
>> +DhcpLeaseNotification
>> +-
>> +
>> +This signal is emitted when a DHCP lease action is triggered. It exports,
>> +as a dictionnary, more informations than the other signals.
>>   
>> diff --git a/src/dbus.c b/src/dbus.c
>> index c0ce903..468f393 100644
>> --- a/src/dbus.c
>> +++ b/src/dbus.c
>> @@ -55,6 +55,7 @@ const char* introspection_xml_template =
>>  "\n"
>>  "

Re: [Dnsmasq-discuss] dnsmasq using 100% of cpu

2020-02-20 Thread Simon Kelley
On 17/02/2020 14:37, Geert Stappers wrote:
> On 17-02-2020 14:31, Donald Sharp wrote:
> 
>> Running:
>>
>> sharpd@eva:~/dnsmasq$ /sbin/dnsmasq --version
>> Dnsmasq version 2.80  Copyright (c) 2000-2018 Simon Kelley
> 
> 2018,  no  short-git-hashes nor simular indicators on source version.
> 
> 
>> Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua
>> TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
>> 
>>
>> When I install several hundred thousand routes into the kernel and
>> remove them( or some variation thereof ), dnsmasq eventually ends up
>> running 100% cpu:
>>
>> top - 18:45:18 up 1 day,  7:44,  1 user,  load average: 2.70, 2.65, 2.34
>> Tasks: 424 total,   3 running, 421 sleeping,   0 stopped,   0 zombie
>> %Cpu(s): 12.1 us,  6.9 sy,  0.0 ni, 80.2 id,  0.0 wa,  0.0 hi,  0.7
>> si,  0.0 st
>> MiB Mem :  32131.3 total,  19483.6 free,   6620.3 used,   6027.4
>> buff/cache
>> MiB Swap:  32718.0 total,  31693.0 free,   1025.0 used.  24698.2 avail Mem
>>
>>     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+
>> COMMAND                            
>>  293183 nobody    20   0   11040   2040   1688 R  99.7   0.0 148:48.40
>> dnsmasq       
> 
> 
> The "CPU 100%" made me do  `git log` and a "find" on 'CPU'.  I found
> 
> 
> commit df6636bff61aa53ed7ad4b34d940805193c0bc74
> Author: Florent Fourcot 
> Date:   Mon Feb 11 17:04:44 2019 +0100
> 
>     lease: prune lease as soon as expired
>    
>     We detected a performance issue on a dnsmasq running many dhcp sessions
>     (more than 10 000). At the end of the day, the server was only releasing
>     old DHCP leases but was consuming a lot of CPU.
>    
>     It looks like curent dhcp pruning:
>  1) it's pruning old sessions (iterate on all current leases). It's
>  important to note that it's only pruning session expired since more
>  than one second
>  2) it's looking for next lease to expire (iterate on all current leases
>  again)
>  3) it launchs an alarm to catch next expiration found in step 2). This
>  value can be zero for leases just expired (but not pruned).
>    
>     So, for a second, dnsmasq could fall in a "prune loop" by doing:
>  * Not pruning anything, since difftime() is not > 0
>  * Run alarm again with zero as argument
>    
>     On a server with very large number of leases and releasing often
>     sessions, that can waste a very big CPU time.
>    
>     Signed-off-by: Florent Fourcot 
> 
> 
> 
> 
>>
>> strace output:
>>
>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
>>     
>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=PO^Cstrace: Process
>> 293183 detached
>>
>> I can pretty much make this happen at will.  What can I provide to
>> help debug this?
> 
> Start with stating how recent the source is that you are using.
> 
> 
>>
>> As a side note, I was not placing these routes into the default linux
>> routing table.  Does dnsmasq need to be paying attention to these routes?
> 
> Side notes in a separate thread  please.
> 
> 
>>
>> donald
>>
> 
> Regards
> 
> Geert Stappers
> 

Geert, you're confusing things. It's perfectly clear that the process is
running 100% CPU beacuse the poll() calls are returning an error which
the code is not expecting and doesn't handle. It just calls poll()
again, and because the error wasn't cleared, poll returns immediately
again, rinse and repeat.

The solution is to handle the error (it's not obvious to me how to do
that) or to avoid creating the error condition in the first place.

To get further, we need to know which socket is erroring. It's file
descriptor four in the strace, but is that the netlink socket, or a DHCP
socket or a socket used to talk DNS upstream, or DNS downstream. We
don't know  without further information.

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DNSSEC + No Cache not possible

2020-02-20 Thread Simon Kelley
On 17/02/2020 04:14, Marc Dirsus wrote:
> Reffering to this github issue it seems that dnsmasq cant disable
> caching when dnssec is enabled. I and other would love to see this
> changed. I have a unbound server installed and get statistics from there
> that ar way to low because pi-hole or better dnsmasq is caching before. 
> 
> i could disable dnssec but i dont want to do that and no one should
> disable this. 
> 
> https://github.com/pi-hole/FTL/issues/692
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

The cache is integral to DNSSEC validation because the validation
requires the use of a whole set of RRsets. The only way to have all
those RRsets is to put them in the cache.


It would be possible to have dnsmasq use the cache for DNSSEC
validation, but not to answer queries, but that doesn't seem like a
particularly useful thing to do.

A quick look at the dnsmasq man page shows that we're not afraid to add
options, but options really have to make sense and be useful to a
significant number of people, not just a way to remove an annoyance in
one installation. Your task, therefore, is to show that an option which
leaves the cache intact but disables it's use for answering queries, is
a generally useful feature.


Cheers,

Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] Say it is homemade when we can't tell

2020-02-20 Thread Simon Kelley
On 17/02/2020 21:10, Geert Stappers wrote:
> From: Geert Stappers 
> 
> bld/get-version yields UNKNOWN in case no tarball version
> or no git commit information is found.
> 
> That UNKNOWN does scare those who are not familiar
> with compling / building source code themself.
> 
> Replaced the scary string with HOMEMADE
> 
> Reported-by: Abhishek Patti 
> ---
>  bld/get-version | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bld/get-version b/bld/get-version
> index e472aab..71d92d5 100755
> --- a/bld/get-version
> +++ b/bld/get-version
> @@ -23,7 +23,7 @@ if which git >/dev/null 2>&1 && \
>  git describe | sed 's/^v//'
>  elif grep '\$Format:%d\$' $1/VERSION >/dev/null 2>&1; then
>  # unsubstituted VERSION, but no git available.
> -echo UNKNOWN
> +echo HOMEMADE
>  else
>   vers=`cat $1/VERSION | sed 's/[(), ]/,/ g' | tr ',' '\n' | grep ^v[0-9]`
>  
> 

I appreciate the thought, but is HOMEMADE more, or less likely to cause
confusion. At least UNKNOWN is always true, whilst a binary reporting
HOMEMADE may not be homemade at all.


Cheers,

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Wrong dhcp-renewal-time

2020-02-20 Thread Simon Kelley


On 20/02/2020 10:49, Andrija Panic wrote:
> Hi all,
> 
> first time posting to this ML.
> 
> We are using dnsmasq with CloudStack to provide DNS/DHCP services.
> 
> Recently we've changed the lease duration to 36250 days (98y, i.e.
> closer to infinity) to make sure that the clients will not renew its
> lease for a lng time (for reasons known to us).
> 
> Now, the lease time is sent fine to the client, but the
> dhcp-renewal-time and dhcp-rebinding-time are NOT set to 50% (87.5%) of
> the lease time, but instead to "only" ~650 days, which beats the purpose
> of us increasing it to 36250 days.
> 
> Can anyone advise what is happening and if this might be a known issue?
> 
> Here's an example from the log (dnsmasq version 2.76 on Debian 9)
> 
> root@r-3199-VM:~# cat /var/log/dnsmasq.log
> 
> |:|
> |Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 51
> lease-time 36250d|
> |Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 58
> T1 649d19h57m19s|
> 
> Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 59
> T2 649d19h57m20s
> 
> 
> Thanks,
> 
> -- 
> 
> Andrija Panić
> 

These times are 32-bit values, expressed in seconds, so I suspect that
your 98 years has overflowed the variable. Either that or the
end-of-lease time is after 2038, and you're running on a platform with
32bt time_t, and have overflowed that.

Instead of messing with very long lease times, why not just set the
lease time to "infinite", which should solve these problems.

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Odd DNS behaviour for www.freesat.co.uk

2020-02-17 Thread Simon Kelley



On 17/02/2020 18:19, Paul Martin wrote:
> dnsmasq 2.80 (Debian).
> 
> Performing an "A" query against www.freesat.co.uk returns the expected
> response on the first query.
> 
> However, the target of the CNAME is cached as a negative response,
> even though it was never looked up.  This could be considered a form
> of cache poisoning.
> 
> The problem could be that both A and CNAME records are returned by the
> domain's authoritative server and this is confusing dnsmasq's cache.
> 
> The DNS zone configuration here is definitely incorrect, but dnsmasq's
> behaviour in this instance is a concern.
> 
> Setting "no-negcache" in dnsmasq.conf works around this problem.
> 
> 
> 
> Feb 17 18:03:15 thinkpad dnsmasq[10582]: query[A] www.freesat.co.uk from 
> 127.0.0.1
> Feb 17 18:03:15 thinkpad dnsmasq[10582]: forwarded www.freesat.co.uk to 
> 1.1.1.1
> Feb 17 18:03:15 thinkpad dnsmasq[10582]: reply www.freesat.co.uk is 
> Feb 17 18:03:15 thinkpad dnsmasq[10582]: reply ghs.googlehosted.com is 
> NODATA-IPv4
> 
> Feb 17 18:05:51 thinkpad dnsmasq[10582]: query[A] www.freesat.co.uk from 
> 127.0.0.1
> Feb 17 18:05:51 thinkpad dnsmasq[10582]: cached www.freesat.co.uk is 
> Feb 17 18:05:51 thinkpad dnsmasq[10582]: cached ghs.googlehosted.com is 
> NODATA-IPv4
> 
> Feb 17 18:06:12 thinkpad dnsmasq[10582]: query[A] ghs.googlehosted.com from 
> 127.0.0.1
> Feb 17 18:06:12 thinkpad dnsmasq[10582]: cached ghs.googlehosted.com is 
> NODATA-IPv4
> 
> 
> 
> $ dig www.freesat.co.uk @ns1.peer1.net
> 
> ; <<>> DiG 9.11.14-3-Debian <<>> www.freesat.co.uk @ns1.peer1.net
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22745
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 2
> ;; WARNING: recursion requested but not available
> 
> ;; QUESTION SECTION:
> ;www.freesat.co.uk. IN  A
> 
> h;; ANSWER SECTION:
> www.freesat.co.uk.  300 IN  CNAME   ghs.googlehosted.com.
> www.freesat.co.uk.  300 IN  A   216.239.34.21
> www.freesat.co.uk.  300 IN  A   216.239.32.21
> www.freesat.co.uk.  300 IN  A   216.239.36.21
> www.freesat.co.uk.  300 IN  A   216.239.38.21
> 
> ;; AUTHORITY SECTION:
> freesat.co.uk.  259200  IN  NS  ns1.peer1.net.
> freesat.co.uk.  259200  IN  NS  ns2.peer1.net.
> 
> ;; ADDITIONAL SECTION:
> ns1.peer1.net.  21600   IN  A   69.90.13.5
> ns2.peer1.net.  21600   IN  A   69.90.13.6
> 
> ;; Query time: 12 msec
> ;; SERVER: 69.90.13.5#53(69.90.13.5)
> ;; WHEN: Mon Feb 17 17:42:57 GMT 2020
> ;; MSG SIZE  rcvd: 210
> 
> $ dig www.freesat.co.uk a
> 
> ; <<>> DiG 9.11.14-3-Debian <<>> www.freesat.co.uk a
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51256
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;www.freesat.co.uk. IN  A
> 
> ;; ANSWER SECTION:
> www.freesat.co.uk.  300 IN  CNAME   ghs.googlehosted.com.
> www.freesat.co.uk.  300 IN  A   216.239.36.21
> www.freesat.co.uk.  300 IN  A   216.239.34.21
> www.freesat.co.uk.  300 IN  A   216.239.38.21
> www.freesat.co.uk.  300 IN  A   216.239.32.21
> 
> ;; Query time: 14 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Feb 17 18:03:15 GMT 2020
> ;; MSG SIZE  rcvd: 144
> 
> $ dig www.freesat.co.uk a
> 
> ; <<>> DiG 9.11.14-3-Debian <<>> www.freesat.co.uk a
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24120
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;www.freesat.co.uk. IN  A
> 
> ;; ANSWER SECTION:
> www.freesat.co.uk.  144 IN  CNAME   ghs.googlehosted.com.
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Feb 17 18:05:51 GMT 2020
> ;; MSG SIZE  rcvd: 80
> 
> $ dig ghs.googlehosted.com a
> 
> ; <<>> DiG 9.11.14-3-Debian <<>> ghs.googlehosted.com a
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9646
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ghs.googlehosted.com.  IN  A
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Feb 17 18:06:12 GMT 2020
> ;; MSG SIZE  rcvd: 49
> 
> 
> 
> (I have already sent an email trying to get freesat.co.uk to fix their
> zone but suspect that it will fall on deaf ears.)
> 


It's pretty difficult to see what dnsmasq can do here, other than give
up on caching such negative data.

A reply _from_a_recursive_server_ which includes a CNAME, but 

Re: [Dnsmasq-discuss] dnsmasq using 100% of cpu

2020-02-17 Thread Simon Kelley


On 17/02/2020 13:31, Donald Sharp wrote:
> Running:
> 
> sharpd@eva:~/dnsmasq$ /sbin/dnsmasq --version
> Dnsmasq version 2.80  Copyright (c) 2000-2018 Simon Kelley
> Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua
> TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
> 
> 
> When I install several hundred thousand routes into the kernel and
> remove them( or some variation thereof ), dnsmasq eventually ends up
> running 100% cpu:
> 
> top - 18:45:18 up 1 day,  7:44,  1 user,  load average: 2.70, 2.65, 2.34
> Tasks: 424 total,   3 running, 421 sleeping,   0 stopped,   0 zombie
> %Cpu(s): 12.1 us,  6.9 sy,  0.0 ni, 80.2 id,  0.0 wa,  0.0 hi,  0.7 si,
>  0.0 st
> MiB Mem :  32131.3 total,  19483.6 free,   6620.3 used,   6027.4 buff/cache
> MiB Swap:  32718.0 total,  31693.0 free,   1025.0 used.  24698.2 avail Mem
> 
>     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+
> COMMAND                            
>  293183 nobody    20   0   11040   2040   1688 R  99.7   0.0 148:48.40
> dnsmasq        
> 
> strace output:
> 
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
> poll([{fd=3, events=POLLIN}, {fd=4, events=

Re: [Dnsmasq-discuss] [PATCH V2] Add new extensible D-Bus signal

2020-02-12 Thread Simon Kelley
On 11/02/2020 12:28, Victorien Molle wrote:
> Hi Simon, sorry for the late reply.
> 
> Here are my answers:
> 
> 1) This is because I prefer to work with integers and not strings.
> I personnaly prefer to declare enums for each action and then perform
> a boolean comparison instead of doing strings comparison.
> But I can use action strings if you prefer.

Definitely. You can't use those integers in the external DBus API unless
you define them, and having done that they can't be changed, so non-DBus
code is tied forever to the API. Make the notification type a string and
define it to be DhcpLeaseDeleted, DhcpLeaseAdded, or DhcpLeaseUpdated.

> 
> 2) 3) and 3a) I will look at it.
> 
> 4) Agree but I would like to be sure of one thing. At the start of
> DNSMasq, the start_time will be stored in the 'now' variable (line 240 of
> dnsmasq.c) and then in 'daemon->soa_sn' variable (line 253 of dnsmasq.c).
> Is it the right way to use daemon->soa_sn when calling the 'difftime' function
> outside of the 'main' function, or is there a better way to access to the 
> 'now'
> variable outside of the 'main' function?

daemon->soa_sn is not relevant to this. Don't use it. The now variable
gets updated each time the main loop is called, and passed as an
argument to any function that needs it. Just add time_t now as an
argument to emit_dbus_signal() and emit_dhcplease_notification().
emit_dbus_signal() is called from do_script_run() in lease.c which is
already passed the value of now as an argument.
> 
> 5) For now, I included data I need for my own usage but I can embed more
> data if necessary.

>From experience, if it's not done now, someone will want it in the
future. It's easier for everyone to try an pre-empt that whilst we can.



I know I'm in no position to complain about the time taken to get things
done, but I really am trying to tie up loose ends and get a 2.81 release
done, so it would be great to get a new patch fairly soon :) After all
this time it would be sad to be delaying waiting for this when 2.81 is
ready to go.

Cheers,

Simon.


> 
> Regards,
> Victorien
> 
> On Sun, Jan 26, 2020 at 11:52:35PM +, Simon Kelley wrote:
>> Sorry to keep pushing this back at you, but I looked in more detail and
>> there are things that are not yet right.
>>
>> 1) Why is the action the internal arbitrary integer? Wouldn't it be
>> better for this to be a string, deleted/added/updated or even the name
>> of the earlier signals; DhcpLeaseAdded etc which are in the action_str
>> variable already?
>>
>> 2) There is a few instances of code in dbus.c which have got wrapped with
>>
>> #if defined(HAVE_SCRIPT) || defined(HAVE_DBUS)
>>
>> which is pointless, since HAVE_DBUS must be defined otherwise the whole
>> file is omitted.
>>
>> 3) You're allocating a copy of the vendorclass but that's not necessary,
>> just past the pointer to the start of the extradata buffer.
>>
>> 3a) For an IPv6 lease, the vendorclass is different, see the code around
>> line 586 in src/helper.c and line 1783 in src/rfc3315.c, the extradata
>> buffer contains a (string) vendor-id first, and then some number of
>> vendor-class strings, the number is stored in lease->vendorclass_count.
>> Again, you don't need to copy these, just generate pointers into the
>> zero-delimited extradata buffer.
>>
>> 4) The lease expiration time is in unix epoch time, except sometimes it
>> isn't, if dnsmasq is compiled with   HAVE_BROKEN_RTC then it's in
>> seconds since last boot. The field name in the dictionary should at
>> least reflect this: but maybe it would be better to just provide the
>> time until lease expiration in seconds, that's always calculated the
>> same way: see helper.c line 788.
>>
>> 5) Question: there's lots of other data which is exported to the script,
>> as we now have an extensible way to export if via DBUS, should that data
>> be included in the DBus Dict?
>>
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>> On 23/01/2020 11:00, Victorien Molle wrote:
>>> For our usage, we need to have more informations sent over D-Bus such as 
>>> the interface
>>> name, the vendor class identifier and the lease expiration time.
>>>
>>> To achieve this, we add a new D-Bus signal "DhcpLeaseNotification" which 
>>> exports the
>>> requested informations as a dictionnary.
>>> It also has the advantage to be flexible if someone wants to add a new 
>>> entry in the
>>> future.
>>>
>>> Note: in order to get leases extradata be populated, we enabled this 
>>> feature if D-B

Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

2020-02-12 Thread Simon Kelley
On 10/02/2020 22:18, Harald Jensås wrote:
> On Mon, 2020-02-10 at 21:37 +0000, Simon Kelley wrote:
>> On 10/02/2020 17:56, Harald Jensås wrote:
>>> On Fri, 2020-02-07 at 21:27 +, Simon Kelley wrote:
>>>> Two commits in the repo, one adds arbitrary list of IPv6
>>>> addresses to
>>>> dhcp-host, second adds tags.
>>>>
>>>> Please  give them a whirl
>>>>
>>>
>>> Thank you for working on this Simon. I have tested the following
>>> configuration variations and there seem to be one small issue, but
>>> overall it is working nicely.
>>>
>>> The one test that fails is:
>>>
>>> * Use a prefix with wildcard address:
>>>   dhcp-host=52:54:00:3f:5c:c0,[::aa08/126],host1
>>>   Test: FAIL
>>>
>>>   In this configuration the first request succeeds, following
>>>   requests get 'no address available'. Looks like it does'nt try
>>>   the ::aa09 address when aa08 is already leased.
>>>
>>
>> Excellent. Thanks for the comprehensive testing. I just pushed the
>> fix
>> for this bug.
>>
> 
> Fantastic! I can confirm the last commit fixed the bug.
> 
> I also re-ran some of the other smoke tests and everything works as
> expected.
> 
> Thanks!
> 


That's great. I'm trying to catch up on all the loose ends and release
2.81 ASAP.


Cheers,

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Insecure DS reply warning - false positives?

2020-02-11 Thread Simon Kelley
On 13/05/2019 10:40, Kevin Darbyshire-Bryant wrote:
> Hi All,
> 
> Part of the reason for submitting 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013026.html 
> "[PATCH] dnssec: add hostname info to insecure DS warning” was to easily find 
> out what domain was prompting the warning.
> 
> Some of my mystery ‘Insecure DS reply’ turns out to be this:
> 
> Mon May 13 09:57:27 2019 daemon.warn dnsmasq[20911]: Insecure DS reply 
> received for 168.192.in-addr.arpa, check domain configuration and upstream 
> DNS server DNSSEC support
> Mon May 13 09:57:27 2019 daemon.warn dnsmasq[20911]: Insecure DS reply 
> received for 168.192.in-addr.arpa, check domain configuration and upstream 
> DNS server DNSSEC support
> Mon May 13 09:57:27 2019 daemon.warn dnsmasq[20911]: Insecure DS reply 
> received for 168.192.in-addr.arpa, check domain configuration and upstream 
> DNS server DNSSEC support
> Mon May 13 09:58:57 2019 daemon.warn dnsmasq[20911]: Insecure DS reply 
> received for 168.192.in-addr.arpa, check domain configuration and upstream 
> DNS server DNSSEC support
> Mon May 13 09:58:57 2019 daemon.warn dnsmasq[20911]: Insecure DS reply 
> received for 168.192.in-addr.arpa, check domain configuration and upstream 
> DNS server DNSSEC support
> Mon May 13 09:58:57 2019 daemon.warn dnsmasq[20911]: Insecure DS reply 
> received for 168.192.in-addr.arpa, check domain configuration and upstream 
> DNS server DNSSEC support
> 
> Is this a genuine configuration error on my/upstream’s part or is it false 
> positive log spam?
> 
> (I think) The relevant bits from dnsmasq config:
> 
> dnssec
> dnssec-check-unsigned
> 
> Upstream servers are Google’s 8.8.8.8 & friends.
> 
> Trust anchors:
> 
> trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
> trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
> 
> 

Continuing through the mail backlog from the missing months



I think the answer is that Google & friends block queries to the RFC
1918 ranges, and return locally generated (and not DNSSEC signed)
replies. Cloudflare even tells you.

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51064
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;168.192.in-addr.arpa.  IN  PTR

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   10800   IN  SOA nobody.invalid. nobody.invalid. 
1
3600 1200 604800 10800

;; ADDITIONAL SECTION:
explanation.invalid.10800   IN  TXT "Blocking is mandated by 
standards,
see references on
https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml;


Since these are not signed, validators try and check that's ok, by
proving that there is no DS record for 168.192.in-addr.arpa

If you go to the authoritative servers then that proof is indeed
available, but the DS queries get blocked by Google and cloudflare too,
so dnsmasq can't get at it. Hence it fails and gets upset.

The best you can do is tell dnsmasq never to forward such queries with

--server=/168.192.in-addr.arpa/

You should be able to do the same more nicely with

--rev-server=192.168.0.0/16

but that's broken for the "no server address" case. I just pushed a fix
for that.


Cheers,

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] Use instead of

2020-02-11 Thread Simon Kelley
On 28/04/2019 01:19, DDoSolitary wrote:
> The former should be used according to POSIX, otherwise it causes bunches of 
> warnings when compiling for musl-based distros like Alpine Linux.
> 
> /usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include 
>  to  [-Wcpp]
>  #warning redirecting incorrect #include  to 
>   ^~~
> Regards,
> DDoSolitary
> 
> 


Patch applied. Apologies for the long delay.


Simon.




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] dnssec: add hostname info to insecure DS warning

2020-02-11 Thread Simon Kelley
On 11/05/2019 18:05, Kevin Darbyshire-Bryant wrote:
> From: Kevin Darbyshire-Bryant 
> 
> Make the existing "insecure DS received" warning more informative by
> reporting the domain name reporting the issue.
> 
> This may help identify a problem with a specific domain or server
> configuration.
> 
> Signed-off-by: Kevin Darbyshire-Bryant 
> ---
>  src/dnssec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/dnssec.c b/src/dnssec.c
> index 9bf43a2..5e0686c 100644
> --- a/src/dnssec.c
> +++ b/src/dnssec.c
> @@ -873,7 +873,7 @@ int dnssec_validate_ds(time_t now, struct dns_header 
> *header, size_t plen, char
>
>if (rc == STAT_INSECURE)
>  {
> -  my_syslog(LOG_WARNING, _("Insecure DS reply received, do upstream DNS 
> servers support DNSSEC?"));
> +  my_syslog(LOG_WARNING, _("Insecure DS reply received for %s, check 
> domain configuration and upstream DNS server DNSSEC support"), name);
>rc = STAT_BOGUS;
>  }
>
> 

Patch applied. eventually!


Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] conf-dir load order and strict-order directive

2020-02-11 Thread Simon Kelley
In all the released versions of dnsmasq, the order in which the files in
a conf-dir are loaded is indeterminate.

The next dnsmasq release changes this to alphabetic order.


Simon.


On 11/02/2020 00:44, Salatiel Filho wrote:
> I am trying to understand the behaviour of conf-dir parameter.
> Although I am running dnsmasq inside openwrt, this is more a dnsmasq
> question than openwrt question.
> 
> I have conf-dir=/tmp/dnsmasq.d
> This directory CAN contain files or not. The files, when exists,  are
> created by  the init scripts of two other services  (nextdns and
> stubby)
> When nextdns it creates 20-nextdns.conf and send a SIGHUP to dnsmasq (
> reload ). The content of the conf file is:
> 
> # cat /var/dnsmasq.d/20-nextdns.conf
> server=127.0.0.1#5342
> strict-order
> no-resolv
> 
>>From this moment on , the new requests will use nextdns server as
> upstream (127.0.0.1 port 5432) as expected.
> 
> Now if I start the stubby service, it will create
> /var/dnsmasq.d/30-stubby.conf and reload dnsmasq.
> # cat /var/dnsmasq.d/30-stubby.conf
> server=127.0.0.1#5453
> strict-order
> no-resolv
> 
> 
> Now we have two files inside the conf-dir.
> 
> 
> Question number 1: Since we have strict-order, what server should be
> used? The one from the 20-nextdns.conf or the one from 30-stubby.conf
> ?  I suppose the order is  alphabetical, right ?
> 
> Now comes the odd part. If I stop nextdns, the init script will delete
> the /var/dnsmasq.d/20-nextdns.conf and reload dnsmasq. As expected,
> the only upstream server will be the one from 30-stubby.conf  (
> 127.0.0.1#5453 ). BUT if i start nextdns again, it will create the
> /var/dnsmasq.d/20-nextdns.conf again and reload dnsmasq again. But
> now, dnsmasq will not start using the dns from 20-nextdns.conf  (
> 127.0.0.1#5342 ). It will keep using the DNS from 30-stubby.conf (
> 127.0.0.1#5453).
> 
> Question 2: Shouldn't dnsmasq on reload respect the strict-order and
> start using the dns from 20-nextdns.conf instead of keeping using the
> one from 30-stubby.conf ?
> 
> Thanks!
> 
> 
> 
> 
> 
> 
> Atenciosamente/Kind regards,
> Salatiel
> 
> ___
> 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] DHCPv6 - List or Range reservation for single host

2020-02-10 Thread Simon Kelley
On 10/02/2020 17:56, Harald Jensås wrote:
> On Fri, 2020-02-07 at 21:27 +0000, Simon Kelley wrote:
>> Two commits in the repo, one adds arbitrary list of IPv6 addresses to
>> dhcp-host, second adds tags.
>>
>> Please  give them a whirl
>>
> 
> Thank you for working on this Simon. I have tested the following
> configuration variations and there seem to be one small issue, but
> overall it is working nicely.
> 
> The one test that fails is:
> 
> * Use a prefix with wildcard address:
>   dhcp-host=52:54:00:3f:5c:c0,[::aa08/126],host1
>   Test: FAIL
> 
>   In this configuration the first request succeeds, following
>   requests get 'no address available'. Looks like it does'nt try
>   the ::aa09 address when aa08 is already leased.
> 

Excellent. Thanks for the comprehensive testing. I just pushed the fix
for this bug.


Cheers,

Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Disabling AAAA records for a given domain

2020-02-09 Thread Simon Kelley
On 07/02/2020 15:13, Abhishek Patti wrote:
> Hi Everyone 
> 
> What is a recommended way to disable "" records for given domain
> using dnsmasq?
> 
> I have followed solution provided here
> - 
> https://discourse.pi-hole.net/t/solved-disable--response-for-a-given-domain/13143
>  but
> i notice dnsmasq still serving  records. 
> 

Is the domain in question a locally-defined one, or something which is
coming from upstream?


Simon.


> Thank you 
> 
> On Thu, Feb 6, 2020 at 4:05 AM
>  <mailto:dnsmasq-discuss-requ...@lists.thekelleys.org.uk>> wrote:
> 
> Send Dnsmasq-discuss mailing list submissions to
>         dnsmasq-discuss@lists.thekelleys.org.uk
> <mailto:dnsmasq-discuss@lists.thekelleys.org.uk>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> or, via email, send a message with subject or body 'help' to
>         dnsmasq-discuss-requ...@lists.thekelleys.org.uk
> <mailto:dnsmasq-discuss-requ...@lists.thekelleys.org.uk>
> 
> You can reach the person managing the list at
>         dnsmasq-discuss-ow...@lists.thekelleys.org.uk
> <mailto:dnsmasq-discuss-ow...@lists.thekelleys.org.uk>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dnsmasq-discuss digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: [PATCH] DHCPv6 - List or Range reservation for single
>       host (Simon Kelley)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 5 Feb 2020 12:10:50 +
> From: Simon Kelley  <mailto:si...@thekelleys.org.uk>>
> To: hjen...@redhat.com <mailto:hjen...@redhat.com>, Tore Anderson
> mailto:t...@fud.no>>,
>         dnsmasq-discuss@lists.thekelleys.org.uk
> <mailto:dnsmasq-discuss@lists.thekelleys.org.uk>
> Subject: Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range
>         reservation for single host
>     Message-ID:  <mailto:f3dfbe06-5e4a-3a51-5e4c-d45668618...@thekelleys.org.uk>>
> Content-Type: text/plain; charset=utf-8
> 
> On 04/02/2020 14:24, Harald Jens?s wrote:
> > On Tue, 2020-02-04 at 00:06 +, Simon Kelley wrote:
> >> I went though this carefully, and decided that replacing the address
> >> in
> >> the dhcp-host with the next free one, but otherwise treating things
> >> the
> >> same might not work well. For instance, there are places where the
> >> question is asked "is this address reserved in any dhcp-host?" and
> >> clearly that needs to be modified to answer "yes" to any of the
> >> addresses when there is more than one.
> >>
> >
> > I thought this was only the case for IPv4? I.e I did'nt see that check
> > for IPv6 and tought it deliberately allowed having the same IP address
> > in different host-entries? (Fir laptop with wired/wireless interface
> > get's the same ip and such use cases?) Since it's checking for an
> > existing lease, it does'nt lease the same address to both hosts
> > simultaneously.
> >
> 
> 
> > I can with this patch put the following configuration, and dnsmasq
> > starts and serves addresses to the two different hosts from the same
> > address set.
> >
> > dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aa04/126],host2
> > dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa04/126],host1
> >
> > With the git master; as well as older version 2.76 (the one in
> CentOS);
> > I also tested this configuration where two hosts share the same IP:
> > dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aa04],host2
> > dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa04],host1
> >
> > The configuration loads without error, and the first host to capture
> > the reservation gets the lease. The second one get "no addresses
> > available".
> >
> > Because of the above existing behaviour, I came to the conclusion that
> > implementing any check to verify each address in the arbitrary address
> > list wasn't necessary. I may have missed something?
> >
> 
> There are a couple of cases, which are covered by calls to
> config_implies() in the patch.
> 
> 1) A host asks for an address which is static-only, either because the
> network is declared for static

Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

2020-02-07 Thread Simon Kelley

Two commits in the repo, one adds arbitrary list of IPv6 addresses to
dhcp-host, second adds tags.

Please  give them a whirl


Cheers,

Simon.


On 04/02/2020 14:24, Harald Jensås wrote:
> On Tue, 2020-02-04 at 00:06 +0000, Simon Kelley wrote:
>> I went though this carefully, and decided that replacing the address
>> in
>> the dhcp-host with the next free one, but otherwise treating things
>> the
>> same might not work well. For instance, there are places where the
>> question is asked "is this address reserved in any dhcp-host?" and
>> clearly that needs to be modified to answer "yes" to any of the
>> addresses when there is more than one.
>>
> 
> I thought this was only the case for IPv4? I.e I did'nt see that check
> for IPv6 and tought it deliberately allowed having the same IP address
> in different host-entries? (Fir laptop with wired/wireless interface
> get's the same ip and such use cases?) Since it's checking for an
> existing lease, it does'nt lease the same address to both hosts
> simultaneously.
> 
> I can with this patch put the following configuration, and dnsmasq
> starts and serves addresses to the two different hosts from the same
> address set.
> 
> dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aa04/126],host2
> dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa04/126],host1
> 
> With the git master; as well as older version 2.76 (the one in CentOS);
> I also tested this configuration where two hosts share the same IP:
> dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aa04],host2
> dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa04],host1
> 
> The configuration loads without error, and the first host to capture
> the reservation gets the lease. The second one get "no addresses
> available".
> 
> Because of the above existing behaviour, I came to the conclusion that
> implementing any check to verify each address in the arbitrary address
> list wasn't necessary. I may have missed something?
> 
>> I ended with a different implementation of the same thing, with the
>> exception that I only supported a prefix range of addresses, and not
>> an
>> arbitrary list. That makes the internal representation much simpler.
>>
>> A quick test passes fine, but Harald you clearly have a better test
>> harness. Please could you put this through its paces, and see if it
>> does
>> what you need.
>>
> 
> I ran some tests with your patch, and I did not run into any issues
> with the prefix support.
> 
> Unfortunately, for my use-case in openstack the arbitrary list is the
> useful option between the two. There is currently no way in openstack
> networking api to ask the ip-address management to allocate a set of
> consecutive addresses. Adding support for the prefix approach is a
> major change to api, object model's, database schema etc.
> 
> Any chance we can add the arbitrary list back in? Or revert to my
> initial approach allowing multiple host-entries with different
> addresses? With the tag filtering support added for dhcp-hosts the
> issue of ordering of entries in configuration file is somewhat relaxed,
> as in; it's possible to control via tag's and filters.
> 
> 
> 
> Cheers
> Harald
> 
> 
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

2020-02-05 Thread Simon Kelley
On 04/02/2020 14:24, Harald Jensås wrote:
> On Tue, 2020-02-04 at 00:06 +0000, Simon Kelley wrote:
>> I went though this carefully, and decided that replacing the address
>> in
>> the dhcp-host with the next free one, but otherwise treating things
>> the
>> same might not work well. For instance, there are places where the
>> question is asked "is this address reserved in any dhcp-host?" and
>> clearly that needs to be modified to answer "yes" to any of the
>> addresses when there is more than one.
>>
> 
> I thought this was only the case for IPv4? I.e I did'nt see that check
> for IPv6 and tought it deliberately allowed having the same IP address
> in different host-entries? (Fir laptop with wired/wireless interface
> get's the same ip and such use cases?) Since it's checking for an
> existing lease, it does'nt lease the same address to both hosts
> simultaneously.
> 


> I can with this patch put the following configuration, and dnsmasq
> starts and serves addresses to the two different hosts from the same
> address set.
> 
> dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aa04/126],host2
> dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa04/126],host1
> 
> With the git master; as well as older version 2.76 (the one in CentOS);
> I also tested this configuration where two hosts share the same IP:
> dhcp-host=52:54:00:bc:c3:fd,[fd12:3456:789a:1::aa04],host2
> dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa04],host1
> 
> The configuration loads without error, and the first host to capture
> the reservation gets the lease. The second one get "no addresses
> available".
> 
> Because of the above existing behaviour, I came to the conclusion that
> implementing any check to verify each address in the arbitrary address
> list wasn't necessary. I may have missed something?
> 

There are a couple of cases, which are covered by calls to
config_implies() in the patch.

1) A host asks for an address which is static-only, either because the
network is declared for static addresses, or the address is outside the
range declared for dynamicic allocation. The semantics change to
allowing the address in --dhcp-host to any of the addresses in --dhcp-host.

2) Something like

dhcp-host=,

is valid, and has to override the default lease length for the whole set
of addresses now.

>> I ended with a different implementation of the same thing, with the
>> exception that I only supported a prefix range of addresses, and not
>> an
>> arbitrary list. That makes the internal representation much simpler.
>>
>> A quick test passes fine, but Harald you clearly have a better test
>> harness. Please could you put this through its paces, and see if it
>> does
>> what you need.
>>
> 
> I ran some tests with your patch, and I did not run into any issues
> with the prefix support.
> 
> Unfortunately, for my use-case in openstack the arbitrary list is the
> useful option between the two. There is currently no way in openstack
> networking api to ask the ip-address management to allocate a set of
> consecutive addresses. Adding support for the prefix approach is a
> major change to api, object model's, database schema etc.
> 
> Any chance we can add the arbitrary list back in? 


Yes, no problem doing that. I didn't appreciate it was necessary. New
commit soon, and I'll also look at the tagging one.



Cheers,

Simon.

Or revert to my
> initial approach allowing multiple host-entries with different
> addresses? With the tag filtering support added for dhcp-hosts the
> issue of ordering of entries in configuration file is somewhat relaxed,
> as in; it's possible to control via tag's and filters.
> 
> 
> 
> Cheers
> Harald
> 
> 
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

2020-02-03 Thread Simon Kelley
I went though this carefully, and decided that replacing the address in
the dhcp-host with the next free one, but otherwise treating things the
same might not work well. For instance, there are places where the
question is asked "is this address reserved in any dhcp-host?" and
clearly that needs to be modified to answer "yes" to any of the
addresses when there is more than one.

I ended with a different implementation of the same thing, with the
exception that I only supported a prefix range of addresses, and not an
arbitrary list. That makes the internal representation much simpler.

A quick test passes fine, but Harald you clearly have a better test
harness. Please could you put this through its paces, and see if it does
what you need.


Cheers,

Simon.




http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=79aba0f10ad0157fb4f48afbbcb03f094caff97a

On 27/01/2020 08:14, Harald Jensås wrote:
> On Sun, 2020-01-26 at 18:34 +, Simon Kelley wrote:
>> /62 is crazy, I don't know why I even said that. Harald, if you could
>> tweak your patch work with 128-based prefixes, I think we have
>> reached a
>> successful conclusion.
> 
> Sure, since 128-bit int's might not be available on many platforms
> where dnsmasq run I opted to support a max prefix of /64. So a prefix
> between /64 - /128 are valid in config. If the user tries to use a
> prefix < /64 an error is raised.
> 
> Updated patch below:
> 
> 
> 
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Dnsmasq version is displayed as "UNKNOWN" on complied version

2020-01-31 Thread Simon Kelley
On 31/01/2020 12:34, Abhishek Patti wrote:
> Hi
> 
> We needed dnsmasq to have capability of SRV caching, so I have complied
> dnsmasq from source using following dockerfile
> 
> " 
> FROM ubuntu:bionic
> MAINTAINER "Abhishek Patti mailto:abpa...@cisco.com>>"
> 
> RUN apt-get update && apt-get install -y gettext
> libnetfilter-conntrack-dev libidn2-dev libdbus-1-dev libgmp-dev
> nettle-dev libbsd-dev liblua5.2-dev build-essential devscripts
> COPY dnsmasq ./
> RUN debuild -b -uc -us
> 
> "
> this gives me dnsmasq_2.81-1_all.deb 
> 
> however when i upgrade existing/running version of dnsmasq (2.79) on
> ubuntu and run command "dnsmasq --version:, it upgraded successfully but
> shows "UNKNOWN"
> 
> " dnsmasq --version
> Dnsmasq version UNKNOWN  Copyright (c) 2000-2020 Simon Kelley
> Compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6
> no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
> 
> This software comes with ABSOLUTELY NO WARRANTY.
> Dnsmasq is free software, and you are welcome to redistribute it
> under the terms of the GNU General Public License, version 2 or 3."
> 
> Please let me know
> 


The version string compiled into the code is derived from the git tags,
either directly from git is you're compiling in a git repository, or
from a substituted format string if you're compiling from from tarball
extracted from a git repository. Failing either of those, you can edit a
suitable string into the file VERSION to get something useful.


Cheers,

Simon.

> 
> 
> 
> On Thu, Jan 30, 2020 at 4:05 AM
>  <mailto:dnsmasq-discuss-requ...@lists.thekelleys.org.uk>> wrote:
> 
> Send Dnsmasq-discuss mailing list submissions to
>         dnsmasq-discuss@lists.thekelleys.org.uk
> <mailto:dnsmasq-discuss@lists.thekelleys.org.uk>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> or, via email, send a message with subject or body 'help' to
>         dnsmasq-discuss-requ...@lists.thekelleys.org.uk
> <mailto:dnsmasq-discuss-requ...@lists.thekelleys.org.uk>
> 
> You can reach the person managing the list at
>         dnsmasq-discuss-ow...@lists.thekelleys.org.uk
> <mailto:dnsmasq-discuss-ow...@lists.thekelleys.org.uk>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dnsmasq-discuss digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Active-passive failover for dnsmasq with ldirectord
>       (Tom Fernandes)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 29 Jan 2020 22:32:28 +0100
> From: Tom Fernandes mailto:anyaddr...@gmx.net>>
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> <mailto:dnsmasq-discuss@lists.thekelleys.org.uk>
> Subject: Re: [Dnsmasq-discuss] Active-passive failover for dnsmasq
>         with ldirectord
> Message-ID: <602f303e-0198-b3b2-fd4f-3d684d08a...@gmx.net
> <mailto:602f303e-0198-b3b2-fd4f-3d684d08a...@gmx.net>>
> Content-Type: text/plain; charset=utf-8
> 
> Hi again,
> 
> are there some points in my description that are unclear?
> 
> Feedback concerning this setup is very much appreciated!
> 
> Warm regards,
> 
> 
> Tom
> 
> On 23/01/2020 15:08, Tom Fernandes wrote:
> > Hi,
> >
> > I read the old threads regarding dnsmasq and high availability and
> would
> > like to know if the following setup is possible or if I'm missing
> something.
> >
> > Master: dnsmasq A (192.168.1.10)
> > Slave: dnsmasq B (192.168.1.20)
> >
> > Loadbalancer virtual IP in ldirectord 192.168.1.30
> >
> > The clients use the virtual IP 192.168.1.30 as their nameserver.
> >
> > Host A is a "normally" configured dnsmasq server which also offers
> DHCP.
> >
> > Host B is configured the same way like server A with addition of an
> > iptables rule which blocks incoming DHCP-Requests.
> >
> > The configuration files + the DHCP leases file are on a shared
> > (active-active) Cluster-FS available to A and B.
> >
> > ldirectord is configured with with one realserver (A) and one fallback
> > server (B). In this configuration a connection to 192.168.1.30
> will only
> > lookup records from host A (as long as A is alive).
> &

Re: [Dnsmasq-discuss] [BUG] RA are sent too fast and slows down the machine

2020-01-27 Thread Simon Kelley
On 21/08/2019 19:59, 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].
> 
> 1. https://github.com/NetworkManager/NetworkManager-ci
> 2.
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0a496f059c1e9d75c33cce4c1211d58422ba4f62
> 3. https://bugzilla.redhat.com/show_bug.cgi?id=1739797
> 

Petr,

returning to this after too long away, I've committed what seems like
the most sensible fix:


http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=515ba97595e60c762c448657f3c0e545c1e365f9

which is different from yours. It only starts fast-RA when the
dhcp-range in question has never been used before. This satisfies the
original aim of 0a496f059c1e9d75c33cce4c1211d58422ba4f62 but eliminates
the possibility of the infinite loop.

Does that work for you?


Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Please consider clarifying the man page about the tftp service

2020-01-27 Thread Simon Kelley
On 24/01/2020 21:49, Olivier Cailloux wrote:
> Dear list,
> 
> I have been happy to use dnsmasq to install debian through network
> boot. However, it has taken a lot of trials and errors before I found
> the correct command line to use. I’d like to report my experience in
> hope that the man page be possibly improved, as the developers see fit.
> 
> It was very unclear to me while reading the man page which options
> exactly need to be turned on to enable network boot. I tried the
> following commands:
> sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0, proxy" "
> --dhcp-boot=pxelinux.0,saucisson" --enable-tftp --log-dhcp
> sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0,proxy" "
> --dhcp-boot=pxelinux.0" --enable-tftp --log-dhcp --tftp-
> root=/home/olivier/netboot
> sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0,proxy" "
> --dhcp-boot=/pxelinux.0" --enable-tftp --log-dhcp --tftp-
> root=/home/olivier/netboot --dhcp-no-override
> 
> before I finally found a correct one:
> sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0,proxy" "
> --dhcp-boot=pxelinux.0" --enable-tftp --log-dhcp --tftp-
> root=/home/olivier/netboot "--pxe-service=x86PC,Install Linux,
> pxelinux"
> 
> (All this took a while because I did not even know the TFTP service was
> not activated with my first tries, so I thought the problem lied
> somewhere else.)
> 
> The man page says: “If dnsmasq is providing a TFTP service (see --
> enable-tftp ) then only the filename is required here to enable network
> booting.” and also reading about the pxe-service option, I thought that
> it was unnecessary and was there just to allow for customizing the
> string that would display at start (which I thought I do not need).
> 
> Please consider clarifying the man page concerning the relevant options
> to state which option is required exactly; and especially, please
> consider making dnsmasq tell something in the log file, or (better
> IMHO) refuse to start when the options it receives are incoherent. With
> the current behavior, it is very hard, when it’s the first time you do
> it, to even know that dnsmasq is not configured properly.
> 

This is a laudible aim, the problem is that there's no such thing as
"which option is required exactly". Netboot is gnarly thicket of
different standards and different ways of doing things, and depending on
how you want to do things, and which standards the things you are trying
to boot support, then you need different options. For instance in your
case you presumably have another DHCP server on the network which is
dealing with handing out addresses, and you're relying on the
never-standardised "proxy DHCP" feature of PXE to do be able to do
netbooting without touching the configuration of that other DHCP server.
In fact if you use just one DHCP server which can be configured,
especially if it's running dnsmasq, netbooting is much simpler than the
way you've done it. A primer on netbooting with examples of dnsmasq
configurations would be a good thing to have, but it's place is not in
the dnsmasq man page.



Cheers

Simon


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH V2] Add new extensible D-Bus signal

2020-01-26 Thread Simon Kelley
Sorry to keep pushing this back at you, but I looked in more detail and
there are things that are not yet right.

1) Why is the action the internal arbitrary integer? Wouldn't it be
better for this to be a string, deleted/added/updated or even the name
of the earlier signals; DhcpLeaseAdded etc which are in the action_str
variable already?

2) There is a few instances of code in dbus.c which have got wrapped with

#if defined(HAVE_SCRIPT) || defined(HAVE_DBUS)

which is pointless, since HAVE_DBUS must be defined otherwise the whole
file is omitted.

3) You're allocating a copy of the vendorclass but that's not necessary,
just past the pointer to the start of the extradata buffer.

3a) For an IPv6 lease, the vendorclass is different, see the code around
line 586 in src/helper.c and line 1783 in src/rfc3315.c, the extradata
buffer contains a (string) vendor-id first, and then some number of
vendor-class strings, the number is stored in lease->vendorclass_count.
Again, you don't need to copy these, just generate pointers into the
zero-delimited extradata buffer.

4) The lease expiration time is in unix epoch time, except sometimes it
isn't, if dnsmasq is compiled with   HAVE_BROKEN_RTC then it's in
seconds since last boot. The field name in the dictionary should at
least reflect this: but maybe it would be better to just provide the
time until lease expiration in seconds, that's always calculated the
same way: see helper.c line 788.

5) Question: there's lots of other data which is exported to the script,
as we now have an extensible way to export if via DBUS, should that data
be included in the DBus Dict?



Cheers,

Simon.



On 23/01/2020 11:00, Victorien Molle wrote:
> For our usage, we need to have more informations sent over D-Bus such as the 
> interface
> name, the vendor class identifier and the lease expiration time.
> 
> To achieve this, we add a new D-Bus signal "DhcpLeaseNotification" which 
> exports the
> requested informations as a dictionnary.
> It also has the advantage to be flexible if someone wants to add a new entry 
> in the
> future.
> 
> Note: in order to get leases extradata be populated, we enabled this feature 
> if D-Bus
> is enabled in configuration file (this was enabled in the past only if a 
> script was
> ran on leases updates).
> 
> Here is an example of the obtained result with a Python3 program:
> 
> ''' Define our D-Bus callback '''
> def cb(action, ipaddr, hwaddr, hostname, info):
> print(f'Action: {action}')
> print(f'IP: {ipaddr}')
> print(f'Hostname: {hostname}')
> for k in info:
> print(f'{k}: {info.get(k)}')
> 
> ''' Connect to signal DhcpLeaseNotification on interface 
> uk.org.thekelleys.dnsmasq '''
> DNSMasq.listen('DhcpLeaseNotification', callback=cb)
> 
> ''' Run GLib loop '''
> GLib.MainLoop().run()
> 
> ''' When DNSMasq receives a DHCP request, here is the result: '''
> 
> Action: 3
> IP: 192.168.1.100
> Hostname: Nucleus.nucle.us
> interface: br-mgmt
> vendor_class: LaGrosseBiche
> expiration: 1575667431
> 
> Signed-off-by: Victorien Molle 
> Signed-off-by: Florent Fourcot 
> ---
>  dbus/DBus-interface |   9 
>  src/dbus.c  | 118 +++-
>  src/dnsmasq.h   |   2 +-
>  src/lease.c |   2 +-
>  src/rfc2131.c   |  12 ++---
>  5 files changed, 134 insertions(+), 9 deletions(-)
> 
> diff --git a/dbus/DBus-interface b/dbus/DBus-interface
> index 954c5b9..ed42551 100644
> --- a/dbus/DBus-interface
> +++ b/dbus/DBus-interface
> @@ -273,14 +273,23 @@ DhcpLeaseAdded
>  ---
>  
>  This signal is emitted when a DHCP lease for a given IP address is created.
> +This will also trigger the DhcpLeaseNotification signal.
>  
>  DhcpLeaseDeleted
>  
>  
>  This signal is emitted when a DHCP lease for a given IP address is deleted.
> +This will also trigger the DhcpLeaseNotification signal.
>  
>  DhcpLeaseUpdated
>  
>  
>  This signal is emitted when a DHCP lease for a given IP address is updated.
> +This will also trigger the DhcpLeaseNotification signal.
> +
> +DhcpLeaseNotification
> +-
> +
> +This signal is emitted when a DHCP lease action is triggered. It exports,
> +as a dictionnary, more informations than the other signals.
>   
> diff --git a/src/dbus.c b/src/dbus.c
> index c0ce903..c906e11 100644
> --- a/src/dbus.c
> +++ b/src/dbus.c
> @@ -55,6 +55,7 @@ const char* introspection_xml_template =
>  "\n"
>  "  \n"
>  "\n"
> +#ifdef HAVE_DHCP
>  "\n"
>  "  \n"
>  "  \n"
> @@ -70,7 +71,13 @@ const char* introspection_xml_template =
>  "  \n"
>  "  \n"
>  "\n"
> -#ifdef HAVE_DHCP
> +"\n"
> +"  \n"
> +"  \n"
> +"  \n"
> +"  \n"
> +"  \n"
> +"\n"
>  "\n"
>  "   \n"
>  "   \n"
> @@ -98,6 +105,12 @@ struct watch {
>struct watch *next;
>  };
>  
> +struct lease_info {
> +  char *key;
> +  char *fmt;
> +  char dbus_type;
> +  DBusBasicValue value;
> 

Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

2020-01-26 Thread Simon Kelley
On 21/01/2020 23:31, Harald Jensås wrote:
> On Tue, 2020-01-21 at 23:38 +0100, Tore Anderson wrote:
>> * Simon Kelley
>>
>>> I have an alternative suggestion for the syntax of dhcp-host.
>>> It's less flexible, but simpler and easier to understand and to
>>> explain,
>>> and uses existing semantics rather than adding new keywords.
>>>
>>> The idea is just to add a prefix-length to the address. That allows
>>> you
>>> to define (eg) 1,2,4,8, or 16 addresses for use by a host simply
>>> and
>>> easily in a way which makes it difficult to accidentally overlap
>>> address
>>> ranges, and is fairly obvious to anyone who has done done any IPv6
>>> network configuration.
>>>
>>> for instance to reserve four addresses for each host we cold do:
>>>
>>> dhcp-host=00:11:22:33:44:55,[fd12:3456::aa00/62]
>>> dhcp-host=00:11:22:33:44:56,[fd12:3456::aa04/62]
>>> dhcp-host=00:11:22:33:44:57,[fd12:3456::aa08/62]
>>>
>>> As a sanity check, if the "host part" of the address isn't zero,
>>>
>>> ie [fd12:3456::aa01/62]
>>>
>>> that could be rejected with an error.
>>
> 
> I like the idea of using a prefix. I have a new revision of the patch
> with this implemented at the bottom of this e-mail. It's far better and
> more flexible than the keywords approach I came up with initially, as
> it's now possible to mix individual addreses, prefixed ranges and
> prefixed wildcard addresses etc.
> 
> # A list of addressses
> dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa02][fd12:3456:789a:1::aa04][fd12:3456:789a:1::aa06],host1
> 
> # Mixing a prefix and a single address
> dhcp-host=52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa04/62][fd12:3456:789a:1::aa00],host1
> 
> # Prefixed wildcard
> dhcp-host=52:54:00:3f:5c:c0,[::aa04/62],host1
> 
> 
>> I have done quite a bit of IPv6 networking, but the use of /62 here
>> is anything but «fairly obvious» to me.
>>
>> It would have been much more intuitive to use /126, in my opinion.
>>
>> Tore
>>
> 
> I too found it a bit curios with /62 at first, as I understand it the
> interface identifier is always the 64 least significant bit's in IPv6
> ref[1].
> 
> I think changing the patch to use the full 128 bit's as a mask is
> trivial. We may also support both by subtracting 64 from any prefix
> larger than 64 in the code? So /126 and /62 yield the same result.
> 
> What does other people think?
> 

/62 is crazy, I don't know why I even said that. Harald, if you could
tweak your patch work with 128-based prefixes, I think we have reached a
successful conclusion.


Simon.



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

2020-01-26 Thread Simon Kelley
On 21/01/2020 22:38, Tore Anderson wrote:
> * Simon Kelley
> 
>> I have an alternative suggestion for the syntax of dhcp-host.
>> It's less flexible, but simpler and easier to understand and to explain,
>> and uses existing semantics rather than adding new keywords.
>>
>> The idea is just to add a prefix-length to the address. That allows you
>> to define (eg) 1,2,4,8, or 16 addresses for use by a host simply and
>> easily in a way which makes it difficult to accidentally overlap address
>> ranges, and is fairly obvious to anyone who has done done any IPv6
>> network configuration.
>>
>> for instance to reserve four addresses for each host we cold do:
>>
>> dhcp-host=00:11:22:33:44:55,[fd12:3456::aa00/62]
>> dhcp-host=00:11:22:33:44:56,[fd12:3456::aa04/62]
>> dhcp-host=00:11:22:33:44:57,[fd12:3456::aa08/62]
>>
>> As a sanity check, if the "host part" of the address isn't zero,
>>
>> ie [fd12:3456::aa01/62]
>>
>> that could be rejected with an error.
> 
> I have done quite a bit of IPv6 networking, but the use of /62 here is 
> anything but «fairly obvious» to me.
> 
> It would have been much more intuitive to use /126, in my opinion.
> 
> Tore
> 

/62 was a late-night-long-day brain fade. Of Course, I meant /126 :)

Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

2020-01-20 Thread Simon Kelley
On 16/01/2020 18:09, Harald Jensås wrote:
> Hi,
> 
> Changing the topic and dropping the history as this is a full re-write
> of the patch based on the previous feedback and discussion. Instead of
> multiple dhcp-host entries, a single dhcp-host entry can be defined
> with either  a list: or range: of addresses, this should eliminate the
> issue with ordering of entries in the configuration file.
> 
> 

I have an alternative suggestion for the syntax of dhcp-host.
It's less flexible, but simpler and easier to understand and to explain,
and uses existing semantics rather than adding new keywords.

The idea is just to add a prefix-length to the address. That allows you
to define (eg) 1,2,4,8, or 16 addresses for use by a host simply and
easily in a way which makes it difficult to accidentally overlap address
ranges, and is fairly obvious to anyone who has done done any IPv6
network configuration.

for instance to reserve four addresses for each host we cold do:

dhcp-host=00:11:22:33:44:55,[fd12:3456::aa00/62]
dhcp-host=00:11:22:33:44:56,[fd12:3456::aa04/62]
dhcp-host=00:11:22:33:44:57,[fd12:3456::aa08/62]

As a sanity check, if the "host part" of the address isn't zero,

ie [fd12:3456::aa01/62]

that could be rejected with an error.

Happy to be shot down in flames, but that seems to be a simple to
implement and to explain way of doing what you want to achieve.



Cheers,

Simon.



> 
> --
> Harald
> 
> 
> 
>>From cfd8881d57ba9e0e26c183318f0118a5ca65c705 Mon Sep 17 00:00:00 2001
> From: Harald Jensås 
> Date: Mon, 13 Jan 2020 19:44:43 +0100
> Subject: [PATCH] DHCPv6 - List or Range reservation for single host
> 
> Add the possibility to provide either a list  or a range
> of ipv6 addresses for a dhcp-host reservation. When a
> request matching the clid or mac address is recieved the
> server will iterate over the available addresses until it
> find's one that is not already leased to a different
> clid/iaid and advertise this address.
> 
> Using multiple reservations for a single host makes it
> possible to maintain a static leases only configuration
> which support network booting systems with UEFI firmware
> that request a new address (a new SOLICIT with a new IA_NA
> option using a new IAID) for different boot modes, for
> instance 'PXE over IPv6', and 'HTTP-Boot over IPv6'. Open
> Virtual Machine Firmware (OVMF) and most UEFI firmware
> build on the EDK2 code base exhibit this behaviour.
> ---
>  man/dnsmasq.8 | 11 +
>  src/dnsmasq.h | 13 +-
>  src/option.c  | 67 ++-
>  src/rfc3315.c | 60 +
>  4 files changed, 149 insertions(+), 2 deletions(-)
> 
> diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
> index cb5cc73..454fca3 100644
> --- a/man/dnsmasq.8
> +++ b/man/dnsmasq.8
> @@ -1079,6 +1079,17 @@ work reliably if only one of the hardware addresses is 
> active at any
>  time and there is no way for dnsmasq to enforce this. It is, for instance,
>  useful to allocate a stable IP address to a laptop which
>  has both wired and wireless interfaces.
> +
> +For DHCPv6 it is possible to provide a list or a range of IPv6 addresses.
> +\fB--dhcp-host=52:54:00:3f:5c:c0,list:[fd12:3456::aa02][fd12:3456::aa04],host1\fP
> +will make the two addresses \fBfd12:3456::aa02\fP and \fBfd12:3456::aa04\fP
> +available to the host with hardware address 52:54:00:3f:5c:c0.
> +\fB--dhcp-host=52:54:00:3f:5c:c0,range:fd12:3456::aa01-fd12:3456::aa63,host1\fP
> +will make the range of addresses between the start address (fd12:3456::aa01) 
> and
> +the end address (fd12:3456::aa63) available to the host with hardware address
> +52:54:00:3f:5c:c0. Providing a range or list of addresses is useful for 
> network
> +booting where individual boot stages will request addresses with different 
> IAID's.
> +
>  .TP
>  .B --dhcp-hostsfile=
>  Read DHCP host information from the specified file. If a directory
> diff --git a/src/dnsmasq.h b/src/dnsmasq.h
> index 7fb440c..a77955b 100644
> --- a/src/dnsmasq.h
> +++ b/src/dnsmasq.h
> @@ -759,14 +759,23 @@ struct hwaddr_config {
>struct hwaddr_config *next;
>  };
>  
> +#ifdef HAVE_DHCP6
> +struct in6_addr_list {
> +  struct in6_addr addr6;
> +  struct in6_addr_list *next;
> +};
> +#endif
> +
>  struct dhcp_config {
> -  unsigned int flags;
> +  unsigned long flags;
>int clid_len;  /* length of client identifier */
>unsigned char *clid;   /* clientid */
>char *hostname, *domain;
>struct dhcp_netid_list *netid;
>  #ifdef HAVE_DHCP6
>struct in6_addr addr6;
> +  struct in6_addr start6, end6; /* range of addresses */
> +  struct in6_addr_list *addr6_list;
>  #endif
>struct in_addr addr;
>time_t decline_time;
> @@ -790,6 +799,8 @@ struct dhcp_config {
>  #define CONFIG_ADDR6  4096
>  #define CONFIG_WILDCARD   8192
>  #define CONFIG_ADDR6_HOSTS   16384/* address added by from /etc/hosts */
> +#define CONFIG_ADDR6_RANGE   32768
> +#define 

Re: [Dnsmasq-discuss] SRV record caching

2020-01-20 Thread Simon Kelley
On 14/01/2020 04:17, Abhishek Patti wrote:
> Hi 
> 
> I see there is a recent (2019-01) patch enabling SRV record caching in
> dnsmasq,. However there seems to be no new version which contains this
> feature. I wanted to ask how people are working around this problem of
> not having SRV caching ? We are currently having major issues since we
> use SIP alot. Any help would be appreciated
> 

From my point-of-view, the best solution would be for you to run the
current bleeding edge code from git. That at least has all the known
problems with the SRV caching code fixed, and it provides testing for
the code which we hope to release as a new stable version Real Soon Now.


Cheers,

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


  1   2   3   4   5   6   7   8   9   10   >