Re: [Dnsmasq-discuss] Announce: dnsmasq-2.77rc4

[Simon Kelley]

On 21/05/17 12:02, Matthias Andree wrote:
> Am 20.05.2017 um 22:50 schrieb Simon Kelley:
>> I've just mase the fourth, and probably final, release candidate for
>> dnsmasq-27. Please download, compile and run, and report any problems
>> ASAP. If all looks OK, 2.77 will happen in the next week.
>>
>> http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.77rc4.tar.gz
> 
> Finally, IDN2 and all-i18n do not appear to get along well,  because
> i18n insists on IDN.
> 
>

I've removed the automatic enable IDN with i18n. Doesn't make sense when
there are options for IDN.


Cheers,

Simon.

___
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.77rc4

[Simon Kelley]

On 21/05/17 11:38, Matthias Andree wrote:
> Am 20.05.2017 um 22:50 schrieb Simon Kelley:
>> I've just mase the fourth, and probably final, release candidate for
>> dnsmasq-27. Please download, compile and run, and report any problems
>> ASAP. If all looks OK, 2.77 will happen in the next week.
>>
>> http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.77rc4.tar.gz
> 
> Three issues during compilation on FreeBSD 10.3 amd64, which look like
> genuine bugs, and the forward.c seem critical
> - these should likely be "server->flags & SERV_DO_DNSSEC), with & not &&.
> 

Yuck. those came from an external patch, but I should have caught them.

>> forward.c:902:60: warning: use of logical '&&' with constant operand
>> [-Wconstant-logical-operand]
>>   
>> option_bool(OPT_DNSSEC_NO_SIGN) && (server->flags && SERV_DO_DNSSEC),
>> NULL, NULL);
>>  
>>
>> ^  ~~
>> forward.c:902:60: note: use '&' for a bitwise operation
>>   
>> option_bool(OPT_DNSSEC_NO_SIGN) && (server->flags && SERV_DO_DNSSEC),
>> NULL, NULL);
>>  
>>
>> ^~
>>  
>>
>> &
>> forward.c:902:60: note: remove constant to silence this warning
>>   
>> option_bool(OPT_DNSSEC_NO_SIGN) && (server->flags && SERV_DO_DNSSEC),
>> NULL, NULL);
>>  
>>   
>> ~^
>> forward.c:1480:59: warning: use of logical '&&' with constant operand
>> [-Wconstant-logical-operand]
>>   
>> option_bool(OPT_DNSSEC_NO_SIGN) && (server->flags && SERV_DO_DNSSEC),
>> NULL, NULL);
>>  
>>
>> ^  ~~
>> forward.c:1480:59: note: use '&' for a bitwise operation
>>   
>> option_bool(OPT_DNSSEC_NO_SIGN) && (server->flags && SERV_DO_DNSSEC),
>> NULL, NULL);
>>  
>>
>> ^~
>>  
>>
>> &
>> forward.c:1480:59: note: remove constant to silence this warning
>>   
>> option_bool(OPT_DNSSEC_NO_SIGN) && (server->flags && SERV_DO_DNSSEC),
>> NULL, NULL);
>>  
>>   
>> ~^
>>
>> rfc2131.c:839:25: warning: data argument not used by format string
>> [-Wformat-extra-args]
>>service->basename, layer);
>>   ^
Taking the patch for this reluctantly. The original code seems better to
me. Pity is confuses the compiler.


> 
> I think you may want to resolve these before 2.77 release time.
> 
> And when trying to strip down the build disabling all options I expose
> in FreeBSD, I get these, which are cosmetic and, in the option.c case,
> are bloat.
> 
> The attached patch series (against Git master) fixes these. Use git am
> to apply them in given order, and carefully review 0003* whether the
> option_len() macro needs to be changed instead.
> 
>> option.c:910:23: warning: unused function 'add_rev6' [-Wunused-function]
>> static struct server *add_rev6(struct in6_addr *addr, int msize)
>>   ^
>>
>> network.c:936:24: warning: unused variable 'l6' [-Wunused-variable]
>>   struct listener *l, *l6;
>>^
> 
> You may consider resolving these before 2.77 with proper #ifdefs. I
> don't care much.
> 
>

I have a policy of leaving such: why complicate the code even more than
the ifdefs already do?


Cheers,

Simon.

> 
> ___
> 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

[Dnsmasq-discuss] 2.77rc5

[Simon Kelley]

Heads up. I just pushed another release candidate.

http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.77rc5.tar.gz


Cheers,

Simon.

___
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.77rc4

[Simon Kelley]

I think my code has beaten the compiler.


opt->source_netmask  will remain set to zero on any code path which
doesn't set addrp and inhibit the execution of the memcpy()

Nevertheless I'll add a check, it took me 10 minutes to conince myself
the able was true.

Cheers,

Simon.

On 21/05/17 11:49, Matthias Andree wrote:
> Am 20.05.2017 um 22:50 schrieb Simon Kelley:
>> I've just mase the fourth, and probably final, release candidate for
>> dnsmasq-27. Please download, compile and run, and report any problems
>> ASAP. If all looks OK, 2.77 will happen in the next week.
>>
>> http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.77rc4.tar.gz
>>
> 
> GCC 5 and 6 also have this complaint, and they are right, unless you
> prove that the address family is either AF_INET or AF_INET6.
> If the latter isn't true, memcpy() copies to whichever garbage address
> was in the stack and picked up by [auto] void *addrp.
> 
> edns0.c: In function 'calc_subnet_opt':
> edns0.c:350:7: warning: 'addrp' may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>memcpy(opt->addr, addrp, len);
>^
> 
> Cheers,
> Matthias
> 
> 
> 
> ___
> 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] intermittent connection refused errors

[Simon Kelley]

On what basis do you think that your clients are getting "connection
refused". That's a specific ICMP error which typically originates in the
kernel, because there's nothing actually listening on a port.

Also, are you using TCP connections? If not, there's not a connection,
as such, the client sends a single UDP packet with the query, and some
time later it, probably, gets a single UDP packet reply. The reply may
never come because UDP is unreliable, either to and from dnsmasq, or to
and from the upstream server it forwards too. Under heavy load, UDP
packets may be dropped by the kernel too.


Your error message

ERROR: logging before flag.Parse: W0517 03:19:50.139060 1 server.go:53]
Error getting metrics from dnsmasq: read udp
127.0.0.1:36181->127.0.0.1:53: i/o timeout

implies that the client is timing out awaiting the UDP reply. Does it
retry the query under those circumstances? If it doesn't, that's your
problem, you're assuming UDP is reliable, when it ain't.


Cheers,

Simon.

On 18/05/17 23:45, Guido Pepper wrote:
> Hello.
> We are running dnsmasq version
> 
> /usr/sbin/dnsmasq --version
> Dnsmasq version 2.76  Copyright (c) 2000-2016 Simon Kelley
> Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP
> DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect
> inotify
> 
> We run dnsmasq in our kubernetes (https://kubernetes.io/) clusters to
> perform DNS resolution for the container based services running in the
> cluster.  I wrote up a bigger picture overview of our situation here
> http://stackoverflow.com/q/44030167/6067470.
> 
> The key points are that the applications running in our clusters
> experience intermittent name resolution errors.  At the same time that
> 1 or more applications have a name resolution error we get connection
> refused errors from an application that is querying dnsmaq for it's
> metrics (eg: dig +short chaos txt cachesize.bind).  I'm thinking that
> the DNS failures we are seeing is that dnsmasq is refusing the
> connection.  I'm hoping someone can point me in a direction to get to
> the root of these issues.  The only thought I have is to run dnsmasq
> in debug mode in the hopes that when connections are not being
> accepted something will get logged that would be a clue as to why this
> is happening.   I'm wondering if that's a sound approach or if anyone
> has alternate ideas for me to move this situation forward.
> 
> Thanks for listening!
> 
> ___
> 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

[Dnsmasq-discuss] Announce: dnsmasq-2.77rc4

[Simon Kelley]

I've just mase the fourth, and probably final, release candidate for
dnsmasq-27. Please download, compile and run, and report any problems
ASAP. If all looks OK, 2.77 will happen in the next week.

http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.77rc4.tar.gz


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] problem with loopback and 2.77test5

[Simon Kelley]

On 15/05/17 11:20, Kevin Darbyshire-Bryant wrote:
> 
> 
> On 15/05/17 11:06, Bastian Bittorf wrote:
>> * Simon Kelley  [12.05.2017 08:33]:
>>> Oops. "It compiles - ship it" bites back.
>>>
>>> 2.77rc3 fixes this, and we're currently eating the dog-food chez Kelley.
>>
>> just to mention it, the loopback-thingy is working fine now on my side
>> with rc3.
>> Thanks a lot!
> 
> Cheers Bastian,
> 
> To confirm, no obvious screaming in LEDEland with rc3, in fact the 'DS
> queries' fix has solved at least 2 reports of SIGSEGV.  That's good news
> I think.
> 
> Kevin
> 

This is all good. I've made a (hopefully) last rc4, mainly because none
of the others have actually been formally announced. If nobody screams
in a few days. 2.77 is go.

I just realised that the anniversary of the release of 2.76 was couple
of days ago. A year between releases in unprecedented.


Cheers,

Simon.

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

Re: [Dnsmasq-discuss] dhcp entries not being removed from dnsmasq

[Simon Kelley]

Ah, didn't read this before my previous reply.

dhcp_release is getting called, but dnsmasq is not getting the packet
(dhcp_release works by faking up a DHCP message as if it's coming from
the DHCP client, which tells the server to release the lease.)

If you can't see the packet in your packet dump, then that's significant.

Note that dhcp_release needs an "interface" parameter. That has to be
correct.

Cheers,

Simon.




On 17/05/17 19:12, Graeme Peterson wrote:
> I found the following entry in /var/log/auth.log which shows neutron as
> root (sudo) calling dhcp_release on IP: 132.16.0.13, MAC: 
> fa:16:3e:8e:83:97 two minutes after the DHCPACK and two minutes before
> the dnsmasq-dhcp log failure saying: "not using configured address
> 132.16.0.13 because it is leased to fa:16:3e:8e:83:97". Looks to me like
> Openstack is calling dhcp_release correctly. The dnsmask log is in a
> folder named "34705fcf-4f9c-48eb-b0bc-ac5091e181c8", same as the arg to
> ip netns exec without the "qdhcp-" prefix. So far it looks like a
> dhcp_release/dnsmasq issue to my untrained eye. I have been able to work
> around it somewhat by setting the max lease time to 30 seconds, although
> that seems to be introducing other issues, more investigation required
> there.
> 
> ./auth.log:May 16 16:55:21 my-ucs-69 sudo:  neutron : TTY=unknown ;
> PWD=/var/lib/neutron ; USER=root ; COMMAND=/usr/bin/neutron-rootwrap
> /etc/neutron/rootwrap.conf ip netns exec
> qdhcp-34705fcf-4f9c-48eb-b0bc-ac5091e181c8 dhcp_release tapc5399cce-70
> 132.16.0.13 fa:16:3e:8e:83:97
> 
> Thanks again,
> Graeme
> 
> On 2017-05-17 12:24, Graeme Peterson wrote:
> 
>> Hi all.
>>
>> Sorry if this issue has been discussed and resolved, I am new to the
>> list. I tried to find it in the list, and came across this reference
>> to the issue from Jan 2016:
>>
>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010273.html
>>
>>
>> What I am seeing is with OpenStack Newton on Ubuntu 16.10
>> (4.8.0-49-generic), with force_dhcp_release=True in
>> /etc/nova/nova.conf, using tcpdump on the netns for the relevant
>> Openstack network, I see dnsmasq receives the dhcp request, issues an
>> IP, and that IP should be released (Openstack should be calling
>> dhcp_release, I need to figure out how to verify that it is or is not
>> happening, however force_dhcp_release=True is explicitly set in
>> /etc/nova/nova.conf) , but it seems like the dhcp entry isn't being
>> entirely released. The odd thing is that when a new VM wants an IP,
>> tcpdump shows the request coming in for an address, but no reply, and
>> OpenStack thinks it got an IP - the same one that used to belong to
>> the recently terminated VM - but there is no dhcp offer in the
>> tcpdump, and the dnsmasq log shows:
>>
>> May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020
>> DHCPREQUEST(tapc5399cce-70) 132.16.0.13 fa:16:3e:8e:83:97
>> May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020 tags: tag0, known,
>> tapc5399cce-70
>> May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020
>> DHCPACK(tapc5399cce-70) 132.16.0.13 fa:16:3e:8e:83:97 host-132-16-0-13
>> ...
>> ...
>> ...
>> May 16 16:57:12 dnsmasq-dhcp[40394]: 461988430 available DHCP subnet:
>> 132.16.0.0/255.255.0.0
>> May 16 16:57:12 dnsmasq-dhcp[40394]: not using configured address
>> 132.16.0.13 because it is leased to fa:16:3e:8e:83:97
>> May 16 16:57:12 dnsmasq-dhcp[40394]: 461988430
>> DHCPDISCOVER(tapc5399cce-70) 192.168.0.51 fa:16:3e:31:de:d3 no address
>> available
>>
>> I don't see a log entry for a release of 132.16.0.13, not sure if
>> there should be one.
>>
>>
>> Is this a known and hopefully fixed issue? Can I provide further info
>> to help investigate it?
>>
>> Thanks,
>> Graeme
>>
>>
>> ___
>> 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
> 



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] dhcp entries not being removed from dnsmasq

[Simon Kelley]

dhcp_release is a bit of a hack, and I guess the packet it generates
could be blocked by all sorts of iptables rules. It also doesn't seem to
support the interface (eg tapc5399cce-70) having more than one IP
address on the same subnet, in case that's a problem.

My impression is that you're an OpenStack user trying to fix a problem,
but if you're in fact an OpenStack developer, it's worth pointing out
that the DBus control interface to dnsmasq provides a rather better way
of doing the same thing as dhcp_release.

Cheers,

Simon.


On 17/05/17 20:11, Graeme Peterson wrote:
> Thanks Simon. Appreciate the heads-up on the off-topic parts of my post.
> 
> I see from the auth.log entries that dhcp_release is being called as:
> 
> dhcp_release tapc5399cce-70 132.16.0.13 fa:16:3e:8e:83:97
> 
> To me that looks good, and lines up with the man page for dhcp_release.
> The interface "tapc5399cce-70" is the same as in the dnsmasq-dhcp log
> entries for the request and offer, and also matches the output of:
> 
> ip netns exec qdhcp-34705fcf-4f9c-48eb-b0bc-ac5091e181c8 ip a
> 
> I will try to reproduce again and watch the tcpdump for the release packet.
> 
> Thanks,
> GP
> 
> On 2017-05-17 14:39, Simon Kelley wrote:
> 
>> Ah, didn't read this before my previous reply.
>>
>> dhcp_release is getting called, but dnsmasq is not getting the packet
>> (dhcp_release works by faking up a DHCP message as if it's coming from
>> the DHCP client, which tells the server to release the lease.)
>>
>> If you can't see the packet in your packet dump, then that's significant.
>>
>> Note that dhcp_release needs an "interface" parameter. That has to be
>> correct.
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>>
>> On 17/05/17 19:12, Graeme Peterson wrote:
>>> I found the following entry in /var/log/auth.log which shows neutron as
>>> root (sudo) calling dhcp_release on IP: 132.16.0.13, MAC:
>>> fa:16:3e:8e:83:97 two minutes after the DHCPACK and two minutes before
>>> the dnsmasq-dhcp log failure saying: "not using configured address
>>> 132.16.0.13 because it is leased to fa:16:3e:8e:83:97". Looks to me like
>>> Openstack is calling dhcp_release correctly. The dnsmask log is in a
>>> folder named "34705fcf-4f9c-48eb-b0bc-ac5091e181c8", same as the arg to
>>> ip netns exec without the "qdhcp-" prefix. So far it looks like a
>>> dhcp_release/dnsmasq issue to my untrained eye. I have been able to work
>>> around it somewhat by setting the max lease time to 30 seconds, although
>>> that seems to be introducing other issues, more investigation required
>>> there.
>>>
>>> ./auth.log:May 16 16:55:21 my-ucs-69 sudo:  neutron : TTY=unknown ;
>>> PWD=/var/lib/neutron ; USER=root ; COMMAND=/usr/bin/neutron-rootwrap
>>> /etc/neutron/rootwrap.conf ip netns exec
>>> qdhcp-34705fcf-4f9c-48eb-b0bc-ac5091e181c8 dhcp_release tapc5399cce-70
>>> 132.16.0.13 fa:16:3e:8e:83:97
>>>
>>> Thanks again,
>>> Graeme
>>>
>>> On 2017-05-17 12:24, Graeme Peterson wrote:
>>>
>>>> Hi all.
>>>>
>>>> Sorry if this issue has been discussed and resolved, I am new to the
>>>> list. I tried to find it in the list, and came across this reference
>>>> to the issue from Jan 2016:
>>>>
>>>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010273.html
>>>>
>>>>
>>>> What I am seeing is with OpenStack Newton on Ubuntu 16.10
>>>> (4.8.0-49-generic), with force_dhcp_release=True in
>>>> /etc/nova/nova.conf, using tcpdump on the netns for the relevant
>>>> Openstack network, I see dnsmasq receives the dhcp request, issues an
>>>> IP, and that IP should be released (Openstack should be calling
>>>> dhcp_release, I need to figure out how to verify that it is or is not
>>>> happening, however force_dhcp_release=True is explicitly set in
>>>> /etc/nova/nova.conf) , but it seems like the dhcp entry isn't being
>>>> entirely released. The odd thing is that when a new VM wants an IP,
>>>> tcpdump shows the request coming in for an address, but no reply, and
>>>> OpenStack thinks it got an IP - the same one that used to belong to
>>>> the recently terminated VM - but there is no dhcp offer in the
>>>> tcpdump, and the dnsmasq log shows:
>>>>
>>>> May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020
>>>

Re: [Dnsmasq-discuss] dhcp entries not being removed from dnsmasq

[Simon Kelley]

You're assuming a lot of knowledge of OpenStack which is strictly
off-topic here.

Given that,  a couple of observations.

1) If dnsmasq is getting a DHCPELEASE packet, it will log that. Given
you're not seeing that in logs, then either dhcp_release is not being
invoked, or it's getting the wrong parameters, or it's failing. Can you
see the DHCPRLEASE messages in your packet dump?

2) What dhcp client is openstack using? Some DHCP servers will continue
to use a previous address if they fail to contact a DHCP server.

Cheers,
Simon.


On 17/05/17 17:24, Graeme Peterson wrote:
> Hi all.
> 
> Sorry if this issue has been discussed and resolved, I am new to the
> list. I tried to find it in the list, and came across this reference to
> the issue from Jan 2016:
> 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010273.html
> 
> 
> What I am seeing is with OpenStack Newton on Ubuntu 16.10
> (4.8.0-49-generic), with force_dhcp_release=True in /etc/nova/nova.conf,
> using tcpdump on the netns for the relevant Openstack network, I see
> dnsmasq receives the dhcp request, issues an IP, and that IP should be
> released (Openstack should be calling dhcp_release, I need to figure out
> how to verify that it is or is not happening, however
> force_dhcp_release=True is explicitly set in /etc/nova/nova.conf) , but
> it seems like the dhcp entry isn't being entirely released. The odd
> thing is that when a new VM wants an IP, tcpdump shows the request
> coming in for an address, but no reply, and OpenStack thinks it got an
> IP - the same one that used to belong to the recently terminated VM -
> but there is no dhcp offer in the tcpdump, and the dnsmasq log shows:
> 
> May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020
> DHCPREQUEST(tapc5399cce-70) 132.16.0.13 fa:16:3e:8e:83:97
> May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020 tags: tag0, known,
> tapc5399cce-70
> May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020 DHCPACK(tapc5399cce-70)
> 132.16.0.13 fa:16:3e:8e:83:97 host-132-16-0-13
> ...
> ...
> ...
> May 16 16:57:12 dnsmasq-dhcp[40394]: 461988430 available DHCP subnet:
> 132.16.0.0/255.255.0.0
> May 16 16:57:12 dnsmasq-dhcp[40394]: not using configured address
> 132.16.0.13 because it is leased to fa:16:3e:8e:83:97
> May 16 16:57:12 dnsmasq-dhcp[40394]: 461988430
> DHCPDISCOVER(tapc5399cce-70) 192.168.0.51 fa:16:3e:31:de:d3 no address
> available
> 
> I don't see a log entry for a release of 132.16.0.13, not sure if there
> should be one.
> 
> 
> Is this a known and hopefully fixed issue? Can I provide further info to
> help investigate it?
> 
> Thanks,
> Graeme
> 
> 
> 
> ___
> 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] [PATCH] DHCPv6: Add support for more than one hardware address per IPv6 address

[Simon Kelley]

On 09/05/17 10:21, Pali Rohár wrote:
> On Sunday 02 October 2016 11:43:43 Pali Rohár wrote:
>> On Wednesday 27 January 2016 13:37:27 Pali Rohár wrote:
>>> On Wednesday 20 January 2016 20:15:23 Simon Kelley wrote:
>>>> Dnsmasq identifies IPv6 clients via their MAC address for the
>>>> purpose of selecting dhcp-host configuration to use, but it
>>>> doesn't use the MAC address as a unique client identifier for the
>>>> purpose of assigning DHCP leases in the same way the DHCPv4 does.
>>>> That's the crucial difference.
>>>
>>> Yes, I know.
>>>
>>>> The equivalent of the DHCPv4 share MAC address facility, should
>>>> really be something  which shares IAIDs, maybe?
>>>
>>> Right, in lease file is stored pair (MAC address, IP address) for
>>> IPv4 and pair (IAID, IPv6 address) for IPv6.
>>>
>>>> The crucial thing I'm trying to achieve here is turning your patch
>>>> from something that works on your network, with your very odd
>>>> configuration, into something that other people might want and use.
>>>> Without that, it's fine as your patch, but it can't go into the
>>>> dnsmasq mainline.
>>>
>>> Understood.
>>>
>>>> Maybe the way to think about that is to think about
>>>> how to document it. If we can describe what problem it solves, and
>>>> how it should be used, then we'll be getting there.
>>>
>>> I was thinking about it for more days. It is really not easy to solve
>>> this problem... Here are my results:
>>>
>>> * There are people who misuse original concept of "more mac
>>> addresses" for one ipv4 address. Dnsmasq supports this configuration
>>> only if one mac address from that --dhcp-host line is used at same
>>> time.
>>>
>>> * DHCPv6 clients are identified by DUID string, which we can say is
>>>   totally random and are not persistent across multi-OS computers or
>>>   reinstalling...
>>>
>>> * Internally DHCPv6 leases are identified by IAID.
>>>
>>> So to make configuration clean for both IPv4 and IPv6 we need support
>>> for:
>>>
>>> * Assigning IPv4 lease to more MAC addresses at the same time
>>>   (This will help people to use "more mac addresses" functionality
>>> correctly)
>>>
>>> * Assigning IPv6 address to more DUIDs at the same time
>>>   (This is "correct" IPv6 equivalent for previous request)
>>>
>>> * Assigning IPv6 address to more MAC addresses at the same time
>>>   (This is what would fix DUID problem)
>>>
>>> And it means that pair (IAID, IPv6 address) for IPv6 leases it not
>>> enough to do it.
>>>
>>> So, what about extending lease line for IPv6 addresses to include
>>> DUID and MAC address?
>>>
>>>> We need to bear in
>>>> mind that the behaviour we're talking about violates the RFCs
>>>> specifying DHCPv6, so it has to be especially carefull justified.
>>>
>>> Thats probably truth, but if something is useful users will try to
>>> use it. Either itself by patching dnsmasq or if possible by optional
>>> config options...
>>
>> Hi Simon! Replaying to my old email from January. Have you found some 
>> time to look at my suggestions? If yes, what do you think about it?
>>
> 
> PING again.
> 

There are so many layers of quotes here that I've completely lost track
of what we were trying to achieve, and how to achieve it. My memory is
that we'd failed to come up with any consensus on either of those.

Using MAC addresses with DHCPv6 AT ALL is quite difficult - it's not a
concept that the RFCs deal with. Doing the sleight-of-hand trick that
works with DHCPv4 doesn't seem feasible to me for DHCPv6.


Cheers,

Simon.


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

Re: [Dnsmasq-discuss] dhcp vendor-option and grub net_pxe_extensionspath

[Simon Kelley]

On 11/05/17 23:22, Carl Karsten wrote:
> I am pondering something I am not sure I even want: I guess we can call
> it a default option 209
> 
> Is this valid, reliable, predictable?
> 
> dhcp-option-force=209,"partman-auto/disk=/dev/sda"
> 
> dhcp-host=00:26:9e:03:9d:e5,set:negk,negk
> dhcp-option-force=tag:negk,209,"partman-auto/disk=/dev/sdb"
> 
> 
> The hope is ...sda except for the tag:negk case.

Yeah, that's how it's defined to work: and option which is conditional
on a tag gets used in preference to one which is not conditional, of the
tag is set.


Cheers,

Simon.

> 
> personally I only touch 20 machines a year, so setting up the extra 19
> lines
> is easy.  I like to understand my tools, and maybe someone with 100''s
> will be interested in my setup.  probaly not ;)
> 
> 
> 
> 
> On Sun, Apr 30, 2017 at 11:58 PM, Carl Karsten  <mailto:c...@nextdayvideo.com>> wrote:
> 
> woked - yay.
> 
> dhcp-host=00:26:9e:03:9d:e5,set:negk,negk
> dhcp-option-force=tag:negk,209,"partman-auto/disk=/dev/sda"
> 
> # grub/grub.cfg
> net_get_dhcp_option appends ${net_default_interface} 209 string
> 
> menuentry "Install Ubuntu preseed" {
> set gfxpayload=keep
> linux /ubuntu-installer/amd64/linux gfxpayload=800x600x16,800x600
> --- auto=true url=dc10b DEBCONF_DEBUG=5 tasks="" hostname=
> interface=${net_default_mac} ${appends}
> initrd /ubuntu-installer/amd64/initrd.gz
> }
> 
> ~ # head /var/log/syslog
> May  1 04:30:40 kernel: [0.00] Command line:
> BOOT_IMAGE=/ubuntu-installer/amd64/linux
> gfxpayload=800x600x16,800x600 --- auto=true url=dc10b
> DEBCONF_DEBUG=5 tasks= hostname= interface=00:26:9e:03:9d:e5
> partman-auto/disk=/dev/sda
> 
> 
> 
> On Fri, Apr 28, 2017 at 5:53 PM, Simon Kelley
> mailto:si...@thekelleys.org.uk>> wrote:
> 
> On 27/04/17 17:42, Carl Karsten wrote:
> > I am looking for the syntax of dhcp vendor options, and then how to
> > access them in grub-net.  I think.  maybe there is a better way.
> >
> > I pxe boot grub, which boots di (Debian Installer) and pass a 
> preseed file.
> >
> > I am trying to work out a nice way to pass host specific info to di
> > example, most use:
> > partman-auto/disk="/dev/sda"
> > but one machine has an onboard ssd nvme which needs /dev/nvme0n1
> >
> > di will read values appended to the kernel boot line, so I can hard 
> code
> > it like this:
> >
> > menuentry "Install Ubuntu preseed" {
> > set gfxpayload=keep
> > linux /ubuntu-installer/amd64/linux gfxpayload=800x600x16,800x600 
> ---
> > auto=true url=dc10b hostname= partman-auto/disk="/dev/nvme0n1"
> > interface=${net_default_mac}
> > initrd /ubuntu-installer/amd64/initrd.gz
> > }
> >
> > interface=${net_default_mac} - use the nic that pxe booted.
> >
> > Now I get lost in conf options and syntax.  forgive me for making 
> stuff
> > up here, if it worked I wouldn't be asking for help.
> >
> > I am hoping for something like
> > partman-auto/disk=$(net_pxe_extensionspath/disk}
> >
> > in dnsmasq conf:
> > dhcp-host=40:8d:5c:7f:bb:90,,gator
> >
> > dhcp-option-force=host:gator,209,"disk=/dev/nvme0n1"
> >
> 
> Look for "tags" in the man page, in this case, set a tag in the
> dhcp-host line (it can be the same as the hostname)
> 
> dhcp-host=40:8d:5c:7f:bb:90,set:gator,gator
> 
> 
> and make the option conditional on that tag
> 
> dhcp-option-force=tag:gator,209,"disk=/dev/nvme0n1"
> 
> >
> > So yeah, how do I send random strings based on mac/hostname
> See above
> 
> 
> > and how do I read what was sent in grub?
> 
> Set the "log-dhcp" flag in the dnsmasq configuration to get lots of
> useful information.
> 
> Cheers,
> 
> Simon.
> 
> >
> 
> 
> 
> > --
> > Carl K
> >
> >
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
>

Re: [Dnsmasq-discuss] problem with loopback and 2.77test5

[Simon Kelley]

Oops. "It compiles - ship it" bites back.

2.77rc3 fixes this, and we're currently eating the dog-food chez Kelley.


Cheers,

Simon.

On 11/05/17 15:49, Kevin Darbyshire-Bryant wrote:
> 
> 
> On 10/05/17 22:31, Simon Kelley wrote:
>> Just committed a patch which should make this work again without needing
>> --no-ping.
>>
>> I've tagged it as 2.77rc2, so please could a LEDE package be built, and
>> this behaviour tested.
> 
> I tried rc2 and think there's a problem with DHCPv4 leasesie. It
> doesn't give them out any more.
> 
> It was a *very* quick test before I had to dash out of the door so not
> exactly thorough.
> 


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

Re: [Dnsmasq-discuss] define IPv6 prefix for host-records

[Simon Kelley]

You're trying to invent yet another way of solving the "naming IPv6
hosts" problem, made more difficult by the fact that they change
addresses as the delegated prefix changes.

There are a couple of other possibilities.

1) If you're using DHCP for IPv4, look at the dnsmasq "ra-names"
facility, which can make creating DNS entries for RA-allocated addresses
automatic.

2) Consider giving your hosts ULA addresses as well as addresses with
the prefix you get from you ISP. If you just want a DNS name that's
usable from the local net, then that gives you a stable address to
associate with the DNS name.

Cheers,

Simon.




On 06/05/17 16:10, Carsten Spieß wrote:
> Hello Simon,
> 
>> How do your machines get their IPv6 addresses, and specifically, their
>> changed IPv6 addresses after the prefix changes.?
> With RA/SLAAC, i have a dibbler client running receiving the prefix via
> DHCPv6 and distributing it via RA.
> Can dnsmasq be configured to run as DHCPv6 client too?
> 
>> If you're using DHCPv6 with dnsmasq as the server, 
> At the moment not, i'm using dnsmasq vor DHCPv4 and DNS
> I have no DHCPv6 server running (neither dnsmasq or dibbler or
> something else)
> 
>> then something like this is already available: if you have a dhcp-range line 
>> which
>> has the constructor: keyword, then you can have IPv6 addresses in
>> dhcp-host lines which have zero network part, and the relevant prefix
>> will be substituted in.
> I've seen this which pointed me to the proposed syntax.
> 
> Regards
> Carsten
> 
> 
> 
> ___
> 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] specifying dhcp options in proxy mode

[Simon Kelley]

The design is that dnsmasq sends the options expected by a PXE client if
it's acting as a proxy (because the whole proxy thing is part of the PXE
spec: a normal DHCP client doesn't know how to deal with it.) The
replies to the PXE client are constructed using the information given in
the pxe-service and pxe-prompt options. The inclusion of arbitrary
vendor-specific options is an oversight, I think.

As the PXE-spec doesn't AFAIK, include root-path as an expected option,
I'm not sure that sending it will have any effect.

As stated in the thread you link to, if you're netbooting an OS via PXE
then one the OS starts, it will do DHCP again, and that's the time to
send arbitrary options.

TL;DR I don't think implementing what you're asking for will achieve
what you want, but if you can demonstrate that it will, then I'll
certainly looking at adding the extra function.

Cheers,

Simon.


On 10/05/17 14:32, Andriy Gapon wrote:
> 
> It seems that present dnsmasq adds only vendor-specific option when it 
> operates
> on the proxy mode.
> E.g., with a config that has
>   dhcp-range=192.168.0.88,proxy,255.255.255.0
>   dhcp-option=vendor:PXEClient,6,2b
> dnsmasq adds option 43, suboption 6 to its responses.
> 
> But if I have
>   dhcp-range=192.168.0.88,proxy,255.255.255.0
>   dhcp-option=option:root-path,"192.168.0.200:/export/netboot"
> then the root-path option is not set in the responses.
> That's the case even if I use dhcp-option-force.
> 
> Is there any reason for this?
> Could dnsmasq be changed to allow explicitly set options for proxy responses?
> I think that that would add more flexibility for users who know what they are 
> doing.
> 
> P.S.
> I found this old conversation:
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q2/005722.html
> Looks like the situation hasn't changed since then.
> 



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] problem with loopback and 2.77test5

[Simon Kelley]

Just committed a patch which should make this work again without needing
--no-ping.

I've tagged it as 2.77rc2, so please could a LEDE package be built, and
this behaviour tested.


Cheers,


Simon.

On 10/05/17 14:11, Bastian Bittorf wrote:
> * Simon Kelley  [10.05.2017 15:05]:
>> I wonder if this is to do with the extension of the ping-test to more
>> cases. Please could you try adding
>>
>> no-ping
>>
>> to the config, and see if that improves things?
> 
> thank you - yes, that works...now the log shows:
> 
> dnsmasq-dhcp[28815]: DHCPREQUEST(lo) 127.0.0.2 00:00:00:00:00:00
> dnsmasq-dhcp[28815]: DHCPACK(lo) 127.0.0.2 00:00:00:00:00:00 lo-alias
> dnsmasq-dhcp[28815]: ARP-cache injection failed: Invalid argument
> 
> could it be, because 'loopback' is not arp-able?
> 
> bye, bastian
> 




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] libidn2 support

[Simon Kelley]

OK, answering my own question, Debian support for libidn2 seems to be
rather behind, so at least for now, my life with Debian maintainer hat
on is easier if the option to build with libidn is retained. I shall
commit the patch forthwith.


Cheers,

Simon.


On 09/05/17 23:12, Simon Kelley wrote:
> On 09/05/17 19:35, Petr Menšík wrote:
>> Hi Simon, hi everyone.
>>
>> Fedora wants to move from IDN 2003 to IDN 2008 support. Dnsmasq already
>> supports IDN, but only older version. There is really little of IDN to
>> support. I made a patch that allows explicit support for libidn2 along
>> with original libidn. Because simple packaging, I could not use
>> HAVE_IDN2. I chose HAVE_LIBIDN2 as a replacement.
>>
>> A link to Fedora bug, if you want to try difference:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1449150
>>
>> Could it be merged?
>>
> 
> Is there any point in supporting both libraries? I'm not sure what the
> point is. Any build which includes the IDN support (which is, broadly
> distribution packages) will change to libidn2 so the libidn support just
> becomes support overhead moving forward. It won't give people the old
> behaviour unless they recompile.
> 
> I could see slightly more point to an option which allowed the user to
> specify IDN2003 rather than IDN2008 behaviour. It looks like that could
> be done by forcing the IDN2_TRANSITIONAL flag to the  idn2_to_ascii_lz()
> call.
> 
> 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] problem with loopback and 2.77test5

[Simon Kelley]

On 10/05/17 14:11, Bastian Bittorf wrote:
> * Simon Kelley  [10.05.2017 15:05]:
>> I wonder if this is to do with the extension of the ping-test to more
>> cases. Please could you try adding
>>
>> no-ping
>>
>> to the config, and see if that improves things?
> 
> thank you - yes, that works...now the log shows:
> 
> dnsmasq-dhcp[28815]: DHCPREQUEST(lo) 127.0.0.2 00:00:00:00:00:00
> dnsmasq-dhcp[28815]: DHCPACK(lo) 127.0.0.2 00:00:00:00:00:00 lo-alias
> dnsmasq-dhcp[28815]: ARP-cache injection failed: Invalid argument
> 
> could it be, because 'loopback' is not arp-able?

Actually, its the sort-of opposite. loopback seems to respond to any
address in 127.0.0.0/8 so you get a reply to an ICMP echo request from
any 127.0.0.0/8 address, even if the loopback interface doesn't
explicitly have that address

srk@holly:~/dnsmasq/dnsmasq$ ifconfig lo
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:2194 errors:0 dropped:0 overruns:0 frame:0
  TX packets:2194 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1
  RX bytes:164612 (164.6 KB)  TX bytes:164612 (164.6 KB)

srk@holly:~/dnsmasq/dnsmasq$ ping 127.0.0.2
PING 127.0.0.2 (127.0.0.2) 56(84) bytes of data.
64 bytes from 127.0.0.2: icmp_seq=1 ttl=64 time=0.068 ms
64 bytes from 127.0.0.2: icmp_seq=2 ttl=64 time=0.065 ms
^C
--- 127.0.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms

I'll patch it to suppress ping-checks for the loopback interface.

Cheers,

Simon.



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

Re: [Dnsmasq-discuss] problem with loopback and 2.77test5

[Simon Kelley]

Yes. I'll look at putting code to suppress the ARP check. on loopback.

Cheers,

Simon.


On 10/05/17 14:11, Bastian Bittorf wrote:
> * Simon Kelley  [10.05.2017 15:05]:
>> I wonder if this is to do with the extension of the ping-test to more
>> cases. Please could you try adding
>>
>> no-ping
>>
>> to the config, and see if that improves things?
> 
> thank you - yes, that works...now the log shows:
> 
> dnsmasq-dhcp[28815]: DHCPREQUEST(lo) 127.0.0.2 00:00:00:00:00:00
> dnsmasq-dhcp[28815]: DHCPACK(lo) 127.0.0.2 00:00:00:00:00:00 lo-alias
> dnsmasq-dhcp[28815]: ARP-cache injection failed: Invalid argument
> 
> could it be, because 'loopback' is not arp-able?
> 
> bye, bastian
> 



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] problem with loopback and 2.77test5

[Simon Kelley]

I wonder if this is to do with the extension of the ping-test to more
cases. Please could you try adding

no-ping

to the config, and see if that improves things?


Cheers,

Simon.


On 10/05/17 11:56, Bastian Bittorf wrote:
> here the relevant things with recent lede-project.org
> 
> root@box:~ dnsmasq -v
> Dnsmasq version 2.77test5  Copyright (c) 2000-2016 Simon Kelley
> Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP
> no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID
> loop-detect inotify
> 
> # kernel tested with non working version: 4.4.61
> # kernel tested with working version 4.4.56
> 
> # this is repeating in syslog every 3 seconds:
> Wed May 10 12:47:55 2017 daemon.warn dnsmasq-dhcp[21993]:
>  not using configured address 127.0.0.2 because it is in use by another host
> Wed May 10 12:47:55 2017 daemon.info dnsmasq-dhcp[21993]:
>  DHCPDISCOVER(lo) 00:00:00:00:00:00 no address available
> 
> # here the exact same config which is working with 2.77test4:
> root@box:~ :) cat /var/etc/dnsmasq.conf.cfg02411c
> # auto-generated config file from /etc/config/dhcp
> conf-file=/etc/dnsmasq.conf
> dhcp-authoritative
> localise-queries
> read-ethers
> expand-hosts
> dhcp-script=/etc/dhcp-script.d/10dhcpscript
> cache-size=1000
> domain=internet
> server=/internet/
> server=8.8.8.8
> except-interface=eth0.2
> except-interface=wlan0-1
> except-interface=wlan1-1
> addn-hosts=/var/run/hosts_olsr
> addn-hosts=/etc/local.hosts
> dhcp-leasefile=/tmp/dhcp.leases
> resolv-file=/tmp/resolv.conf.auto
> dhcp-broadcast=tag:needs-broadcast
> addn-hosts=/tmp/hosts
> conf-dir=/tmp/dnsmasq.d
> user=dnsmasq
> group=dnsmasq
> 
> dhcp-host=00:00:00:00:00:00,127.0.0.2,lo-alias
> 
> bogus-priv
> conf-file=/usr/share/dnsmasq/rfc6761.conf
> dhcp-range=set:lan,10.63.22.98,10.63.22.110,255.255.255.240,48h
> dhcp-range=set:mastergate,100.66.19.2,100.66.19.254,255.192.0.0,12h
> dhcp-option=mastergate,3,100.64.0.1
> dhcp-option=mastergate,6,100.64.0.1
> no-dhcp-interface=eth0.2
> dhcp-range=set:loopback,127.0.0.2,127.0.0.3,255.0.0.0,1h
> # end-of-config
> 
> 
> # on a working version i get a lease:
> root@box:~ :) cat /tmp/dhcp.leases 
> 1494416311 00:00:00:00:00:00 127.0.0.2 lo-alias *
> 
> we use this "strange" method, for checking if everything is
> working and the lease gets renewed (and some hotplug scripts are
> fired)
> 
> thanks & bye, bastian
> 
> ___
> 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] [PATCH] Logging of dhcp_script output

[Simon Kelley]

On 09/05/17 18:49, Petr Menšík wrote:
> Hi Simon,
> 
> sorry for a delay. We concluded that we do not like die on parse error
> even for dhcp script. It does always start up now unless script returns
> nonzero exit status. With this change, it would never start, until you
> were able to figure out what is wrong with your script. Then fix the
> cause. Until that, no-one will receive any lease as they did before.
> 
> When assigning addresses to dhclient that had his address before,
> dnsmasq will offer requested address if it is not leased. If you start
> with clear leases, many machines will receive correct addresses again.
> Dnsmasq is used as small server for containers or virtual hosts on the
> local machine. I think it is quite useful they will always (try to) start.
> 
> I think it should be possible to disable dying on parse errors. I think
> change from totally ignoring parsing errors to being not able to skip
> them is problematic for real world administrators.
> 
> I would prefer current behavior as default, but with possible
> configuration override. I think it would be useful if return code
> suggested there is problem with lease database. I could then move old
> leases file and retry with empty database from the startup script.
> 
> What do you think?

I think that just logging a warning is best. I don't want to add yet
another obscure config option.

Cheers,

Simon.

> 
> Dne 29.4.2017 v 00:03 Simon Kelley napsal(a):
>> On 24/04/17 15:42, Petr Mensik wrote:
>>> Thank you for accepting that patches. I agree that some garbage is
>>> far more likely to appear in dhcp-script mode. I would myself welcome
>>> error log from wrong formatted lease file as well. If I understand it
>>> well, that file will be overwritten after the first lease created. If
>>> it contains wrong data, just log an error, but do not terminate.
>>
>> That seems sensible. Change committed.
>>>
>>> It should not surprise administrator that just disabled IPv6 support.
>>> Error message would be logged once at startup until the first lease
>>> is created. Then file will be rewritten without any IPv6 leases,
>>> because they were skipped during the reading. I would accept one
>>> error message as notification some leases are gone forever.
>>>
>> Agreed.
>>
>>> I will have to ask whether failure to start on database corruption is
>>> considered a problem. It was silently ignoring all problems before.
>>> Now it fails to start the service completely if any error occurs. I
>>> think it relied on auto recovery with empty leases in the same way as
>>> with plain file. I think there should be a way to override default
>>> behavior. I will check for more opinions and get back with results.
>>>
>>
>> Any news on this?
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>> Thank you Simon.
>>>
>>> Cheers, Petr
>>>
>>>
>>
>>
> 




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] libidn2 support

[Simon Kelley]

On 09/05/17 19:35, Petr Menšík wrote:
> Hi Simon, hi everyone.
> 
> Fedora wants to move from IDN 2003 to IDN 2008 support. Dnsmasq already
> supports IDN, but only older version. There is really little of IDN to
> support. I made a patch that allows explicit support for libidn2 along
> with original libidn. Because simple packaging, I could not use
> HAVE_IDN2. I chose HAVE_LIBIDN2 as a replacement.
> 
> A link to Fedora bug, if you want to try difference:
> https://bugzilla.redhat.com/show_bug.cgi?id=1449150
> 
> Could it be merged?
> 

Is there any point in supporting both libraries? I'm not sure what the
point is. Any build which includes the IDN support (which is, broadly
distribution packages) will change to libidn2 so the libidn support just
becomes support overhead moving forward. It won't give people the old
behaviour unless they recompile.

I could see slightly more point to an option which allowed the user to
specify IDN2003 rather than IDN2008 behaviour. It looks like that could
be done by forcing the IDN2_TRANSITIONAL flag to the  idn2_to_ascii_lz()
call.

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] Intermittent SIGSEGV crash of dnsmasq-full

[Simon Kelley]

Never trust a git commit which happened in the early hours :)

Thanks for a second excellent bug report. This was much easier to find.

I've committed the fix to git.

I'll deal with Petr's patch tomorrow and then tag 2.77rc2

Cheers,

Simon.


On 09/05/17 09:33, Kevin Darbyshire-Bryant wrote:
> 
> 
> On 09/05/17 01:39, Simon Kelley wrote:
>> That was a horrible one.
>>
>> Fix committed, and an optimistic 2.77rc1 tag added.
> 
> Sadly a tad optimistic.  From the original reporter, and I can confirm
> 'domain-needed' is the crash enabling option:
> 
> Sorry!
> 
> Looking forward to the final release following the rc2 :-)
> 
> Cheers,
> 
> Kevin
> 
> 
> 
>> I saw the update from Simon Kelley (thank you!) on the Dnsmasq-discuss
>> mailing list and built an updated LEDE dnsmasq-2.77rc1 package to
>> test. (see required patch attached)
> 
> The prior minimal test-case passed, but the original production config
> file now creates a horrible SIGSEGV crash-loop (log attached):
> Mon May  8 22:59:46 2017 kern.info kernel: [1738736.539480]
> do_page_fault(): sending SIGSEGV to dnsmasq for invalid read access from
> 
> Mon May  8 22:59:46 2017 kern.info kernel: [1738736.548375] epc =
> 0040e79b in dnsmasq[40+2d000]
> Mon May  8 22:59:46 2017 kern.info kernel: [1738736.553564] ra  =
> 0040e773 in dnsmasq[40+2d000]
> 
> 
> Stack trace indicates something to do with logging:
> (gdb) core-file dnsmasq.18906.11.1494309586.core
> [New LWP 18906]
> ...
> Core was generated by `dnsmasq -C /var/etc/dnsmasq.conf.cfg02411c
> --no-daemon'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x0040e79b in search_servers (now=now@entry=1494309586,
> addrpp=addrpp@entry=0x0, qtype=qtype@entry=32768, qdomain=,
> type=type@entry=0x7fd02c74, domain=domain@entry=0x7fd02c78,
> norebind=norebind@entry=0x0) at forward.c:222
> 222   log_query(logflags | flags | F_CONFIG | F_FORWARD,
> qdomain, *addrpp, NULL);
> (gdb) bt
> #0  0x0040e79b in search_servers (now=now@entry=1494309586,
> addrpp=addrpp@entry=0x0, qtype=qtype@entry=32768, qdomain=,
> type=type@entry=0x7fd02c74, domain=domain@entry=0x7fd02c78,
> norebind=norebind@entry=0x0) at forward.c:222
> #1  0x00410759 in reply_query (fd=, family=,
> now=now@entry=1494309586) at forward.c:938
> #2  0x004127dd in check_dns_listeners (now=now@entry=1494309586)
> at dnsmasq.c:1560
> #3  0x004047db in main (argc=, argv=)
> at dnsmasq.c:1044
> (gdb) print logflags
> $1 = 32800
> (gdb) print flags
> $2 =
> (gdb) print *qdomain
> value has been optimized out
> (gdb) print addrpp
> $3 = (struct all_addr **) 0x0
> (gdb)
> 
> This turns out to be easy to reproduce. Simply add domain-needed to the
> prior standalone config file.
> Then trigger the crash from a client with:
> $ nslookup -port=3 google.com 192.168.1.1
> ;; connection timed out; no servers could be reached
> 
> I attached all the relevant logs, configs and patches.
> 
> 
> --
> 
> One or more files have been attached.
> 
> More information can be found at the following URL:
> https://bugs.lede-project.org/index.php?do=details&task_id=766#comment2589
>> I really hope to get out a 2.77 release soon.
>>
>>
>> Cheers,
>>
>> Simon.
>>
> 
> 
> 
> 
> 
> 
> 
> 
>> On 08/05/17 13:30, Kevin Darbyshire-Bryant wrote:
>>> Hi Simon,
>>>
>>> Got a report in LEDE land about a SIGSEGV issue,  I'm able to replicate
>>> easily as described.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>>
>>> Kevin
>>>
>>>
>>>  Forwarded Message 
>>> Subject: [FS#766] Intermittent SIGSEGV crash of dnsmasq-full
>>> Date: Mon, 08 May 2017 05:57:18 +
>>> From: LEDE Bugs 
>>> Reply-To: lede-b...@lists.infradead.org
>>> To: lede-b...@lists.infradead.org
>>>
>>> The following task has a new comment added:
>>>
>>> FS#766 - Intermittent SIGSEGV crash of dnsmasq-full User who did this -
>>> guidosarducci (guidosarducci)
>>>
>>> --
>>> After a little more investigation, this is definitely a bug that also
>>> exists in the latest lede/master which uses dnsmasq-2.77test5. It is
>>> easily triggered via a common mozilla DNS query, and appears related to
>>> using split DNS and DNSSEC.
>>>
>>> A minimal, standalone dnsmasq.conf that is vulnerable:
>>> listen-address=192.168.1.1
>>> port=3
>>> bind-

Re: [Dnsmasq-discuss] Intermittent SIGSEGV crash of dnsmasq-full

[Simon Kelley]

That was a horrible one.

Fix committed, and an optimistic 2.77rc1 tag added.

I really hope to get out a 2.77 release soon.


Cheers,

Simon.

On 08/05/17 13:30, Kevin Darbyshire-Bryant wrote:
> Hi Simon,
> 
> Got a report in LEDE land about a SIGSEGV issue,  I'm able to replicate
> easily as described.
> 
> Thoughts?
> 
> Cheers,
> 
> Kevin
> 
> 
>  Forwarded Message 
> Subject: [FS#766] Intermittent SIGSEGV crash of dnsmasq-full
> Date: Mon, 08 May 2017 05:57:18 +
> From: LEDE Bugs 
> Reply-To: lede-b...@lists.infradead.org
> To: lede-b...@lists.infradead.org
> 
> The following task has a new comment added:
> 
> FS#766 - Intermittent SIGSEGV crash of dnsmasq-full User who did this -
> guidosarducci (guidosarducci)
> 
> --
> After a little more investigation, this is definitely a bug that also
> exists in the latest lede/master which uses dnsmasq-2.77test5. It is
> easily triggered via a common mozilla DNS query, and appears related to
> using split DNS and DNSSEC.
> 
> A minimal, standalone dnsmasq.conf that is vulnerable:
> listen-address=192.168.1.1
> port=3
> bind-interfaces
> no-daemon
> no-hosts
> no-resolv
> log-queries=extra
> server=8.8.8.8
> server=/cloudfront.net/50.22.147.234
> dnssec
> dnssec-check-unsigned
> trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
> 
> trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
> 
> 
> 
> Removing either of these config lines results in no SIGSEGV:
> server=/cloudfront.net/50.22.147.234
> dnssec-check-unsigned
> 
> The bug can be triggered from a DNS client simply (e.g.a blank Firefox
> page!):
> ubuntu$ nslookup -port=3 tiles-cloudfront.cdn.mozilla.net 192.168.1.1
> ;; Question section mismatch: got cloudfront.net/DS/IN
> ;; connection timed out; no servers could be reached
> 
> 
> I also captured a dnsmasq core file from my router and ran it through gdb:
> ubuntu$
> ./staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.16/bin/mips-openwrt-linux-gdb
> -d
> ./build_dir/target-mips_24kc_musl-1.1.16/dnsmasq-full/dnsmasq-2.77test5/src/
> -n
> ./staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/dnsmasq
> dnsmasq.757.11.1494218146.core
> GNU gdb (GDB) 7.12
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later ...
> Reading symbols from
> ./staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/dnsmasq...done.
> 
> [New LWP 757]
> ...
> Core was generated by `dnsmasq -C crash-dnsmasq.conf'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  forward_query (udpfd=, udpaddr=udpaddr@entry=0x7fc1d930,
> dst_addr=, dst_iface=dst_iface@entry=0,
> header=header@entry=0x7c8010, plen=43, plen@entry=50,
> now=now@entry=1494218146, forward=0x77cabd90, ad_reqd=ad_reqd@entry=0,
> do_bit=do_bit@entry=0) at forward.c:281
> 281   if (forward->sentto->addr.sa.sa_family == AF_INET)
> (gdb) bt
> #0  forward_query (udpfd=, udpaddr=udpaddr@entry=0x7fc1d930,
> dst_addr=, dst_iface=dst_iface@entry=0,
> header=header@entry=0x7c8010, plen=43, plen@entry=50,
> now=now@entry=1494218146, forward=0x77cabd90, ad_reqd=ad_reqd@entry=0,
> do_bit=do_bit@entry=0) at forward.c:281
> #1  0x00410275 in receive_query (listen=listen@entry=0x77cbffe0,
> now=now@entry=1494218146) at forward.c:1443
> #2  0x00412825 in check_dns_listeners (now=now@entry=1494218146)
> at dnsmasq.c:1565
> #3  0x004047db in main (argc=, argv=)
> at dnsmasq.c:1044
> (gdb)
> 
> 
> The dnsmasq config file, log file, and client log are attached. I'm not
> sure I can go any further, so would appreciate the dnsmasq package
> maintainer taking a look and advising.
> 
> Thanks!
> --
> 
> 
> ___
> 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] define IPv6 prefix for host-records

[Simon Kelley]

How do your machines get their IPv6 addresses, and specifically, their
changed IPv6 addresses after the prefix changes.?If you're using DHCPv6
with dnsmasq as the server, then something like this is already
available: if you have a dhcp-range line which has the constructor:
keyword, then you can have IPv6 addresses in dhcp-host lines which have
zero network part, and the relevant prefix will be substituted in.

Cheers,

Simon.


On 05/05/17 15:13, Carsten Spieß wrote:
> Hello ,
> 
> i'm using dnsmasq to deliver IPv6 DNS entries.
> The IPv6 prefix i get dynamicaly from my ISP after dialin (pppoe),
> but this changes on every reconnect (which is at least once a day).
> 
> When the prefix changes every IPv6 host in /etc/hosts 
> dnsmasq.conf files has to be changed to cause dnsmasq to deliver
> the IPv6 address containing the new prefix.
> (I didn't find a posibility to configure dnsmasq to do this
> automatically)
> 
> I would like to suggest to add an "constructor:" option to 
> --host-record like:
>   
> --host-record=[,],[],[][,constructor:][,]
> 
> Where [] contains only the host-/local-network part and
> [constructor:] will add the prefix from 
> 
> e.g.
> --host-record=myhost,10.1.2.3,::0123:4567:89ab:cdef,constructor:eth1
> for adding the /64 prefix of eth1
> 
> Regards
> Carsten
> 
> 
> 
> ___
> 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] Memory corruption in my_syslog (log.c), SIGABRT (double free)

[Simon Kelley]

This is actually another instance of the parse_hex bug, which caused a
certain amount of confusion.

Anyway, fixes for that and the hostname_isequal() one committed to git.


Thanks for running these tests.

(In case it's not obvious, these are not security problems, since they
rely on malformed config files and not untrusted data from the net.)

Cheers,

Simon.

On 03/05/17 17:47, Stephan Zeisberg wrote:
> Hello,
> 
> opening the attached sample config input file with dnsmasq results in a 
> SIGABRT. The input file is fuzzed with american fuzzy 
> lop http://lcamtuf.coredump.cx/afl/.
> 
> version:
> 
> commit b2a9c571ebb333acbaa6bd752142df6821cb410c
> 
> how to reproduce:
> 
> $ ./src/dnsmasq --test -C 
> 
> Output (memory map/bt):
> 
> dnsmasq: bad option at line 8 of /tmp/dnsmasq_crash
> *** Error in `./src/dnsmasq': double free or corruption (out): 
> 0x00ebc680 ***
> === Backtrace: =
> /usr/lib/libc.so.6(+0x722ab)[0x7f5e308612ab]
> /usr/lib/libc.so.6(+0x7890e)[0x7f5e3086790e]
> /usr/lib/libc.so.6(+0x7911e)[0x7f5e3086811e]
> /usr/lib/libc.so.6(_IO_setb+0x4b)[0x7f5e3086522b]
> /usr/lib/libc.so.6(_IO_file_close_it+0xae)[0x7f5e3086385e]
> /usr/lib/libc.so.6(fclose+0x1bf)[0x7f5e30856def]
> /usr/lib/libc.so.6(+0xac5ad)[0x7f5e3089b5ad]
> /usr/lib/libc.so.6(+0xab5f9)[0x7f5e3089a5f9]
> /usr/lib/libc.so.6(+0xab8dd)[0x7f5e3089a8dd]
> /usr/lib/libc.so.6(__vsyslog_chk+0xd4)[0x7f5e308d6114]
> ./src/dnsmasq[0x4966ab]
> ./src/dnsmasq[0x4976b2]
> ./src/dnsmasq[0x422f71]
> ./src/dnsmasq[0x42159a]
> ./src/dnsmasq[0x424c3d]
> ./src/dnsmasq[0x457557]
> /usr/lib/libc.so.6(__libc_start_main+0xf1)[0x7f5e3080f511]
> ./src/dnsmasq[0x40331a]
> === Memory map: 
> 0040-004d2000 r-xp  fe:03 12073597   
> src/dnsmasq
> 006d1000-006d2000 r--p 000d1000 fe:03 12073597   
> src/dnsmasq
> 006d2000-006d4000 rw-p 000d2000 fe:03 12073597   
> src/dnsmasq
> 006d4000-006e4000 rw-p  00:00 0 
> 00eb8000-00ed9000 rw-p  00:00 0  
> [heap]
> 7f5e2c00-7f5e2c021000 rw-p  00:00 0 
> 7f5e2c021000-7f5e3000 ---p  00:00 0 
> 7f5e305d8000-7f5e305ee000 r-xp  fe:02 306247 
> /usr/lib/libgcc_s.so.1
> 7f5e305ee000-7f5e307ed000 ---p 00016000 fe:02 306247 
> /usr/lib/libgcc_s.so.1
> 7f5e307ed000-7f5e307ee000 r--p 00015000 fe:02 306247 
> /usr/lib/libgcc_s.so.1
> 7f5e307ee000-7f5e307ef000 rw-p 00016000 fe:02 306247 
> /usr/lib/libgcc_s.so.1
> 7f5e307ef000-7f5e3098a000 r-xp  fe:02 264297 
> /usr/lib/libc-2.25.so
> 7f5e3098a000-7f5e30b89000 ---p 0019b000 fe:02 264297 
> /usr/lib/libc-2.25.so
> 7f5e30b89000-7f5e30b8d000 r--p 0019a000 fe:02 264297 
> /usr/lib/libc-2.25.so
> 7f5e30b8d000-7f5e30b8f000 rw-p 0019e000 fe:02 264297 
> /usr/lib/libc-2.25.so
> 7f5e30b8f000-7f5e30b93000 rw-p  00:00 0 
> 7f5e30b93000-7f5e30bb6000 r-xp  fe:02 264298 
> /usr/lib/ld-2.25.so
> 7f5e30d7a000-7f5e30d7c000 rw-p  00:00 0 
> 7f5e30db4000-7f5e30db5000 rw-p  00:00 0 
> 7f5e30db5000-7f5e30db6000 r--p 00022000 fe:02 264298 
> /usr/lib/ld-2.25.so
> 7f5e30db6000-7f5e30db7000 rw-p 00023000 fe:02 264298 
> /usr/lib/ld-2.25.so
> 7f5e30db7000-7f5e30db8000 rw-p  00:00 0 
> 7fffcf4f4000-7fffcf515000 rw-p  00:00 0  
> [stack]
> 7fffcf53f000-7fffcf541000 r--p  00:00 0  
> [vvar]
> 7fffcf541000-7fffcf543000 r-xp  00:00 0  
> [vdso]
> ff60-ff601000 r-xp  00:00 0  
> [vsyscall]
> [1]25674 abort (core dumped)  ./src/dnsmasq --test -C /tmp/dnsmasq_crash
> 
> gdb:
> 
> Program terminated with signal SIGABRT, Aborted.
> #0  0x7f5e30822a10 in raise () from /usr/lib/libc.so.6
> (gdb) bt
> #0  0x7f5e30822a10 in raise () from /usr/lib/libc.so.6
> #1  0x7f5e3082413a in abort () from /usr/lib/libc.so.6
> #2  0x7f5e308612b0 in __libc_message () from /usr/lib/libc.so.6
> #3  0x7f5e3086790e in malloc_printerr () from /usr/lib/libc.so.6
> #4  0x7f5e3086811e in _int_free () from /usr/lib/libc.so.6
> #5  0x7f5e3086522b in __GI__IO_setb () from /usr/lib/libc.so.6
> #6  0x7f5e3086385e in __GI__IO_file_close_it () from /usr/lib/libc.so.6
> #7  0x7f5e30856def in fclose@@GLIBC_2.2.5 () from /usr/lib/libc.so.6
> #8  0x7f5e3089b5ad in __tzfile_read () from /usr/lib/libc.so.6
> #9  0x7f5e3089a5f9 in tzset_internal () from /usr/lib/libc.so.6
> #10 0x7f5e3089a8dd in __tz_convert () from /usr/lib/libc.so.6
> #11 0x7f5e308d6114 in __vsyslog_chk () from /usr/lib/libc.so.6
> #12 0x004966ab in my_syslog (priority=2, format=0x4cb3b6 "%s") at 
> log.c:340
> #13 0x004976b

Re: [Dnsmasq-discuss] Disabling dynamic DHCP assignment for known hosts

[Simon Kelley]

I just committed a patch to do this. I chose the tag "known-othernet"
just because it seemed more descriptive.


Cheers,

Simon.


On 19/04/17 19:36, Todd Sankey wrote:
> I tried a different approach. I created a patch (attached) so that the
> tag "knownother" is applied if there is a host definition that applies
> to a different context. In our setup, we then added
> "dhcp-ignore=tag:knownother".
> 
> On Wed, Mar 15, 2017 at 1:14 PM, Todd Sankey  > wrote:
> 
> Our setup has two wifi networks with different network addresses,
> one for employees and one for guests. On the employee network, the
> hosts all have static host entries that include IP addresses. The
> guest network has no static host entries. What we would like to do
> is prevent the employee machines from getting any assignment on the
> guest network.
> 
> We tried using "tag:!known" in the dhcp-range configuration, and we
> have tried a tag-if statement that sets a tag based on the guest
> network interface and known followed by a dhcp-ignore. Neither works. 
> 
> Looking through the code, I think it is because when looking for a
> dhcp_config entry, the search is filtered by whether the assigned
> address is valid for the interface the request was received on.
> Since the static assignments are only valid for the employee
> network, when a request is received on the guest network, the static
> assignments are not valid so the "known" tag is never set. As a
> result, neither the dhcp-range tag filter nor the tag-if filter has
> the desired effect.
> 
> I next tried having dhcp-host entries for every employee machine,
> one with a static assignment on the employee network, and one with a
> static assignment on guest network and appending "ignore" to the
> guest network entry. This seems to have the desired behaviour in
> that employee machines cannot get on the guest network. However,
> this obviously doubles the work of maintaining the host list. I am
> also not sure what this does to the guest address range having these
> static but ignored assignments.
> 
> Is there a better way to do this in the current version (2.76)?
> 
> If not, would it be a reasonable feature request to extend the
> handling of dhcp-host settings so that if there is an IP assignment
> and "ignore" is specified, then the host is ignored on networks
> where the IP assignment is not valid?
> 
> 
> 
> 
> ___
> 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] bug: trunk DHCP offer/replies being ignored by some devices

[Simon Kelley]

I just reverted the guilty change, so 2.77 should be OK now.


Cheers,

Simon.

On 08/04/17 00:55, Pedro MG Palmeiro wrote:
> The latest firmware for the printer is from 2015. This is one of those
> shared Epson/Fuji/Xerox models which I believe is entering EOL, since
> there is already another printer
> called M200 (Ecotank). Anyway, I'll report it.
> 
> Should the the implementation be correct in dnsmasq, then there will be
> more reports of this behavior from gateways implementing it, and that
> may move Epson into action.
> 
> Adding a mac exclude switch to dnsmasq is just marginally better than
> setting the printer IP manually, since both require intervention per device.
> 
> A switch disabling the whole implementation, or making it optional, thus
> reverting to the old behavior would be better if feasible, but I don't
> agree with removing it completely.
> 
> If nothing can be done, or be deemed unfeasible to be done, my opinion
> is that not much harm is done, since there is a way of getting things
> working (manual IP).
> 
> So, for me (3) it is.
> 
> Cheers.
> 
> On Fri, Apr 7, 2017 at 11:00 PM, Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> On 06/04/17 14:01, Pedro MG Palmeiro wrote:
> > Dnsmasq trunk replies are being ignored by some devices, in my
> case, two
> > epson printers (AL-M200).
> > Dnsmasq 2.76 works fine.
> >
> > This could be related with
> > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit
> <http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit>;
> > =88a77a78ad27adc3ed87b7ee603643d26cb896ee
> >
> > Please refer to
> > https://bugs.lede-project.org/index.php?do=details&task_id=673
> <https://bugs.lede-project.org/index.php?do=details&task_id=673>
> > for tcpdumps.
> >
> 
> But RFC 6842 assures us that no clients are broken by this change :)
> 
> The options here, as I see it are
> 
> 1) revert the change and don't support 6842
> 2) provide a way to disable the client-id reply for broken clients.
> 3) provide a flag to disable the client-id for all clients.
> 4) make the new behaviour optional, and provide a flag to enable it.
> 5) declare it No Our Problem and get the broken clients fixed.
> 
> 
> 5) is possible - have you talked to Epson? the AL-M200 looks like a
> current product, and likely has field-upgradable firmware.
> 
> 1) is not attractive.
> 
> 2) may be possible. There is already a config option to tell dnsmasq to
> ignore _incoming_ client-ids for a particular client, that could be
> extended to apply to _outgoing_ cones too.
> 
> Specifically, you'd need to add something like
> 
> dhcp-host=,id:*
> 
> to turn off this for just those machines.
> 
> 4) is not attractive.
> 
> I'm interested in peoples opinions; a flag to kill the new client-uid
> behaviour globally, or just for particular MAC/IP addresses, or based on
> a tag?
> 
> A pity, the original patch was so simple...
> 
> Cheers,
> 
> 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
> <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] Nack requests for unknown leases.

[Simon Kelley]

> Simon, is there any chance of a 'test5' bundling all the latest tweaks
> into a tarball?  It's much easier to get the LEDE guys to accept a test
> release tarball than it is loads of patchesand it means the code
> would get tested by a wider community.
> 

Done.

As soon as we reach a final conclusion on the dhcp-script logging
patches, I plan to start on a 2.77 release.


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] Logging of dhcp_script output

[Simon Kelley]

On 24/04/17 15:42, Petr Mensik wrote:
> Thank you for accepting that patches. I agree that some garbage is
> far more likely to appear in dhcp-script mode. I would myself welcome
> error log from wrong formatted lease file as well. If I understand it
> well, that file will be overwritten after the first lease created. If
> it contains wrong data, just log an error, but do not terminate.

That seems sensible. Change committed.
> 
> It should not surprise administrator that just disabled IPv6 support.
> Error message would be logged once at startup until the first lease
> is created. Then file will be rewritten without any IPv6 leases,
> because they were skipped during the reading. I would accept one
> error message as notification some leases are gone forever.
> 
Agreed.

> I will have to ask whether failure to start on database corruption is
> considered a problem. It was silently ignoring all problems before.
> Now it fails to start the service completely if any error occurs. I
> think it relied on auto recovery with empty leases in the same way as
> with plain file. I think there should be a way to override default
> behavior. I will check for more opinions and get back with results.
> 

Any news on this?


Cheers,

Simon.

> Thank you Simon.
> 
> Cheers, Petr
> 
> 




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] dhcp vendor-option and grub net_pxe_extensionspath

[Simon Kelley]

On 27/04/17 17:42, Carl Karsten wrote:
> I am looking for the syntax of dhcp vendor options, and then how to
> access them in grub-net.  I think.  maybe there is a better way.
> 
> I pxe boot grub, which boots di (Debian Installer) and pass a preseed file.
> 
> I am trying to work out a nice way to pass host specific info to di
> example, most use:
> partman-auto/disk="/dev/sda"
> but one machine has an onboard ssd nvme which needs /dev/nvme0n1
> 
> di will read values appended to the kernel boot line, so I can hard code
> it like this: 
> 
> menuentry "Install Ubuntu preseed" {
> set gfxpayload=keep
> linux /ubuntu-installer/amd64/linux gfxpayload=800x600x16,800x600 ---
> auto=true url=dc10b hostname= partman-auto/disk="/dev/nvme0n1"
> interface=${net_default_mac}
> initrd /ubuntu-installer/amd64/initrd.gz
> }
> 
> interface=${net_default_mac} - use the nic that pxe booted.
> 
> Now I get lost in conf options and syntax.  forgive me for making stuff
> up here, if it worked I wouldn't be asking for help.
> 
> I am hoping for something like
> partman-auto/disk=$(net_pxe_extensionspath/disk}
> 
> in dnsmasq conf:
> dhcp-host=40:8d:5c:7f:bb:90,,gator
> 
> dhcp-option-force=host:gator,209,"disk=/dev/nvme0n1"
> 

Look for "tags" in the man page, in this case, set a tag in the
dhcp-host line (it can be the same as the hostname)

dhcp-host=40:8d:5c:7f:bb:90,set:gator,gator


and make the option conditional on that tag

dhcp-option-force=tag:gator,209,"disk=/dev/nvme0n1"

> 
> So yeah, how do I send random strings based on mac/hostname
See above


> and how do I read what was sent in grub?

Set the "log-dhcp" flag in the dnsmasq configuration to get lots of
useful information.

Cheers,

Simon.

> 



> -- 
> Carl K
> 
> 
> 
> ___
> 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] bug:DHCP Relay not responding with DHCP OFFER.

[Simon Kelley]

On 27/04/17 22:02, Jason Kary wrote:
> Hi Folks,
> 
> I have a basic setup for DHCP relay across VLANS in DNSMASQ.  
> 
> My configuration file looks like: 
> 
> 
> bogus-priv
> interface=ens160
> log-dhcp
> dhcp-range=10.168.102.100,10.168.102.150,255.255.255.0,12h
> 
> 
> The client and server are running on a VMs in separate VLANS.  DHCP
> requests appear to be coming across:
> 
> 
> root@DHCP-UBUNTU-SERVER:~# tcpdump -i ens160 port 67 or port 68 -n
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on ens160, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 03:58:40.966944 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
> Request from 00:0c:29:65:e0:ea, length 322
> 03:58:46.487767 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
> Request from 00:0c:29:65:e0:ea, length 322
> 03:58:54.424895 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
> Request from 00:0c:29:65:e0:ea, length 322
> 03:59:07.795712 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
> Request from 00:0c:29:65:e0:ea, length 322
> 03:59:19.196022 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
> Request from 00:0c:29:65:e0:ea, length 322
> 
> root@DHCP-UBUNTU-SERVER:~# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> 
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> root@DHCP-UBUNTU-SERVER:~#
> 
> 
> The syslog log indicates the DCHP OFFERS are ‘supposed’ to be going out
> however nothing is seen on the wire.
> 
> 
> Apr 27 04:03:26 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> available DHCP range: 10.168.102.100 -- 10.168.102.150
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> DHCPDISCOVER(ens160) 00:0c:29:65:e0:ea
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> tags: ens160
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> DHCPOFFER(ens160) 10.168.102.128 00:0c:29:65:e0:ea
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> requested options: 1:netmask, 28:broadcast, 2:time-offset,
> 121:classless-static-route,
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> requested options: 15:domain-name, 6:dns-server, 12:hostname,
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> requested options: 40:nis-domain, 41:nis-server, 42:ntp-server,
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> requested options: 26:mtu, 119:domain-search, 3:router,
> 121:classless-static-route,
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> requested options: 249, 33:static-route, 252, 42:ntp-server
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> next server: 10.168.101.20
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size:  1 option: 53 message-type  2
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size:  4 option: 54 server-identifier  10.168.101.20
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size:  4 option: 51 lease-time  12h
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size:  4 option: 58 T1  6h
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size:  4 option: 59 T2  10h30m
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size:  4 option:  1 netmask  255.255.255.0
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size:  4 option: 28 broadcast  10.168.102.255
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size:  4 option:  3 router  10.168.102.1
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size:  4 option:  6 dns-server  10.168.101.20
> Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
> sent size: 20 option: 82 agent-id
>  01:0a:01:08:00:06:00:4c:4f:2a:00:2f:02:06…
> 
> 
> I’ve been trying to trace this issue and it is like the sendmsg system
> call is not working properly.  I believe routing is setup properly on
> the DHCP server.
> 
> root@DHCP-UBUNTU-SERVER:~# netstat -nr
> Kernel IP routing table
> Destination Gateway Genmask Flags   MSS Window
>  irtt Iface
> 0.0.0.0 172.31.13.1 0.0.0.0 UG0 0  
>0 ens192
> 10.168.101.00.0.0.0 255.255.255.0   U 0 0  
>0 ens160
> 10.168.102.00.0.0.0 255.255.255.0   U 0 0  
>0 ens160
> 

Re: [Dnsmasq-discuss] [PATCH] Nack requests for unknown leases.

[Simon Kelley]

On 25/04/17 08:41, Alin Năstac wrote:

>> At the DHCPDISCOVER stage, both the server and the client are supposed
>> to check if an address in in use. The server sends an ICMP echo request
>> and checks there's no answer. The client sends an ARP who-has request.
>> These checks should be enough to avoid address-stealing, but it's also
>> best not to overlap address ranges configured for DHCP allocation with
>> addresses of non-DHCP configured hosts.
> 
> Unfortunately dnsmasq does not send ICMP echo requests when DHCP
> discovery packet carries an OPTION_REQUESTED_IP, see DHCPDISCOVER case
> in file rfc2131.c starting from line 990:
> ...
>   else if (opt && address_available(context, addr,
> tagif_netid) && !lease_find_by_addr(addr) &&
>!config_find_by_address(daemon->dhcp_conf, addr))
> mess->yiaddr = addr;
> 

That's the bug here, I think. I was worried that a client sending a
DHCPDISCOVER when it thinks it knows that address, might respond to ICMP
pings, but at least for ISC dhclient on Linux, that's not the case.

Patch is here, and was much more trouble than it should have been: the
code really didn't consider this case.

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

It's still the case that addresses used by statically configured host on
a network should not be in the dhcp-range configured into that network's
DHCP server.


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] Nack requests for unknown leases.

[Simon Kelley]

> What I did to fix it was to send a NACK to the initial DHCP request,
> which luckily convinced the ISC DHCP client to stop asking for the
> same IP address in the following DHCP discovery. However, NACK will
> not quarantee all DHCP clients will do the same, so the case where
> DHCP discovery is carrying a conflicting option-50 should also be
> fixed IMO.

It also violates RFC 2131, para 4.3.2

 "If the DHCP
  server has no record of this client, then it MUST remain silent,
  and MAY output a warning to the network administrator. This
  behavior is necessary for peaceful coexistence of non-
  communicating DHCP servers on the same wire."


> Unfortunately dnsmasq does not send ICMP echo requests when DHCP
> discovery packet carries an OPTION_REQUESTED_IP, see DHCPDISCOVER case
> in file rfc2131.c starting from line 990:
> ...
>   else if (opt && address_available(context, addr,
> tagif_netid) && !lease_find_by_addr(addr) &&
>   !config_find_by_address(daemon->dhcp_conf, addr))
>mess->yiaddr = addr;

That's possibly a bug. Let me think about if there's a reason for that
(This is 10-year old code.)

However, doing that doesn't defend against the case that a client with a
statically-configured address turns up on a network _after_ the address
got leased to another machine. The only way to do that is not to give
static addresses in the range that you told your DHCP was available for
DHCP leases.


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] Nack requests for unknown leases.

[Simon Kelley]

On 24/04/17 10:16, Alin Năstac wrote:
> On Sun, Apr 23, 2017 at 5:46 PM, Simon Kelley  wrote:
>> On 20/04/17 10:34, Alin Nastac wrote:
>>> Hosts that migrate from one network to another could request their
>>> old IP address which might be already in use by another statically
>>> configured host. Currently non-authoritative dnsmasq servers will
>>> ignore such requests, but ISC DHCP client will send discovery packets
>>> next carrying the same requested IP address and dnsmasq will end up
>>> allocating a new lease for it without checking first if is already
>>> used by another host.
>>
>>
>> When the client sends the discovery packet, dnsmasq will notice that the
>> requested address is in use by another client, and offer a different
>> address instead.
> 
> You did not understood the scenario. The host that already use the
> requested IP address is statically configured to use it (in other
> words dnsmasq does not have a lease for the given IP address).
> 
> While at it, you might consider fixing the scenario in which a client
> fills a DHCP discovery message with an option-50 containing an IP
> address that is already used by another statically configured host.
> 

At the DHCPDISCOVER stage, both the server and the client are supposed
to check if an address in in use. The server sends an ICMP echo request
and checks there's no answer. The client sends an ARP who-has request.
These checks should be enough to avoid address-stealing, but it's also
best not to overlap address ranges configured for DHCP allocation with
addresses of non-DHCP configured hosts.

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] Nack requests for unknown leases.

[Simon Kelley]

On 20/04/17 10:34, Alin Nastac wrote:
> Hosts that migrate from one network to another could request their
> old IP address which might be already in use by another statically
> configured host. Currently non-authoritative dnsmasq servers will
> ignore such requests, but ISC DHCP client will send discovery packets
> next carrying the same requested IP address and dnsmasq will end up
> allocating a new lease for it without checking first if is already
> used by another host.


When the client sends the discovery packet, dnsmasq will notice that the
requested address is in use by another client, and offer a different
address instead.

Cheers,


Simon.



> ---
>  src/rfc2131.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/rfc2131.c b/src/rfc2131.c
> index 6a8f0db..9987745 100644
> --- a/src/rfc2131.c
> +++ b/src/rfc2131.c
> @@ -1141,10 +1141,12 @@ size_t dhcp_reply(struct dhcp_context *context, char 
> *iface_name, int int_index,
> else
>   {
> /* INIT-REBOOT */
> -   if (!lease && !option_bool(OPT_AUTHORITATIVE))
> - return 0;
> -   
> -   if (lease && lease->addr.s_addr != mess->yiaddr.s_addr)
> +   if (!lease)
> + {
> +   if (!option_bool(OPT_AUTHORITATIVE))
> + message = _("lease not found");
> + }
> +   else if (lease->addr.s_addr != mess->yiaddr.s_addr)
>   message = _("wrong address");
>   }
>   }
> 




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] Disabling dynamic DHCP assignment for known hosts

[Simon Kelley]

I like this. (Almost) completely backwards compatible, obvious to use,
solves a problem. What do people think?

I think the implementation is over-complex: calling find_config() with
the context set to NULL is all that's needed to implementthe search, but
that's a detail.

Cheers,

Simon.


On 19/04/17 19:36, Todd Sankey wrote:
> I tried a different approach. I created a patch (attached) so that the tag
> "knownother" is applied if there is a host definition that applies to a
> different context. In our setup, we then added "dhcp-ignore=tag:knownother".
> 
> On Wed, Mar 15, 2017 at 1:14 PM, Todd Sankey  wrote:
> 
>> Our setup has two wifi networks with different network addresses, one for
>> employees and one for guests. On the employee network, the hosts all have
>> static host entries that include IP addresses. The guest network has no
>> static host entries. What we would like to do is prevent the employee
>> machines from getting any assignment on the guest network.
>>
>> We tried using "tag:!known" in the dhcp-range configuration, and we have
>> tried a tag-if statement that sets a tag based on the guest network
>> interface and known followed by a dhcp-ignore. Neither works.
>>
>> Looking through the code, I think it is because when looking for a
>> dhcp_config entry, the search is filtered by whether the assigned address
>> is valid for the interface the request was received on. Since the static
>> assignments are only valid for the employee network, when a request is
>> received on the guest network, the static assignments are not valid so the
>> "known" tag is never set. As a result, neither the dhcp-range tag filter
>> nor the tag-if filter has the desired effect.
>>
>> I next tried having dhcp-host entries for every employee machine, one with
>> a static assignment on the employee network, and one with a static
>> assignment on guest network and appending "ignore" to the guest network
>> entry. This seems to have the desired behaviour in that employee machines
>> cannot get on the guest network. However, this obviously doubles the work
>> of maintaining the host list. I am also not sure what this does to the
>> guest address range having these static but ignored assignments.
>>
>> Is there a better way to do this in the current version (2.76)?
>>
>> If not, would it be a reasonable feature request to extend the handling of
>> dhcp-host settings so that if there is an IP assignment and "ignore" is
>> specified, then the host is ignored on networks where the IP assignment is
>> not valid?
>>
> 
> 
> 
> ___
> 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] not giving name to the DHCP lease

[Simon Kelley]

On 22/04/17 07:12, Harald Dunkel wrote:
> Hi folks,
> 
> dnsmasq 2.76, as packaged for openBSD 6.1:
> 
> dnsmasq.log contains tons of lines like
> 
> :
> :
> Apr 22 04:08:46 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 04:08:46 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 04:41:25 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 04:41:25 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 04:50:15 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 04:50:15 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 04:50:18 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 04:50:18 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 04:53:04 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 04:53:04 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 05:35:12 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 05:35:12 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 05:54:50 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 05:54:50 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 05:54:50 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 05:54:50 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 05:54:54 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 05:54:54 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 05:55:40 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 05:55:40 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> Apr 22 05:55:40 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the 
> DHCP lease of 10.0.0.239 because the name exists in /etc/hosts with address 
> 10.0.0.3
> Apr 22 05:55:40 dnsmasq-dhcp[70140]: not giving name nas1 to the DHCP lease 
> of 10.0.0.239 because the name exists in /etc/hosts with address 10.0.0.3
> :
> :
> 
> Since nas1 is off for several hours and local-ttl was never set, I wonder
> why dnsmasq doesn't fix the lease according to /etc/hosts?

The crucial thing is the DHCP lease-length, not DNS TTLs. Whilst nas1
has a lease for 10.0.0.239 then dnsmasq will renew it and you'll see
those messages.

Cheers,

Simon.

> 
> 
> Regards
> Harri
> 
> domain-needed
> bogus-priv
> no-resolv
> server=8.8.4.4
> server=2001:4860:4860::
> all-servers
> local=/example.com/
> interface=re1
> domain=example.com
> dhcp-range=10.0.0.128,10.0.0.254,12h
> dhcp-range=::,constructor:re1,ra-stateless,ra-names
> enable-ra
> ra-param=re1,120
> read-ethers
> dhcp-option=option:router,10.0.0.2
> dhcp-authoritative
> cache-size=1024
> localmx
> mx-target=mailhost.example.com.
> log-facility=/var/log/dnsmasq.log
> 
> ___
> 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] Logging of dhcp_script output

[Simon Kelley]

OK, there's a little subtlety here that needs to be taken into account.


The lease file format was not originally designed to be extensible, so
the code takes advantage (sort of) of the fact that lines which are
associated with IPv6 leases make no sense to older versions of dnsmasq
or even current versions compiled without IPv6 support.

The order of lines when the file is written is always

IPv4 leases
duid 
IPv6 leases

(I think duid may not get written in some cases - doesn't matter for the
sake of this argument.)

Therefore the behaviour of silently giving up when an unrecognisable
line is encountered is a feature, not a bug, as it allows old or
non-IPv6 dnsmasq binaries to work with newer lease files - they get the
IPv4 leases and ignore the rest.

Since the main problem you're trying to solve is unexpected error
messages from the script, the solution to this is to keep the old
behaviour when reading from a file, but the new behaviour when running
the script init command.

Given that we're only checking when using the init script, I think
die()ing is the best thing to do when parsing fails.

I've moved your patch on to do that, and to check ferror() on the
stream, to catch IO-errors.

Again, any new  bugs are mine :)

Cheers,

Simon.


On 19/04/17 19:14, Petr Mensik wrote:
> Hi Simon,
> 
> I like your changes. New shorter log is definitely helpful, separate log 
> section helps. The only bug I found is red white space highlight in the patch.
> 
> However I did yet another fix for remaining dhcp-script init action.
> It completely ignored any error in structure and silently skipped the rest of 
> database. If there was any message in stdin of init script, it just died 
> silently.
> The only thing that were visible was SIGPIPE from dhcp-script, because it did 
> not read whole database, if that signal was logged at all.
> My new patch handles garbage in leases database. If the line is wrong, it 
> logs part of wrong line and skips the rest of init.
> I thought about die in that case. I think it would be better for backward 
> compatibility to start with empty leases as before.
> 
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com  PGP: 65C6C973
> 
> - Original Message -
> From: "Simon Kelley" 
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Sent: Sunday, April 16, 2017 9:29:21 PM
> Subject: Re: [Dnsmasq-discuss] [PATCH] Logging of dhcp_script output
> 
> I like this. Yes, I know you can do it with shell magic, but this is
> easier and what I would expect to happen.
> 
> I've changed the patch quite a lot:
> 
> 1) Don't go to large effort to report "never happen" errors from pipe(),
> just silently handle them in the same way as fork()
> 
> 2) Don't do any of this when the -d debug flag is in effect, as it's
> already defined that the script gets stdin, stdout and stderr from the
> dnsmasq process in that case.
> 
> 3) Expand the subject-based logging that already exists, DHCP stuff
> comes from dnsmasq-dhcp, script output comes from dhcp-script. That
> avoids the wordy preamble to every line otherwise.
> 
> 4) Pull the copy-to-log code out of the loop wait()ing for processes to
> die, it makes more sense to iterate until the descriptors close, then
> reap child processes.
> 
> 5) Rationalise conditional compilation stuff. There may be more of that
> in a subsequent commit.
> 
> 6) Update the man page to reflect new reality (!)
> 
> Any remaining bugs are mine, but Petr please check that I didn't break
> things.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> On 24/03/17 17:38, Petr Mensik wrote:
>> Hi!
>>
>> Some guys using dnsmasq in virtual machines and OpenStack use custom 
>> dhcp_script to manage leases of clients.
>> However they complain if there is anything wrong with them, then are just 
>> told broken pipe and no information.
>>
>> We understand it should not produce any output under normal operation. But 
>> it would be really helpful if at least anything was visible in logs. 
>> Especially for errors happening under rare circumstances.
>> I have prepared patch to forward events from helper. It prevents SIGPIPE 
>> receiving if script does write anything. And logs it from dnsmasq.
>> It seems very handy to me.
>>
>> It was not simple to forward it to main log. I would like opinions if it is 
>> useful or dangerous.
>> Do you consider it worth merging Simon?
>>
>> Best Regards,
>> Petr
>> --
>> Petr Menšík
>> Software Engineer
>> Red Hat, http://www.redhat.com/
>> email: pemen...@redhat.com  PGP: 65C6C973
>>
>>
>>
>&

Re: [Dnsmasq-discuss] [PATCH] Logging of dhcp_script output

[Simon Kelley]

I like this. Yes, I know you can do it with shell magic, but this is
easier and what I would expect to happen.

I've changed the patch quite a lot:

1) Don't go to large effort to report "never happen" errors from pipe(),
just silently handle them in the same way as fork()

2) Don't do any of this when the -d debug flag is in effect, as it's
already defined that the script gets stdin, stdout and stderr from the
dnsmasq process in that case.

3) Expand the subject-based logging that already exists, DHCP stuff
comes from dnsmasq-dhcp, script output comes from dhcp-script. That
avoids the wordy preamble to every line otherwise.

4) Pull the copy-to-log code out of the loop wait()ing for processes to
die, it makes more sense to iterate until the descriptors close, then
reap child processes.

5) Rationalise conditional compilation stuff. There may be more of that
in a subsequent commit.

6) Update the man page to reflect new reality (!)

Any remaining bugs are mine, but Petr please check that I didn't break
things.


Cheers,

Simon.



On 24/03/17 17:38, Petr Mensik wrote:
> Hi!
> 
> Some guys using dnsmasq in virtual machines and OpenStack use custom 
> dhcp_script to manage leases of clients.
> However they complain if there is anything wrong with them, then are just 
> told broken pipe and no information.
> 
> We understand it should not produce any output under normal operation. But it 
> would be really helpful if at least anything was visible in logs. Especially 
> for errors happening under rare circumstances.
> I have prepared patch to forward events from helper. It prevents SIGPIPE 
> receiving if script does write anything. And logs it from dnsmasq.
> It seems very handy to me.
> 
> It was not simple to forward it to main log. I would like opinions if it is 
> useful or dangerous.
> Do you consider it worth merging Simon?
> 
> Best Regards,
> Petr
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com  PGP: 65C6C973
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 




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] dnsmasq needs to be restarted from time to time.

[Simon Kelley]

On 15/04/17 01:39, James Feeney wrote:
> It seems that, every so often, dnsmasq needs to be restarted - unless we blame
> WIDE dhcpv6.  Here, dnsmasq has been running for about a week, and a newly
> started dhcpv6 client will show things like this in the log:
> 
>  dhcp6c[412]: dhcp6_get_options: get DHCP option identity association, len 18
>  dhcp6c[412]:   IA_NA: ID=0, T1=0, T2=0
>  dhcp6c[412]: copyin_option: get DHCP option status code, len 2
>  dhcp6c[412]:   status code: no addresses
>  dhcp6c[412]: get_ia: make an IA: NA-0
>  dhcp6c[412]: update_ia: status code for NA-0: no addresses
>  dhcp6c[412]: update_ia: IA NA-0 is invalidated
>  dhcp6c[412]: remove_ia: remove an IA: NA-0
> 
> Restarting dnsmasq always makes things work again, for awhile, and the client
> log will show instead like:
> 
>  dhcp6c[412]: dhcp6_get_options: get DHCP option identity association, len 40
>  dhcp6c[412]:   IA_NA: ID=0, T1=1800, T2=3150
>  dhcp6c[412]: copyin_option: get DHCP option IA address, len 24
>  dhcp6c[412]: copyin_option:   IA_NA address: 2604:dead:beef:cafe::01
> pltime=3600 vltime=3600
>  dhcp6c[412]: dhcp6_get_options: get DHCP option status code, len 9
>  lapis dhcp6c[412]:   status code: success
> 
> I've mentioned this on the mailing list from time to time, but no response 
> yet.
> If anyone has ideas about how to debug dnsmasq when it begins sending an empty
> Nontemporary Address, please let me know.
> 
> Arch Linux
> dnsmasq 2.76-4
> 
> 

It would be useful if you turned on the dnsmasq option --log-dhcp and
posted the contemporaneous logs from dnsmasq.


Cheers,

Simon.


> ___
> 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] [PATCH] Do not set resolv.conf to 127.0.0.1 if port=0

[Simon Kelley]

Patch applied.

Cheers,

Simon.



On 01/04/17 22:27, Floris Bos wrote:
> dnsmasq's startup script seems to assume users always want to use
> dnsmasq as local DNS resolver, and tells resolvconf to put
> "nameserver 127.0.0.1" in /etc/resolv.conf
> The problem with this is that if users just want to use dnsmasq
> as DHCP server, and put port=0 in /etc/dnsmasq.conf to disable
> the DNS functionality, they end up with broken name resolving.
> 
> Put a basic check in the startup script that skips resolvconf
> configuration if a line starting with port=0 is in /etc/dnsmasq.conf
> This doesn't cover all cases (e.g. configuration could also be in
>  different file in /etc/dnsmasq.d), but is better than current
> situation.




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] client-identifier in server reply

[Simon Kelley]

On 10/02/17 01:22, Reddeiah Raju Konduru wrote:
> Hi,
> 
> I am using dnsmasq 2.72. In dhclient after setting client identifier to
> device mac address, I could see client-identifier option in DISCOVER and
> REQUEST messages. But dhcp server(dnsmasq) not setting client identifier
> option in OFFER and ACK replies.
> 
> As per RFC 6842 Section 3, If client is sending client-identifier server
> also MUST include this option in reply.
> 
> Is this feature implemented in dnsmasq?
> 

Could you elaborate a bit more on what you need this feature for. Since
implementing it, we've found one client which is broken by the presence
of client-ids and there may be more which mysteriously stop working.
Possibly only sending the client-id under certain circumstances may work
for you, without breaking sensitive clients.


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 support for unique TFTP root per MAC

[Simon Kelley]

On 10/04/17 00:09, Floris Bos wrote:
> On 04/09/2017 11:28 PM, Simon Kelley wrote:
>> Patch accepted, with one change
>>
>>
>>>   snprintf(daemon->namebuff+oldlen,
>>> sizeof(daemon->namebuff)-oldlen, "%.2x-%.2x-%.2x-%.2x-%.2x-%.2x/",
>>
>> daemon->namebuff is a char *, so sizeof(daemon->namebuff) is 4 or 8 and
>> sizeof(daemon->namebuff)-oldlen is a negative number which is a large
>> positive number when promoted  to unsigned size_t.
> 
> Ah, you are right.
> 
> Somehow I had the impression it was a fixed size array, on which
> sizeof() do would work.
> Probably confused it with the other namebuff in tftp_request ( char
> namebuff[IF_NAMESIZE]; )
> 
> Sorry, and thanks for the commit.
> 
> 

No problem. Security, I have to take responsibility for.  My tip for
sound sleep is not to be responsible for C code which runs as root on
100 million devices :)

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 v2] Add --dhcp-reply-delay option to delay DHCP replies

[Simon Kelley]

On 30/03/17 12:38, Floris Bos wrote:
> Adds option to delay replying to DHCP packets by one or more seconds.
> This provides a workaround for a PXE boot firmware implementation
> that has a bug causing it to fail if it receives a (proxy) DHCP
> reply instantly.
> 
> On Linux it looks up the exact receive time of the UDP packet with
> the SIOCGSTAMP ioctl to prevent multiple delays if multiple packets
> come in around the same time.
> 
> Signed-off-by: Floris Bos 

Committed, with a minor change for logging.

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] Add support for unique TFTP root per MAC

[Simon Kelley]

Patch accepted, with one change


> snprintf(daemon->namebuff+oldlen, sizeof(daemon->namebuff)-oldlen, 
> "%.2x-%.2x-%.2x-%.2x-%.2x-%.2x/",


daemon->namebuff is a char *, so sizeof(daemon->namebuff) is 4 or 8 and
sizeof(daemon->namebuff)-oldlen is a negative number which is a large
positive number when promoted  to unsigned size_t. There's thus
effectively no protection here against buffer overflow.

In such ways are security CVEs seeded :)

A changed sizeof(daemon->namebuff) to (MAXDNAME-1) which is the
buffer-size limit used elsewhere in this code.

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 & fingerbank.org

[Simon Kelley]

The current tree already has this functionality, though the code which
implements it is somewhat different. It certainly provides a
DNSMASQ_REQUESTED_OPTIONS variable containing a comma-separated list of
decimal numbers.

Best to look at the current code, and submit a patch if it doesn't
behave as you expect.


Cheers,

Simon.



On 09/04/17 19:22, Denton Gentry wrote:
> https://fingerbank.org/about.html is a database of OS signatures based
> on the DHCP options populated and the order in which they appear. So
> for example, an Android device will typically send
> '1,33,3,6,15,26,28,51,58,59' while iOS sends '1,3,6,15,119,252'.
> 
> We modified dnsmasq to export DHCP OS signatures to a
> DNSMASQ_REQUESTED_OPTIONS environment variable when it forks the
> dhcp-script. The environment variable is formatted to match
> fingerbank. The dhcp-script we run writes the signature to a separate
> file, though of course this behavior is outside of dnsmasq itself.
> 
> Is OS fingerprinting support something which could be more widely useful?
> Should I rebase the patch to the current tree and start discussion?
> 
> 
> 
> ___
> 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] bug: trunk DHCP offer/replies being ignored by some devices

[Simon Kelley]

On 08/04/17 12:01, Floris Bos wrote:
> On 04/08/2017 12:00 AM, Simon Kelley wrote:
>>
>> But RFC 6842 assures us that no clients are broken by this change :)
>>
>> The options here, as I see it are
>>
>> 1) revert the change and don't support 6842
>> 2) provide a way to disable the client-id reply for broken clients.
>> 3) provide a flag to disable the client-id for all clients.
>> 4) make the new behaviour optional, and provide a flag to enable it.
>> 5) declare it No Our Problem and get the broken clients fixed.
> 
> What about only sending client-id back if chaddr is zeroed?
> 
> Isn't that the corner case 6842 is actually trying to fix?
> 
> ==
>In some cases, a client may not have a valid hardware address to
>populate the 'chaddr' field and may set the field to all zeroes. One
>such example is when DHCP is used to assign an IP address to a mobile
>phone or a tablet and where the 'chaddr' field is set to zero in DHCP
>request packets.
> ==
> 

A good suggestion. The bald assertion that DHCP-relays drop packets
without chaddrs in 6842 seems quite dodgy to me, why should they, unless
the chaddr is needed to return the reply to the client?


I'll go offline from here and talk to some DHCP people...

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 treats Islands of Security as bogus

[Simon Kelley]

On 08/04/17 17:33, Patryk Szczygłowski wrote:
> 2017-04-04 22:24 GMT+01:00 Simon Kelley :
> 
>> Which version of dnsmasq are you using? I just tested this domain using
>> the development code, and got the correct result.
>>
> 
> 
> dnsmasq - 2.73-3
> 
> This is the version currently distributed by Turris Omnia (openwrt-based).
> 
> 


2.73 is old and gnarly in DNSSEC terms - it's been a long, hard road to
get this right in dnsmasq. I believe that the most recent public release
- 2.76 should behave correctly in this case.

I be grateful if you could test that, as a check that my tests are valid.


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] bug: trunk DHCP offer/replies being ignored by some devices

[Simon Kelley]

On 06/04/17 14:01, Pedro MG Palmeiro wrote:
> Dnsmasq trunk replies are being ignored by some devices, in my case, two
> epson printers (AL-M200).
> Dnsmasq 2.76 works fine.
> 
> This could be related with
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;
> =88a77a78ad27adc3ed87b7ee603643d26cb896ee
> 
> Please refer to
> https://bugs.lede-project.org/index.php?do=details&task_id=673
> for tcpdumps.
> 

But RFC 6842 assures us that no clients are broken by this change :)

The options here, as I see it are

1) revert the change and don't support 6842
2) provide a way to disable the client-id reply for broken clients.
3) provide a flag to disable the client-id for all clients.
4) make the new behaviour optional, and provide a flag to enable it.
5) declare it No Our Problem and get the broken clients fixed.


5) is possible - have you talked to Epson? the AL-M200 looks like a
current product, and likely has field-upgradable firmware.

1) is not attractive.

2) may be possible. There is already a config option to tell dnsmasq to
ignore _incoming_ client-ids for a particular client, that could be
extended to apply to _outgoing_ cones too.

Specifically, you'd need to add something like

dhcp-host=,id:*

to turn off this for just those machines.

4) is not attractive.

I'm interested in peoples opinions; a flag to kill the new client-uid
behaviour globally, or just for particular MAC/IP addresses, or based on
a tag?

A pity, the original patch was so simple...

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 v2] Add --dhcp-reply-delay option to delay DHCP replies

[Simon Kelley]

On 30/03/17 12:38, Floris Bos wrote:
> Adds option to delay replying to DHCP packets by one or more seconds.
> This provides a workaround for a PXE boot firmware implementation
> that has a bug causing it to fail if it receives a (proxy) DHCP
> reply instantly.
> 
> On Linux it looks up the exact receive time of the UDP packet with
> the SIOCGSTAMP ioctl to prevent multiple delays if multiple packets
> come in around the same time.
> 

Apologies for going silent on this. My house move is over and I'm
working through my email backlog. Fortunately, you (collectively) have
reached a good solution without my input :) I'm happy with the principle
of this patch, and will eyeball it in detail and commit in the next day
or two.


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] Support --server syntax in resolv-file

[Simon Kelley]

The overriding objection to this is that it adds to the syntax and
semantics of the resolv-file format, but dnsmasq doesn't "own" that
format: it's actually a libc configuration file, and dnsmasq takes
advantage of the fact that the format is "well known" to extract useful
information from it. If you start adding extra fields to
/etc/resolv.conf then the c-library will get upset.

I understand the desire to be able to specify resolvers dynamically with
the full set of source-address and routing options; that's actually
already available, and has been for a long time, using the DBus
interface to dnsmasq, which includes the "SetDomainServers" method,
which takes strings identical to argument to --server. I've not looked
at the code, but your previous patch to allow binding both IP and
interface should have automatically added that feature to
SetDomainServers. (if it didn't then I'd certainly take a patch to
correct that.)


Cheers,

Simon.



On 23/03/17 18:16, Kristian Evensen wrote:
> Automatically specifying which source address and interface to be used for
> communicating with a given DNS server is very convenient on multihomed hosts.
> Two use-cases I have had for this feature are:
> 
> * Several mobile broadband providers hand out private IP-addresses, but the 
> DNS
> servers are global. Unless special routing rules are added, then the default
> route will be used for resolving domains. This is not ideal, as it might lead 
> to
> higher latencies for replies, or an additional cost to the user if DNS 
> requests
> to the "local" servers are free.
> 
> * Several mobile broadband devices act as small routers, and some of the most
> popular types only hand out the same IP, DNS server, etc. To make matters 
> worse,
> if these devices loose connectivity, they will highjack any DNS request and
> reply with its own IP. If you have multiple of these devices, you risk being
> stuck without working DNS as all requests might be forwarded to the 
> disconnected
> device. Adding support for binding to interface and IP will make sure that
> requests are sent to the correct device. Some external tool will still be
> required to check that DNS is working fine and updating the resolv-file
> accordingly.
> 
> Dnsmasq already supports reading and binding to an ip-adress/interface through
> the --server option. This patch adds support for specifying which source 
> address
> and/or interface to use for a server in the resolv-file, using the same syntax
> as for --server. For example, in order to specify that source ip 100.76.125.47
> and interface wwan1 should be used to communicate with server 213.158.199.1, 
> the
> following line would have to be added to the resolv-file:
> 
> nameserver 213.158.199.1@100.76.125.47@wwan1
> 
> Since the syntax is not standard, the --multihomed-resolver command line 
> option
> must be enabled. Please note that lines with and without source
> address/interface can be mixed.
> 
> Since we now have two places where the interface-part of --server is parsed, I
> have factored out this parsing into a separate function. parse_server() is
> converted to use this function.
> 




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] dnsmasq treats Islands of Security as bogus

[Simon Kelley]

Which version of dnsmasq are you using? I just tested this domain using
the development code, and got the correct result.

dnsmasq: query[A] patryk.one.pl from 127.0.0.1
dnsmasq: forwarded patryk.one.pl to 8.8.4.4
dnsmasq: forwarded patryk.one.pl to 8.8.8.8
dnsmasq: dnssec-query[DS] pl to 8.8.8.8
dnsmasq: dnssec-query[DNSKEY] . to 8.8.8.8
dnsmasq: reply . is DNSKEY keytag 61045, algo 8
dnsmasq: reply . is DNSKEY keytag 14796, algo 8
dnsmasq: reply . is DNSKEY keytag 19036, algo 8
dnsmasq: reply pl is DS keytag 2216, algo 8, digest 2
dnsmasq: dnssec-query[DS] one.pl to 8.8.8.8
dnsmasq: dnssec-query[DNSKEY] pl to 8.8.8.8
dnsmasq: reply pl is DNSKEY keytag 2216, algo 8
dnsmasq: reply pl is DNSKEY keytag 55609, algo 8
dnsmasq: reply pl is DNSKEY keytag 53575, algo 8
dnsmasq: reply pl is DNSKEY keytag 61674, algo 8
dnsmasq: reply one.pl is no DS
dnsmasq: validation result is INSECURE
dnsmasq: reply patryk.one.pl is 213.5.10.12


Cheers,

Simon.

On 27/03/17 16:37, Patryk Szczygłowski wrote:
> Hello,
> 
> I have domain signed with DNSSEC: patryk.one.pl 
> The issue is, the parent one.pl  is completely void of
> DNSSEC support (and it will probably never get fixed).
> 
> Therefore:
> - . is signed
> - .pl is signed, no DS for .one.pl 
> - .one.pl  is NOT signed, no DNSKEY, no DS for
> .patryk.one.pl 
> - .patryk.one.pl  is signed
> 
> My domain is registered with dlv.isc.org , but this
> not important anymore, as they announced closing down.
> 
> Have a look here:
> http://dnsviz.net/d/patryk.one.pl/dnssec/
> 
> The issue is dnsmasq is returning BOGUS instead of INSECURE. In
> consequence the domain does not resolve.
> I believe it is in contradiction with RFC:
> https://tools.ietf.org/html/rfc4035#section-5.1
> 
> It should mark BOGUS only if top-bottom validation determies DS in
> parent but missing DNSKEY in child.
> 
> Current behaviour is promoting a race condition, when the domain owner
> enabled DNSSEC, but didn't upload DS to parent and/or it didn't propagate.
> 
> The same situation was few years ago, when TLDs were gradually enabled,
> when for a while they were signed with DNSKEY without DS being set on
> parent, only to be put several months later. There are still unsigned
> TLDs and I think they will stop being resolved completely when this
> happens again.
> 
> Google Public DNS behaviour is correct.
> 
> -- 
> Patryk Szczygłowski
> 
> 
> ___
> 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] dnsmasq treats Islands of Security as bogus

[Simon Kelley]

This is a real problem, and I plan to look at it (and all the other
stuff I've been ignoring.) ASAP. I'm moving house just now, so very
short of time. If I don't produce something by the end of next week,
please prod me again.


Cheers,

Simon.


On 27/03/17 16:37, Patryk Szczygłowski wrote:
> Hello,
> 
> I have domain signed with DNSSEC: patryk.one.pl 
> The issue is, the parent one.pl  is completely void of
> DNSSEC support (and it will probably never get fixed).
> 
> Therefore:
> - . is signed
> - .pl is signed, no DS for .one.pl 
> - .one.pl  is NOT signed, no DNSKEY, no DS for
> .patryk.one.pl 
> - .patryk.one.pl  is signed
> 
> My domain is registered with dlv.isc.org , but this
> not important anymore, as they announced closing down.
> 
> Have a look here:
> http://dnsviz.net/d/patryk.one.pl/dnssec/
> 
> The issue is dnsmasq is returning BOGUS instead of INSECURE. In
> consequence the domain does not resolve.
> I believe it is in contradiction with RFC:
> https://tools.ietf.org/html/rfc4035#section-5.1
> 
> It should mark BOGUS only if top-bottom validation determies DS in
> parent but missing DNSKEY in child.
> 
> Current behaviour is promoting a race condition, when the domain owner
> enabled DNSSEC, but didn't upload DS to parent and/or it didn't propagate.
> 
> The same situation was few years ago, when TLDs were gradually enabled,
> when for a while they were signed with DNSKEY without DS being set on
> parent, only to be put several months later. There are still unsigned
> TLDs and I think they will stop being resolved completely when this
> happens again.
> 
> Google Public DNS behaviour is correct.
> 
> -- 
> Patryk Szczygłowski
> 
> 
> ___
> 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] No more random source port

[Simon Kelley]

On 22/03/17 16:30, Risto Suominen wrote:

> Mar 20 22:12:00 risto-Macmini dnsmasq[30248]: using nameserver
> 8.8.8.8#53(via eth0)


This indicates that dnsmasq has been configured to force the packets to
the upstream server via eth0. To do that requires an operation on the
socket which can only be done as root, so the socket has to be
pre-allocated and there's no random source port.

It looks like dnsmasq is being configured by networkmanager via the
DBus, and I guess it's that which is doing the configuration of the
upstream server.


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 v2] Add support for binding to both interface and IP

[Simon Kelley]

Good stuff.

Patch applied.


Cheers,

Simon.


On 20/03/17 19:44, Kristian Evensen wrote:
> The current --server syntax allows for binding to interface or address. 
> However,
> in some (admittedly special) cases it is useful to be able to specify both. 
> This
> commit introduces the following syntax to support binding to both interface 
> and
> address:
> 
> --server X.X.X.X@IP@interface#port
> 
> Based on my tests, the syntax is backwards compatible with the current
> @IP/interface#port. The code will fail if two interface names are given.
> 
> v1->v2:
> * Add man page description of the extended server syntax (thanks Simon Kelley)
> 
> Signed-off-by: Kristian Evensen 



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] [RFC] Add --dhcp-reply-delay option to delay DHCP replies

[Simon Kelley]

As a patch, it looks pretty good.

The main problem I have is that the new option becomes one of the those
annoying things that have to be set to make things work, but have no
other value. There are already quite a few dnsmasq options which are
essentially "--dont-break" and if I can avoid another, I will.

You say that the PXE bug is "if it receives a (proxy) DHCP
reply instantly", is this really only with proxy DHCP? That's
believable: a PXE implementation which gets the proxy reply _before_ the
standard DHCP reply might well get confused and, let's face it, it
doesn't take much to confuse most PXE clients :-(

If that's the case, would it be enough to delay replies by a fixed time
always and only if they're proxy replies? That would have the effect of
making things just work, with needing a "--dont-break" option, and
wouldn't affect the normal use-case at all.

It's a bit more difficult to implement, but not impossible. worst case,
dhcp_reply() needs to return a flag indicating that PXE-proxy reply was
made, and the call to the delay routine made based on that.

Only other quibble is the duplication of all the poll-loop code into
dhcp_delay(). Would it be neater to make one routine handle waiting for
an icmp-ping reply and just waiting?

Cheers,

Simon.


On 20/03/17 18:37, Floris Bos wrote:
> Adds option to delay replying to DHCP packets by one or more seconds.
> This provides a workaround for a PXE boot firmware implementation
> that has a bug causing it to fail if it receives a (proxy) DHCP
> reply instantly.
> 
> On Linux it looks up the exact receive time of the UDP packet with
> the SIOCGSTAMP ioctl to prevent multiple delays if multiple packets
> come in around the same time.
> ---
> 
> Hi,
> 
> I have a need to introduce a delay before dnsmasq replies to DHCP
> packets.
> 
> Currently have the following working code, inspired by similar
> code in the icmp_ping() method.
> But was wondering if this is the right way to do this, or if there is
> perhaps a better method?
> 
> And if functionality like this would be welcome for upstream
> inclusion, or if the use-case is too obscure?
> 
> Yours sincerely,
> 
> Floris Bos
> ---
>  man/dnsmasq.8 |  5 +
>  src/dhcp.c| 15 +++
>  src/dnsmasq.c | 43 +++
>  src/dnsmasq.h |  3 ++-
>  src/option.c  |  8 
>  5 files changed, 73 insertions(+), 1 deletion(-)
> 
> diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
> index 059eafc..5030dae 100644
> --- a/man/dnsmasq.8
> +++ b/man/dnsmasq.8
> @@ -1790,6 +1790,11 @@ a router to advertise prefixes but not a route via 
> itself.
>  .B --ra-param=low,60,1200
>  The interface field may include a wildcard.
>  .TP
> +.B --dhcp-reply-delay=
> +Delays replying to DHCP packets for at least the specified number of seconds.
> +This can be used as workaround for bugs in PXE boot firmware that does not 
> function properly when
> +receiving an instant reply.
> +.TP
>  .B --enable-tftp[=[,]]
>  Enable the TFTP server function. This is deliberately limited to that
>  needed to net-boot a client. Only reading is allowed; the tsize and
> diff --git a/src/dhcp.c b/src/dhcp.c
> index 08952c8..bb45ad0 100644
> --- a/src/dhcp.c
> +++ b/src/dhcp.c
> @@ -342,6 +342,21 @@ void dhcp_packet(time_t now, int pxe_fd)
>if (iov.iov_len == 0)
>   return;
>  }
> +
> +  if (daemon->reply_delay)
> +{
> +  int starttime = now;
> +#ifdef HAVE_LINUX_NETWORK
> +  struct timeval tv;
> +
> +  /* Use timestamp of the UDP packet received as start time for delay */
> +  if (ioctl(fd, SIOCGSTAMP, &tv) == 0)
> + {
> +   starttime = tv.tv_sec;
> + }
> +#endif
> +  delay_dhcp(starttime, daemon->reply_delay);
> +}
>
>msg.msg_name = &dest;
>msg.msg_namelen = sizeof(dest);
> diff --git a/src/dnsmasq.c b/src/dnsmasq.c
> index d2cc7cc..f2b0a56 100644
> --- a/src/dnsmasq.c
> +++ b/src/dnsmasq.c
> @@ -1858,6 +1858,49 @@ int icmp_ping(struct in_addr addr)
>  
>return gotreply;
>  }
> +
> +void delay_dhcp(time_t start, int sec)
> +{
> +  /* Delay processing DHCP packets for "sec" seconds counting from "start",
> + while continuing to service events on the DNS and TFTP sockets */
> +
> +  int rc, timeout_count;
> +  time_t now;
> +
> +  for (now = dnsmasq_time(), timeout_count = 0;
> +   (difftime(now, start) <= (float)sec) && (timeout_count < sec * 4);)
> +{
> +  poll_reset();
> +  set_dns_listeners(now);
> +  set_log_writer();
> +
> +#ifdef HAVE_DHCP6
> +  if (daemon->doing_ra)
> + poll_listen(daemon->icmp6fd, POLLIN);
> +#endif
> +
> +  rc = do_poll(250);
> +
> +  if (rc < 0)
> + continue;
> +  else if (rc == 0)
> + timeout_count++;
> +
> +  now = dnsmasq_time();
> +
> +  check_log_writer(0);
> +  check_dns_listeners(now);
> +
> +#ifdef HAVE_DHCP6
> +  if (daemon->doing_ra && poll_check(daemon->icmp6fd, POLLIN))
> + icmp6_packet(now);
> +#endif
> +
> +#ifdef HAVE_TFTP
>

Re: [Dnsmasq-discuss] [PATCH] Add support for binding to both interface and IP

[Simon Kelley]

This slipped through, apologies. You're doing everything right, _except_
that a patch which includes the relevant changes to the man page would
make my life easier.

Cheers,

Simon.


On 17/03/17 15:28, Kristian Evensen wrote:
> A gentle ping on this patch :)
> 
> I tried to look, but couldn't find out the correct way of submitting
> patches to dnsmasq, so I don't know if there is somewhere else it
> should be sent?
> 
> Thanks,
> Kristian
> 
> ___
> 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] Support of labels in --interface

[Simon Kelley]

That seems a good solution. Patch applied, with the man=page changes
re-written and expanded.


Cheers,

Simon.


On 14/03/17 15:11, Petr Menšík wrote:
> Hi,
> 
> I have prepared two patches with suggestion how to fix it.
> 
> Patch 1 warns when a label is used for --interface in default mode.
> Patch 2 corrects manual page about real behavior of --interface with
> labels. Feel free to change it, I am not very good at complicated
> sentences in English.
> 
> I think changing it back again to use all addresses including labels
> would be wrong. Let's just warn user about unexpected results.
> 
> Hope that helps,
> Petr
> 
> Dne 21.2.2017 v 19:50 Simon Kelley napsal(a):
>>> The first problem is, manual page is not updated. It tells you
>>> cannot use labels, but you can. Also it does not tell you you can
>>> use -i eth0,eth0:0,eth0:1,lo, but that is minor change.
>>
>> Documentation point taken.
>>
>>
>>> Labels are now supported and dnsmasq is able to bind only to
>>> secondary IPv4 interface with different address. (Since 2.67!) It
>>> works well with --bind-interfaces. However it has inconsistent
>>> behavior with and without that option.
>>
>>> Let's say my configuration is: 4: virbr0:
>>>  mtu 1500 qdisc noqueue state UP
>>> group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
>>> ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
>>> global virbr0 valid_lft forever preferred_lft forever inet
>>> 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
>>> forever preferred_lft forever
>>
>>
>>> $ dnsmasq -i virbr0 will respond to queries to both addresses. It
>>> might be useful backward compatibility feature. However $ dnsmasq
>>> -i virbr0:1 Will respond only on address 192.168.122.254. Ok, call
>>> it a feature.
>>
>>> Problem is, $ dnsmasq -i virbr0 -z Will respond only on address
>>> 192.168.122.1, as I would expect.
>>
>>> $ dnsmasq -i virbr0:1 -z Behaves the same way, as without -z.
>>
>>> I think different behavior is an error. It might be a feature, but
>>> even then, it has to be documented. Opinions?
>>
>> The different behavior is certainly undesirable, and can be fixed.
>> Unfortunately, I can only see how to easily fix it so that the
>> --bind-interfaces case works the same way as the default.
> No, please don't do that. I think current state is the best version we
> can prepare now. Just correct the documentation and warn user if he or
> she tries to use unsupported combination.
>>
>> The problem is that the sockets API tells you the interface that the
>> packet arrived on, and that's what's checked with -i. In your example,
>> queries send to 192.168.122.1 and 192.168.122.254 both arrive at
>> interface virbr0, so there's no easy way to tell them apart, except by
>> looking at the address they were sent to and correlating that with the
>> list of interfaces and their addresses .
>>
>> That requires an up-to-date list of all interfaces, which means, if
>> you're going to behave well in the face of interfaces and addresses
>> coming and going, enumerating the list for every packet received,
>> which will likely kill performance.
>>
>> My feeling is that consistency is good, so I'll certainly make a
>> change, the question is, is the current behaviour of -i > name> as encompassing _all_ addresses associated with the interface OK?
>>
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>>
>>
>>> [1]
>>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d
>> 7e7dba32b6e64a3687d43928bc8e
>>
>>>  Cheers, Petr -- Petr Menšík Software Engineer Red Hat,
>>> http://www.redhat.com/ email: pemen...@redhat.com  PGP: 65C6C973
>>
>>
>>> ___ Dnsmasq-discuss
>>> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>>
>> ___
>> 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



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] Network booting with stateful IPv6 addressing

[Simon Kelley]

On 01/03/17 15:27, Derek Higgins wrote:
> On 28 February 2017 at 18:24, Simon Kelley  wrote:
> 
> 
> On 28/02/17 17:10, Derek Higgins wrote:
>>>> On 28 February 2017 at 16:43, Simon Kelley
>>>>  wrote: Could you post (or send to me) you
>>>> complete dnsmasq configuration. I'd
>>>>
>>>>> Here you go http://paste.openstack.org/show/600808/
>>>>
>>>> expect, if the IP address associated with the MAC address is in
>>>> use, for dnsmasq to log that and use a dynamically allocated
>>>> address instead.
>>>>
>>>>> Looking at it now, the addition of the static keyword in
>>>>> dhcp-range would be preventing this happening
> 
> Indeed. That explains that effect.
>>>>
>>>>
>>>> Why not nail the IP address using the client-id of the final OS
>>>> booted, rather thna using MAC addresses?
>>>>
>>>>> I've been trying to get this to work within the constraints of
>>>>> how openstack neutron starts dnsmasq, when neutron starts a new
>>>>> instance it doesn't know (if I understand things correctly) what
>>>>> the client-id will be, so MAC would be the only way it can
>>>>> associate a particular VM to a IP address.
>>>>
>>>>
> 
> Sigh. This has always been a problem, and it's got worse, not better,
> in the move to IPv6.
> 
> For DHCPv4, where MAC addresses are pretty much compulsory, there's a
> hack where client is allowed to either present or not a client-id, as
> long as the MAC address is identical. (It's not allowed to present two
> different client-ids, however.)
> 
> For DHCPv6, it's difficult to rely on the MAC address, since it's only
> made available at all by using nasty ARP-snooping hacks. Plus the MAC
> address to client-id function is less well defined. Then we have the
> problem that provisioning systems know about MAC addresses, but not
> client-ids.
> 
> The only possible solution I can come up with is to add filtering of
> dhcp-host lines by tag. You could thereby arrange that the dhcp-host
> line only applied to the final OS boot, and the earlier steps could be
> left to get dynamically allocated addresses. That would require a
> way to set a tag on the final (OS) dhcp request, but that's almost
> certainly possible; you're halfway there with the ipxe6 tag.
> 
>> I'll take a look into getting this to work in the env I'm using.
> 
>> I'd imagine this is a common enough case, is there a argument here to
>> add a dnsmasq flag to allow the IDs to change? If so I'd be happy to
>> work on a patch.
> 
> 

Allowing the IDs to change is a bad idea, since in DHCPv6 they are the
only thing that identifies a client. If you lease an address to a
CLID/IAID combo, then you can't lease it to another CLID/IAID until that
lease has expired. The same applies to DHCPv4, but in some cases,
because MAC addresses are much more strongly associated with clients in
DHCPv4 land, you can get away with it, as I explained.

The solution I'm proposing is to allow dhcp-host to be conditional on a
tag that can be set only when the final OS boots, so that the
intermediate boot stages can dynamically allocated addresses and the
leases for those just expire. The trick is to find a way of
distinguishing the PXE/bootloader DHCP requests from the OS ones, using
dhcp-match and/or tag-if to do the inspection and logic. As you have the
test harness there, that would be a useful thing to look at. The patch
to dnsmasq to allow dhcp-host to be conditional on a tag is trivial.

Cheers,

Simon.





> 
> Cheers,
> 
> Simon.
> 
> 
> 
>>>> Cheers,
>>>>
>>>> Simon.
>>>>
>>>>
>>>> On 28/02/17 10:07, Derek Higgins wrote:
>>>>>>> On 27 February 2017 at 21:51, Simon Kelley
>>>>>>>  wrote: I'm slightly confused as to
>>>>>>> the problem here. The identity of a lease if defined by the
>>>>>>> Client-ID and IAID, if those change then dnsmasq will
>>>>>>> allocate a new address. That means that your boot process
>>>>>>> will go through three different addresses, but should end up
>>>>>>> with a usable and stable address. It's not as if there is a
>>>>>>> shortage of IPv6 addresses, you can afford a couple of
>>>>>>> disposable addresses that only get used during the boot.
>>>>>>>
>>>>>>> What have I missed?
>>&g

Re: [Dnsmasq-discuss] [PATCH 2/2] rev-server: reject CIDR prefixes that are not /8 /16 /24 or /32 for IPv4

[Simon Kelley]

Both patches applied.


Cheers,

Simon.


On 05/03/17 10:13, Olivier Gayot wrote:
> The rev-server directive only handles the following CIDR prefixes
> properly: /8, /16, /24, /32.
> 
> Any other value was silently converted to /16 which could result in
> unexpected behaviour.
> 
> This patch rejects any other value instead of making a silent
> conversion.



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] Network booting with stateful IPv6 addressing

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 28/02/17 17:10, Derek Higgins wrote:
> On 28 February 2017 at 16:43, Simon Kelley
>  wrote: Could you post (or send to me) you
> complete dnsmasq configuration. I'd
> 
>> Here you go http://paste.openstack.org/show/600808/
> 
> expect, if the IP address associated with the MAC address is in
> use, for dnsmasq to log that and use a dynamically allocated
> address instead.
> 
>> Looking at it now, the addition of the static keyword in
>> dhcp-range would be preventing this happening

Indeed. That explains that effect.
> 
> 
> Why not nail the IP address using the client-id of the final OS 
> booted, rather thna using MAC addresses?
> 
>> I've been trying to get this to work within the constraints of
>> how openstack neutron starts dnsmasq, when neutron starts a new
>> instance it doesn't know (if I understand things correctly) what
>> the client-id will be, so MAC would be the only way it can
>> associate a particular VM to a IP address.
> 
> 

Sigh. This has always been a problem, and it's got worse, not better,
in the move to IPv6.

For DHCPv4, where MAC addresses are pretty much compulsory, there's a
hack where client is allowed to either present or not a client-id, as
long as the MAC address is identical. (It's not allowed to present two
different client-ids, however.)

For DHCPv6, it's difficult to rely on the MAC address, since it's only
made available at all by using nasty ARP-snooping hacks. Plus the MAC
address to client-id function is less well defined. Then we have the
problem that provisioning systems know about MAC addresses, but not
client-ids.

The only possible solution I can come up with is to add filtering of
dhcp-host lines by tag. You could thereby arrange that the dhcp-host
line only applied to the final OS boot, and the earlier steps could be
left to get dynamically allocated addresses. That would require a
way to set a tag on the final (OS) dhcp request, but that's almost
certainly possible; you're halfway there with the ipxe6 tag.

Cheers,

Simon.



> Cheers,
> 
> Simon.
> 
> 
> On 28/02/17 10:07, Derek Higgins wrote:
>>>> On 27 February 2017 at 21:51, Simon Kelley 
>>>>  wrote: I'm slightly confused as to
>>>> the problem here. The identity of a lease if defined by the
>>>> Client-ID and IAID, if those change then dnsmasq will
>>>> allocate a new address. That means that your boot process
>>>> will go through three different addresses, but should end up
>>>> with a usable and stable address. It's not as if there is a
>>>> shortage of IPv6 addresses, you can afford a couple of
>>>> disposable addresses that only get used during the boot.
>>>> 
>>>> What have I missed?
>>>> 
>>>>> IPs are being allocated to the MAC addresses in question
>>>>> via a hostfile (see below), so I guess dnsmasq is
>>>>> attempting to allocate the same IP address mutiple times,
>>>>> as its the same MAC but can't because of the changing IDs.
>>>> 
>>>>> This is dnsmasq as configured be openstack newtron
>>>> 
>>>>> bash-4.2$ cat 
>>>>> /var/lib/neutron/dhcp/5cf3b57b-72a3-4044-9528-1f5019e21826/host
>>>>>
>>>>> 
fa:16:3e:59:ef:60,host-fc00-101--2,[fc00:101::2]
>>>>> fa:16:3e:d8:9e:dd,host-fc00-101--3,[fc00:101::3] 
>>>>> fa:16:3e:d2:03:61,host-fc00-101--8,[fc00:101::8],set:ccbc492d-7b5d
- -4f
>
>>>>> 
9a-891c-92d66828f6dd
>>>>> 
>>>>> 
> fa:16:3e:69:89:d5,host-fc00-101--b,[fc00:101::b],set:ea1e2384-7ed7-495
6-
>
> 
bae0-d653c86c840c
>>>> 
>>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> Simon.
>>>> 
>>>> 
>>>> 
>>>> On 27/02/17 16:04, Derek Higgins wrote:
>>>>>>> I've recently been trying to use dnsmasq IPv6 to
>>>>>>> network boot, after a number of hurdles the last
>>>>>>> problem I've been having is that during the boot
>>>>>>> process (after dnsmasq initially hands out an IP
>>>>>>> address as part of PXE boot), it starts responding with
>>>>>>> "no addresses available".
>>>>>>> 
>>>>>>> The problem I'm hitting is that the IAID and the
>>>>>>> ClientID in the dhcp request changes during the
>>>>>>> process, - the IAID being used in PXE generated by the
>

Re: [Dnsmasq-discuss] Network booting with stateful IPv6 addressing

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Could you post (or send to me) you complete dnsmasq configuration. I'd
expect, if the IP address associated with the MAC address is in use,
for dnsmasq to log that and use a dynamically allocated address instead.

Why not nail the IP address using the client-id of the final OS
booted, rather thna using MAC addresses?


Cheers,

Simon.


On 28/02/17 10:07, Derek Higgins wrote:
> On 27 February 2017 at 21:51, Simon Kelley
>  wrote: I'm slightly confused as to the
> problem here. The identity of a lease if defined by the Client-ID
> and IAID, if those change then dnsmasq will allocate a new address.
> That means that your boot process will go through three different
> addresses, but should end up with a usable and stable address. It's
> not as if there is a shortage of IPv6 addresses, you can afford a
> couple of disposable addresses that only get used during the boot.
> 
> What have I missed?
> 
>> IPs are being allocated to the MAC addresses in question via a 
>> hostfile (see below), so I guess dnsmasq is attempting to
>> allocate the same IP address mutiple times, as its the same MAC
>> but can't because of the changing IDs.
> 
>> This is dnsmasq as configured be openstack newtron
> 
>> bash-4.2$ cat
>> /var/lib/neutron/dhcp/5cf3b57b-72a3-4044-9528-1f5019e21826/host 
>> fa:16:3e:59:ef:60,host-fc00-101--2,[fc00:101::2] 
>> fa:16:3e:d8:9e:dd,host-fc00-101--3,[fc00:101::3] 
>> fa:16:3e:d2:03:61,host-fc00-101--8,[fc00:101::8],set:ccbc492d-7b5d-4f
9a-891c-92d66828f6dd
>>
>> 
fa:16:3e:69:89:d5,host-fc00-101--b,[fc00:101::b],set:ea1e2384-7ed7-4956-
bae0-d653c86c840c
> 
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> On 27/02/17 16:04, Derek Higgins wrote:
>>>> I've recently been trying to use dnsmasq IPv6 to network
>>>> boot, after a number of hurdles the last problem I've been
>>>> having is that during the boot process (after dnsmasq
>>>> initially hands out an IP address as part of PXE boot), it
>>>> starts responding with "no addresses available".
>>>> 
>>>> The problem I'm hitting is that the IAID and the ClientID in
>>>> the dhcp request changes during the process, - the IAID being
>>>> used in PXE generated by the OVMF UEFI firmware is a function
>>>> including a time based seed[1] - this chain loads(in my case)
>>>> to an iPXE image that is using a crc of the mac address to
>>>> generate the IAID[2], - dhclient on the OS then uses the last
>>>> 4 octets of the MAC address for the IAID[3]
>>>> 
>>>> I have similar problems with ClientID but I havn't looked
>>>> into them in as much detail
>>>> 
>>>> check_address in dnsmasq/src/rfc3315.c is asserting that the
>>>> ID's can't change, and the only way I've gotten the boot
>>>> process to work locally is to comment out the checks in
>>>> check_address
>>>> 
>>>> As best I can see RFC 3315 does say that the IAID MUST
>>>> remain consistent across restarts of the DHCP client, but
>>>> then recognizes that "There may be no way for a client to
>>>> maintain consistency of the IAIDs if it does not have
>>>> non-volatile storage and the client's hardware configuration
>>>> changes"
>>>> 
>>>> Is there a way to allow these IDs to change? and if not
>>>> should this check be in dnsmasq? or would a patch to
>>>> optionally disable the check be acceptable?
>>>> 
>>>> thanks, Derek.
>>>> 
>>>> 
>>>> [1] - 
>>>> https://github.com/tianocore/edk2/blob/418373a1cd97abc0c0e3557f7a00
105
>
>>>> 
291829e6f/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c#L866
>>>> 
>>>> 
> [2] -
> https://github.com/qemu/ipxe/blob/c34d151/src/net/udp/dhcpv6.c#L97 
> 2
>>>> [3] - 
>>>> https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=clien
t/d
>
>>>> 
hc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
>>>> 
>>>> ___
>>>> 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.thekel

Re: [Dnsmasq-discuss] returns REFUSED when first response comes from non-recursive server

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The behaviour of believing the first REFUSED answer has been changed
for the forthcoming release.


There's a couple of long discussions about this on here.

Cheers,

Simon.

On 27/02/17 16:42, /dev/rob0 wrote:
> On Mon, Feb 27, 2017 at 04:40:14PM +0100, Daniel Pocock wrote:
>> On 27/02/17 13:31, Chris Novakovic wrote:
>>> On 27/02/17 10:04, Daniel Pocock wrote:
 
 I've observed the following problem:
 
 - dnsmasq is sending queries to 5 servers, one of them is not
  recursive and only answers for a private domain
 
 - if the first response dnsmasq receives comes from the 
 non-recursive server (REFUSED), then dnsmasq is sending a 
 REFUSED response to the client
 
 - dnsmasq subsequently receives a response from one of the 
 recursive servers
>>> 
>>> This is expected behaviour. One possibility is to configure 
>>> dnsmasq to forward requests to the non-recursive server only 
>>> for the private domain, e.g.:
>>> 
>>> --server=/private.domain/non.recursive.server.ip
>>> 
>>> and a matching --rev-server directive if appropriate.
>> 
>> The router is running OpenWRT, I could make that change manually
>>  but then I wouldn't be able to fully manage it with the GUI any
>>  more.
>> 
>> Can you confirm if this is the only way it can work according to
>>  the DNS spec, or is it a dnsmasq design decision?
> 
> --server without the domain specified MUST be a recursive server, 
> willing to resolve your queries for any names.
> 
> --server/domain.example/ip.add.re.ss will only send queries for 
> domain.example (and *.domain.example) to ip.add.re.ss.
> 
>> Could a software approach be taken by default, waiting to see if
>> any resolver provides a positive response before sending back
>> REFUSED to the client?
> 
> I don't see a valid use case for this.  You have a configuration 
> error, by listing a non-recursive server among your upstream 
> recursive servers.
> 
> Perhaps the OpenWRT people didn't know enough about dnsmasq to 
> support this situation, or perhaps they didn't care.  But dnsmasq 
> documentation of --server is clear enough about it.
> 
> Another problem you will have is when one of the actual upstream 
> recursive servers replies for "domain.example" with incorrect
> data.
> 
> (Side note: simple is good; listing more recursive servers will 
> generally not improve performance.  If some of the servers you're 
> listing are not reliable enough, try one of the Google Public DNS 
> addresses, or run your own recursive resolver.)
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYtJ+aAAoJEBXN2mrhkTWiRp4P/3B+B6+g4K6zDOd71J6oA5gM
Ap33LcRHWAwBWwMz7NVIrvjTSSQ06r301h7vS5xs3jFSm2j6onvft9cpz4OhkUpq
9h0t8xuNpA/4Tyhr0/f3w+qrrZe85IOOKnVfk2tRoWr3p7+u0yYYJ6+aFom/n4me
F3hBYK95fBGwk9n1dTLt0/a+KEjZA4Z9+aCx0YXpBhnjM15dfkrIyTyBI1FORmQ4
/WHJQiDbqeZ7IFpKQDt5LMhbgxe7a1zMrUbQ/+AJhvHCd04pw79xUvJdM5LEjQT3
r3tmirmdKCyQsdZsjUQTzxjaKu9uC25j8vT5KHrFwS3Qq5vucZ26uM/6FdwiIRBr
TvwNh5ccnlPz/Z3eZ/vZa/hmWcA6/Arfwas5knfhOpeyyYn7D0jC7cDs0WFySlha
9BdmZScxQtPzXoPk/bZg7BHp2N2uhk3zVwOMBVYYVTtmNL9DHQLJgktJ+0Ni16/W
YDVQQKD0LstDnGDh5AeFCNa1gBhrEkIW071IhEMQ1N5sGTml0NM0PXEVL35/sX58
oZGWj5UwVOM+TKK7q++zFCwTQES/SzJrTqlQ5rVlmk5S6b++vcfm7HABnUNXep1z
7fV1qxvChiayYBQjZc1j2TeTbDk7WAsKPXictlMwOfxqp/nTpF5nMaV+Jr+30Ned
HX3wzkH+rk1OdlkigpfD
=YTU9
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Network booting with stateful IPv6 addressing

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm slightly confused as to the problem here. The identity of a lease
if defined by the Client-ID and IAID, if those change then dnsmasq
will allocate a new address. That means that your boot process will go
through three different addresses, but should end up with a usable and
stable address. It's not as if there is a shortage of IPv6 addresses,
you can afford a couple of disposable addresses that only get used
during the boot.

What have I missed?


Cheers,

Simon.



On 27/02/17 16:04, Derek Higgins wrote:
> I've recently been trying to use dnsmasq IPv6 to network boot,
> after a number of hurdles the last problem I've been having is that
> during the boot process (after dnsmasq initially hands out an IP
> address as part of PXE boot), it starts responding with "no
> addresses available".
> 
> The problem I'm hitting is that the IAID and the ClientID in the
> dhcp request changes during the process, - the IAID being used in
> PXE generated by the OVMF UEFI firmware is a function including a
> time based seed[1] - this chain loads(in my case) to an iPXE image
> that is using a crc of the mac address to generate the IAID[2], -
> dhclient on the OS then uses the last 4 octets of the MAC address 
> for the IAID[3]
> 
> I have similar problems with ClientID but I havn't looked into them
> in as much detail
> 
> check_address in dnsmasq/src/rfc3315.c is asserting that the ID's 
> can't change, and the only way I've gotten the boot process to
> work locally is to comment out the checks in check_address
> 
> As best I can see RFC 3315 does say that the IAID MUST remain 
> consistent across restarts of the DHCP client, but then recognizes 
> that "There may be no way for a client to maintain consistency of
> the IAIDs if it does not have non-volatile storage and the
> client's hardware configuration changes"
> 
> Is there a way to allow these IDs to change? and if not should
> this check be in dnsmasq? or would a patch to optionally disable
> the check be acceptable?
> 
> thanks, Derek.
> 
> 
> [1] -
> https://github.com/tianocore/edk2/blob/418373a1cd97abc0c0e3557f7a00105
291829e6f/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c#L866
>
> 
[2] - https://github.com/qemu/ipxe/blob/c34d151/src/net/udp/dhcpv6.c#L97
2
> [3] -
> https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=client/d
hc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
>
>  ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYtJ9GAAoJEBXN2mrhkTWiXAwP/RZ+BE+gchcHXwz/wsGmz2gV
QyHEop+9EZU2FPDBycp0bSBsPeM02Z5ZRfuVslqk/mPZke1WDFqp88Xo5m2wTi09
SIPhk8P8ONAgYcxWy8SYUTPzYWFxTx6R7xyjZaM/gUbBYlzqvCf4KFNDrHsIw9eg
M+5M/pSvLHdA2ELAl1OaGgdC8UWgRIRKoBriSkcl17FwmT7UeLzWVB64NOxYxxGl
pxLjqZVOymfuY5XbjN6DMs431Z/sGIwsY8SBRWU8y1Sm++/Gb55JEYydu1+KXEyW
gx9yrdMH43D6uHp8g+o0C+xTWtoddJx93CwOHLeSRughe24f13Z3xsKbUQRycZRa
UJPKOHSmkO38e6tbGqAMDFtsmoXwXRBElYls32TcS1ai/YzSvkcapKYZh6oiX83Z
fo4+Iklyb87Dft5gj9TsBdr4A1C7Hf9W+A8FR8XL6V05/KT5Z9OS7UTH5vqGM+l/
1bYQsHk7rnNwGrSUyI+QJDLfhjibwwlYs0IeTPhUqexSwRXDiRd0uLH1ZhmLHBRm
8T81sV4S7NErqp3daUdXJdK6GFSp7i8jDMHZujo9Wju9x7fGl2ROVW6oJqQX+lN2
v05zFaXePJR+78gEKVEQP38QNDYnKct8dVHRvoSb+B6pjAWuTM2HgsF0y+x0phNv
JQQXY6kIaOIsjEDROC7q
=oMah
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Can you easily test newer code? Either git-HEAD or 2.77test3 has a fix
for a bug which looks remarkably like this, and it would be good to
eliminate that before going further.


Cheers,

Simon.


On 27/02/17 14:08, Igor Lidin wrote:
> I'm observing the following problem with dnsmasq 2.76 on arm7
> platform.
> 
> Dnsmasq is responing with bad packet, but shouldn't. This is
> somehow related to DNSSEC, ial.ru is signed.
> 
> this is through local dnsmasq forwarding server:
> 
> # dig soa guardian.ial.ru @127.0.0.1 ;; Got bad packet: bad
> compression pointer 131 bytes a8 45 83 80 00 01 00 01 00 01 00 01
> 08 67 75 61  .E...gua 72 64 69 61 6e 03 69 61 6c 02
> 72 75 00 00 06 00  rdian.ial.ru 01 c0 0c 00 05 00 01 00
> 00 0e 0f 00 10 08 67 75  ..gu 61 72 64 69 61 6e
> 02 75 6b 02 74 6f 00 c0 36 00  ardian.uk.to..6. 06 00 01 00
> 00 0e 10 00 2f 03 6e 73 31 06 61 66  /.ns1.af 72 61
> 69 64 03 6f 72 67 00 08 64 6e 73 61 64 6d
> raid.org..dnsadm 69 6e c1 d9 65 76 95 a3 00 01 51 80 00 00 1c 20
> in..evQ. 00 24 ea 00 00 00 0e 10 00 00 29 10 00 00 00 00
> .$). 00 00 00
> ...
> 
> this is though google dns on the same host:
> 
> # dig soa guardian.ial.ru @8.8.8.8
> 
> ; <<>> DiG 9.10.4-P5 <<>> soa guardian.ial.ru @8.8.8.8 ;; global
> options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status:
> NOERROR, id: 31031 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1,
> AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;;
> QUESTION SECTION: ;guardian.ial.ru.   IN  SOA
> 
> ;; ANSWER SECTION: guardian.ial.ru.12  IN  CNAME
> guardian.uk.to.
> 
> ;; AUTHORITY SECTION: uk.to.  1666IN  SOA
> ns1.afraid.org. dnsadmin.afraid.org. 1702270369 86400 7200 2419200
> 3600
> 
> ;; Query time: 63 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon
> Feb 27 14:05:09 UTC 2017 ;; MSG SIZE  rcvd: 131
> 
> this is related info:
> 
> # dnsmasq -v Dnsmasq version 2.76  Copyright (c) 2000-2016 Simon
> Kelley Compile time options: IPv6 GNU-getopt no-RTC no-DBus no-i18n
> no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset Tomato-helper
> auth DNSSEC loop-detect inotify
> 
> 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.
> 
> # uname -a Linux guardian 2.6.36.4brcmarm #1 SMP PREEMPT Thu Feb 2
> 21:42:22 CET 2017 armv7l GNU/Linux
> 
> # drill soa guardian.ial.ru Error: error sending query: Invalid
> compression pointer
> 
> # drill -v drill version 1.6.17 (ldns version 1.6.17) Written by
> NLnet Labs.
> 
> Copyright (c) 2004-2008 NLnet Labs. Licensed under the revised BSD
> license. There is NO warranty; not even for MERCHANTABILITY or
> FITNESS FOR A PARTICULAR PURPOSE.
> 
> Best regards, Igor Lidin
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYtE1UAAoJEBXN2mrhkTWi1zkP/384h/G/zTrQrbVVbr5ECp7t
oflpq7kBhHnxxPIwO0r0O7s7GGghIjTK3XcbXJ0vr8SUls14PKFtIwAyPevxvGhY
Ppf0ju9/QVuu3IZBxd+/6xSuMdgPTpz74+gNJx2t7f6LPYTWiQmOzhhJBTVH4Rzf
SoDpF1mfDDO6kzpJJCg24uDWJ0FPQVIKb/qcnBog1MOgRsbzdQ06DFl5nIHRzhg9
jXsRIgEGkvPLPPwCSzG9HpErhrRiJYHA4CC2aQWPyo9h8KXH9Ji9JYgysmnWCoNo
ky3hYA5UnzlyjEVKapR1hTf6WJRRr7mW7PwQKFX/LPrCCsrS+99KjRYin7h4frSM
23LWcFIyYEE9iGT7ZXqXEshpO63GEbh/z4VGzVPy0n0ZTudru+6t+p0i2yjBdQo0
Qwj3JYxa08d9tlc+Kz9w7F5gI2OzIzPy1aIJcV9m0pcq5HgjeVOj9yWeWFMrLkS0
KXFYvuiV4dbk6hKQLor0ZzwfpvBbOoQb1CCC1TM3jPsS+xU/5+tiBstU1nl+dglY
bjBOkC8j7PgjwJ9WJ0eiWBJqJcnrLMMZ7K7KPjnMyxlFUa6HMnZryefGhyfNKSzJ
Dg9RLFW/8GPoGi7PtiMofzQbIjiGNfhiNE1Z34w5G6uNkBU4TQtgaWRm9XqG/D9v
mMMw92pWtv42aNFkx842
=UkkJ
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] DNSSEC Trust Anchor Roll for 2017

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It's nice to be ahead of the game, for once :)

Simon.


On 26/02/17 05:53, Eric Luehrsen wrote:
> Never mind the idiot (me). It is already implemented in
> V2.77TEST3.
> 
> On 02/26/2017 12:46 AM, Eric Luehrsen wrote:
>> The next release trust-anchor.conf file should include DS record
>> (20326) as well as (19036). I am sure users would like a seamless
>> transition through new KSK introduction and former KSK revocation
>> in 2018. https://www.icann.org/resources/pages/ksk-rollover 
>> https://www.iana.org/domains/root
>> 
>> Eric
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYsqDaAAoJEBXN2mrhkTWi8d0P/2GxzmB84cCuTvYCSPyP5wCO
5HfCdmw/uNAQa3o2DLOE3OW1o0SLCA4xeycGVV/nINzmJ88iE8/Qim70BqMvUEeI
akNB9BMtjaq/TKrh0+Qy6qATUn/EP27Cq6qXnFni6k+6v51TMKScZUIdHcp7RMta
75YznhJecKcuI5ljQHoNCw6mEw2Oqldznwjgxz0lFLLsvPUhvVw3GmVZKp0O4LOR
O00iYV2FzjoDgcy9DO/5pHhw+/lBfHH9qcmnVpWDrUMPHVUr06MgViFrEH0N9AYX
g7kkH4JV6vXBKafwZTRypW3yEE8t0sBnegGxq7TOvjWfUolv0fSnS/zQTqUIDY+5
QaOruaYyr1iZENaLrK1qEw0GuBmZ5AjC++NutxV8/8RAH1bdn+upuFdKHDHigk45
it/RAG7JfGH0LTx7pigFayq5wAgKDXDeAm509g6oSURN0VIFM0CBh4z5hTjk7Rmm
/HMcldrdqESQSXZHm10JznACUHAHXjeFgfpbequ+5UvruuCX0RpoRg7hb/9PDgCJ
KdRjtgmXoaP8GYYNk5S5PqAqwi3dnUUizRAGHY/Fdh5WEbE4icAR6kZDa+uI1ztH
jF5lCvIoZGVnBrF4lLt5wAVqiF/VPOFUf7hOgEI8Y39lp7INeOA37exexzV9S1AI
HSjNVQ4b9DSRjE5igCvM
=U7lC
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Support of labels in --interface

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


> But you can also be notified about interface changes via a netlink 
> socket, so you can cache the interface information.
> 

See my reply to Petr: there is an option for that but it's not the
default for historical reasons.



Cheers,

Simon.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYr0t5AAoJEBXN2mrhkTWi4+AP/1kMh6YBHm2vgM3EACZPfLjN
X2IEPBk/dc/3UP3xbjt6ULy3TaNaCT7D0cqmapz0eaqwdlQO1p5Ur+9hFHYvibtP
YtaBhoByRZEPJMj1Fxvl6PpTsoc9XKToaslhOoaPsCJjs4Mi+OqVxmDQ+Yut6fmq
zrO0770Je7oKWMTI5AGUwCrwZw5a1UZQAxYYw1CsUQ6Rk3kuxfdfaSpQZrRnki9B
Vg+3yvKVXqtr/upEUQyOS36BD9MZKzXVrWkGMkZASykDu0PYoH6UdA3RM9B04Sa0
Inhd0M2acLwiDEhkKHpdV0v8vkCoKxPHtQ5EX6ayUcTyEKSPibT6MMVYNhiAvrRw
3MhLK+NGBKKaoeb3WMltQ80dvilgL3B+nr44Ip5FdJzJk9ZfVWsc5VnO+00py9bx
znByq+O8s39lNoN0s0gdlarmAjwdV3Z/0VNQ729hDhP4E3Q+vzSaQeQXmqNFzbuw
saV2lvgLsdFtN1HY0y/C2BPzEujt6ExE/LN5cfCy6BwgMcPgbyzdBy7juTbM6cD7
Das/WP7QtWSWSC+8rth7YPtlAOmP+rVGF8Z1igFC1H1nCb3JnMXiH2lej19Rh4h2
tXHslN9vABMEPaAY5IzJkfZgZ8B7HoskurTdwc1g6+LZnEjmvuLmBTcILRnTcEq9
+zi06zCiBda/iM7Kn2nM
=wVpC
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Support of labels in --interface

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 22/02/17 21:52, Petr Menšík wrote:

> I would suggest a new option then. For example
> --bind-interfaces-exact. It would listen just like
> --bind-interfaces, but would allow you to listen only on virbr0,
> when ignoring any addresses with labels. Current behavior in other
> words, but documented as a new feature. It would allow previous
> behavior at the same time also.

Ugh. There are already _three_ different modes for this.

The default (bind wildcard address), bind-interfaces (bind individual
addresses) and bind-dynamic (bind individual addresses, keep up with
changes in interface config)

On linux, there's actually no sane reason not to use --bind-dynamic,
and it's only not the default for historical reasons. The other two
modes still exist for *BSD where bind-dynamic doesn't exist and you
have the Hobson's choice of the other two: which is least-bad
depending on circumstances.

Since labels are a Linux-only thing, AFAIK, this whole problem may
best be solved by mandating that --bind-dynamic should be used on
linux if you want labels to work, and generating warnings if an label
!= interface name is found in the default mode. Or possibly ignoring
labels entirely in the default mode. And documenting same and that
- --bind-dynamic is needed to use labels. (or maybe --bind-dynamic or
- --bind-interfaces)


Apart from the documentation changes, that would involve removing
label_exception, so pre-2.67 behavior would return for the default
mode, ie --interface must give an interface name and label-aware
behavior would exist in --bind-dynamic ie --interface must give a label.


This stuff is all horrible: it's really difficult to even explain what
it's for and why  it needs to be configured.

Cheers,

Simon.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYr0sdAAoJEBXN2mrhkTWi8X0P/irtSCpt0AljtsjwKVhgYj0F
TlidegXBIQvnfk8gFZboI07twkB/iIp5La/xj/erpIDwnAR3/ntnq0yrXHhx27Qe
Ts1V1wHN0RnjxlzxJGiYVLJCE1Q8Pv/ckjdYgXdrXtrINzEer5vzb2/wvP5geyVg
0rx5tn6+JuiabZP0gDJASL1qHyozRgIKp0MNRMCzKrY+SMswjqrKVZwElCxbqELO
kP6mwfLsqzRXjESxLlO4h5TU3QqssfycDeEfuJZdCKUJkrIVEcKTnCjzl3+TNvRN
u/HW9gBWZaU/tKc3qEPlW6Tk8U9DKoXM9n7ml3goyhcBmeAENWHKn5TULoMR/Ns3
74HDDS/CKUgNW8u8iF2JD3yAHR7brki+PIuF5MjzP+czw56J/sWYpi/icHqU8tRH
oNxfONMcN9SmBB7JgQCD/TvlAl8mv/bbCs9QW+QQh/A6OigTudV1fx57Nig0YwvC
0usHS6LmX24PtcYRc/3wTrQFI9rsVBmBWVrYTRU1/b3FyVeLlOIXHK4SQ5fHVnvv
xM3BD1YC6etLZjvYdpRyRw6A9UcYvpbqIzXg+HG4EAgJskxf1lJdOIkYAI+qg+d5
3IeZ82wew1ZfjWTMuHVGwUCKaE1119JIr19iXyTfnrKxzP2dQ3rxZqCiCVNG4Equ
6n5FU197tGikv97kEtWo
=Rxi7
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] can't get multiple domains to work

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

You can have multiple domains, but you need to associate subnets with
them, so dnsmasq can determine which one to use.


Cheers,

Simon.



On 21/02/17 03:35, Spike wrote:
> I didn't because it seemed wrong, generally speaking the last entry
> for a given keyword should override former if dups are allowed at
> all. In any case I just tried and that's what happened, with
> 
> domain=good domain=better
> 
> host.better started to resolve and host.good no longer resolved.
> 
> that said it's true that the most recent hit on the ML for
> "multiple domain" did mention a similar setup with two domain lines
> altho it had two diff ranges.
> 
> thanks,
> 
> Spike
> 
> On Mon, Feb 20, 2017 at 6:55 PM richardvo...@gmail.com 
>   > wrote:
> 
> Have you tried using more than one domain= line?
> 
> On Mon, Feb 20, 2017 at 6:57 PM, Spike  > wrote:
> 
> Dear all,
> 
> first time poster here so first things first, thanks to all of you
> that have worked on dnsmasq, all of us here have greatly benefited
> for years from this great piece of software.
> 
> Second, my google-fu and manpage reading are failing me and I can't
> seem to find a way to have dnsmasq resolve queries for multiple
> domains. I've found some posts from 2008 about introducing the
> feature and a recent one about multiple domains, but for different
> ranges.
> 
> What I'm dealing with is a change of domain, so right now 
> dnsmasq.conf has domain=good and eventually it will be 
> domain=better , but during the transition phase it would be useful
> if it could be domain=good,better so that queries for host.good and
> host.better resolve to the same dhcp-host definition.
> 
> is that possible? what's the actual syntax? The manual mentions 
> "domainS", plural, but not if there is a particular syntax to 
> specify them and comma does not work (for example for local it 
> specifically mentions /domain/domain/).
> 
> I guess the alternative if the above isn't possible would be to 
> allow any kind of domain to basically be ignored so that entries 
> are returned as long as the host path matches (this is just during
> the transition phase so it would be ok)
> 
> thanks,
> 
> Spike
> 
> ___ 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYrf++AAoJEBXN2mrhkTWixi0P/A9xPahfW1hRbC2jtCnu+Cpb
v7AWBRRE81jkAdEMiawVfS/kinEku4BFFMVKbslw6q+R9HvrKoTHpi+CUGhAmEx2
4JEnsqfAS6yhqjfdu4pk7n2ZcmL7SDaiEdPCKFCd2ORaI05J+2ivfCqeKgwV+98Y
vjdXBnBrn8BO1yfijfVv0MqQDl8BYMcygzY0mfgVrC/4Ef7fKv7EV4DHrQ1TZkAD
9l5hyq17JpYc8VVJZRpB5hRO9QT6H4WR0RT8u5W0EodlilTOSEBygBbJm7LBXb7H
tTgxJ0+/H3BpX1uyJ7Y+xYdOnK+m/mpnivWGjaSVtrPRZ8k0ZdN/r5lGJ5sOpbhn
GRiwEJs0d+XgRUr8C6FkirJ91WN/V5Ka+ODwY9YMVt4o8o2X3uFC+fIV3I1/4RVd
b30+EnU9dXzeAxZ2jzs88pxX0R+wSpa7/Kj/wSHgFDn3YsMEiGVQtLqPVYnLxcNR
As0DbM5nwG6eSTxK5Bstgxs4IcUUu1VtG2hvnyMCfNSQDkh6b7o9t7FAn95DqBCN
rcAs3xdf4EO5cStIWXa3iBT/IsTBVuOh/+nZHgX/I1oXZkDTZU/pG9XAUBl0MuQ/
oj3yRZNVSCZ3QzQK78NrA9KmCTbuZvqMwDtlfJIvHom1wErpSz9fdUfaxpYYlYs3
+g5jhwh/nPcrgQS3wVX4
=t+QV
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Support of labels in --interface

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> You can get the destination address for datagrams from the
> IP_PTKINFO auxiliary data:
> 
> man 7 ip IP_PKTINFO (since Linux 2.2) Pass an IP_PKTINFO ancillary
> message that contains a pktinfo structure that supplies some
> information about the incoming packet. This only works for datagram
> oriented sockets.  The argument is a flag that tells the socket
> whether the IP_PKTINFO message should be passed or not. The message
> itself can only be sent/retrieved as control message with a packet
> using recvmsg(2) or sendmsg(2).
> 
> struct in_pktinfo { unsigned int   ipi_ifindex;  /* Interface index
> */ struct in_addr ipi_spec_dst; /* Local address */ struct in_addr
> ipi_addr; /* Header Destination address */ };
> 

Indeed. And that gives you, in one hand, the destination address of
the datagram, and in the other hand, a whitelist of interface labels.
The only way to compare the two is to enumerate all the interfaces
using the netlink interface, which gives you all the addresses of each
interface and their associated labels. If the interface set and
configuration can change arbitrarily, you need to do that for every
datagram, which gets expensive.


Cheers,

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYrfngAAoJEBXN2mrhkTWi4GsP/ApliVfiOsVguaMMAfY7MmJX
Q6ieWcPgNrQHXLgKjiJZpof2m9ZOvHKnR37rXNXW6v2x5J3vnRAaigil0j0wEb/u
3R733QI2eNkCOnzAmpO+zKDpkq/KjReEary6znOKp33U1B8kCMpPcJDDx3QZEkjS
qwAMgpsz3IKA+ezNgYbI/311B3RpMGt2XdvUNkHG9JDL2FAroS9/G0/vrmFKaDMZ
1+R09AtJBHvu/fOEbNcnl4r7mwwdMqd6ONPc6oqrah+gOkjdLWQe3M50fZ1aJC0y
r5HH+hp/MobyAxkF7gzbzt4VLG+fGU17ZanJZHRQgKnqsvj1e4pLdCP5wJ/4D1ya
ZlYQ6i3IjCVMXLS+y/tpJtPksnw49soHVOGObIpaT6lEEqX7BgTVvbFPv876aUn/
xkNvE83XzKPJ4LkKTR3cbXi5oJiglmDaClLgq+CRDdgu8cK41o/q6Fbv/gTs7X6N
AHurx+5X7AzArdJdF/cDrt7a7qA5GT7wonUgNZt8xXzW/WWlkMQ878aK2ij2kBFy
AYzeCpqyMyKZ0hEt3VgGo2p5k/cr/Wik5IaaXbrJZC33dRrVAWB6OdAXqmVED9ei
GavpRz+YYwHJaBQoo8ZFjDCEZHqWkFZszMO+B2DuDWYenB/QOCBUYWTEVgfPnPVw
w03CB2ZmjqWfZEHzfiW0
=QPnP
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Support of labels in --interface

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/02/17 17:38, Petr Mensik wrote:
> Hi!
> 
> I am new maintainer of dnsmasq package in RHEL. I am looking for
> potential problems with upgrade from dnsmasq 2.66 to version 2.76.
> And I have found something. Commit [1] changed behaviour of
> --interface eth0:0 behavior.
> 
> The first problem is, manual page is not updated. It tells you
> cannot use labels, but you can. Also it does not tell you you can
> use -i eth0,eth0:0,eth0:1,lo, but that is minor change.

Documentation point taken.

> 
> Labels are now supported and dnsmasq is able to bind only to
> secondary IPv4 interface with different address. (Since 2.67!) It
> works well with --bind-interfaces. However it has inconsistent
> behavior with and without that option.
> 
> Let's say my configuration is: 4: virbr0:
>  mtu 1500 qdisc noqueue state UP
> group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
> ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
> global virbr0 valid_lft forever preferred_lft forever inet
> 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
> forever preferred_lft forever
> 
> 
> $ dnsmasq -i virbr0 will respond to queries to both addresses. It
> might be useful backward compatibility feature. However $ dnsmasq
> -i virbr0:1 Will respond only on address 192.168.122.254. Ok, call
> it a feature.
> 
> Problem is, $ dnsmasq -i virbr0 -z Will respond only on address
> 192.168.122.1, as I would expect.
> 
> $ dnsmasq -i virbr0:1 -z Behaves the same way, as without -z.
> 
> I think different behavior is an error. It might be a feature, but
> even then, it has to be documented. Opinions?

The different behavior is certainly undesirable, and can be fixed.
Unfortunately, I can only see how to easily fix it so that the
- --bind-interfaces case works the same way as the default.

The problem is that the sockets API tells you the interface that the
packet arrived on, and that's what's checked with -i. In your example,
queries send to 192.168.122.1 and 192.168.122.254 both arrive at
interface virbr0, so there's no easy way to tell them apart, except by
looking at the address they were sent to and correlating that with the
list of interfaces and their addresses .

That requires an up-to-date list of all interfaces, which means, if
you're going to behave well in the face of interfaces and addresses
coming and going, enumerating the list for every packet received,
which will likely kill performance.

My feeling is that consistency is good, so I'll certainly make a
change, the question is, is the current behaviour of -i  as encompassing _all_ addresses associated with the interface OK?



Cheers,

Simon.




> 
> [1]
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d
7e7dba32b6e64a3687d43928bc8e
>
>  Cheers, Petr -- Petr Menšík Software Engineer Red Hat,
> http://www.redhat.com/ email: pemen...@redhat.com  PGP: 65C6C973
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYrIvyAAoJEBXN2mrhkTWiWzgP/RKGiOwyCG+IU2MZ5Ax453rM
ALXKz6tyFX/TszMPBLScH65en3IgzL+PrjXDbZu2fXpZXgg957D20wBPfCDHfPxJ
fnBRdWUQpB0W/M8+INJMSrYX+JS5iHfxmm8/5X/zUhedMfB1zhmskOAiHBbcjxCy
vGSvczc9FTNv5Q0/WD9v08EJiEJOfNyOLAGIQILSzVa7HkYpD5nLsJ0rCavoKtFk
OFyK1pA5Kx9QwSlkn7vMco/OU5iTOF9bQ+a7sYJp3mRhXtNdW41HMTEE8J57+tlP
OMkDaKCWnlXDzVfVD0q1cK36aof5IUXukGuuhOx6mEFKSLtpmoZWP7qAhX73KZYk
SKgnnWwZrNgDo5TFYdhCeSIco7bFnQtSgSHgX9VNv/QcLZzZxUfrxbpgyzLO4fvK
TO1YOq8RyHDfHxjS7L8QrPceRck/558L0mNgB09G8y75vIHMNPGghHzCL4AkL1VO
krFCiDrr4GEsGEWx/J2HWagFsRzavFzWAHdkgr2tQ3i7ATThV7+p3tcU164hYoOu
b7fbQk3O+GIpkvuzdG4UWZ4SmrbQ4kl6Q6MMgMsZfXGXqX7SrYXoobn0vPulZxm2
y6SfCTgbjUqTjfkNBNZM3wZyoM77pNhzIZiibHTr388fgbt/5L1xSavlwJqmR5VV
VXeTleBo8BUem7W6BV1B
=pWPX
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Scalability of DNS blackhole configuration?

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There are two ways to do this: one is the way you have.

The second is  using either a file in the same format as /etc/hosts
and --addn-hosts, using --host-record.

Either probably have similar memory-footprint implications, but the
first does wildcards, so your example actually matches
www.example.com, mail.example.com etc. The second doesn't do
wildcards, but will be much faster as you go through the next couple
of orders of magnitude.

There are no hard limits, but there are always pratical limits.


Cheers,

Simon.

On 16/02/17 19:19, Mike Lee wrote:
> Hi folks, I'm redirecting undesirable domains to a "black hole" to 
> prevent normal DNS resolution.
> 
> Specifically, I have this line in my dnsmasq.conf:
> 
> conf-file=/etc/dnsmasq-blackhole.conf
> 
> That file in turn has multiple lines of the form:
> 
> address=/example.com/127.0.0.1 
> 
> I just recently added a new source of domains from
> malwaredomains.com , and my
> blackhole.conf has now ballooned to roughly 20k lines.  Those 20k
> lines appear to consume about 3MB of memory.  The daemon appears to
> be running fine, but memory aside, for future reference is there a
> practical or hard limit to how this type of configuration will
> scale?  Will it gracefully handle 200k such domain configuration
> lines? 2M lines?
> 
> Thanks!
> 
> --Mike
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYqd9/AAoJEBXN2mrhkTWi2EMP/RmPgJFhIBn9en2hl6RTAQYR
YEC2NWt+8qdI0u6MyQUTqqtXVvM3b+AcuxX1OhQEfFu8NRgm03LcIYAAVNXRd73+
CkF9/t7lzGRsgo6RwJG9xDnJaFVaE93J0eCRzEm7PhdLWH7BuBhIUM5TAfmIKL4v
TKsFLOv5H0bZONq29UpBcO19MzRGC6JnsCzBSgLJbz+UK+n0y60HLdc+xegWGT68
EmdZXyMA6mYCEw0p0Q3UUGgclAQzd7XTkiwKezdZmfUK6t0UICLnmz907D7b3Frn
6rqW0Mh7o8rMQBk7LGXB+W5zQpswXV8wNtg2aUboEECqa9lHBZdd071Nf+M1SLcv
ybheNLrsXoIct9elTo9U9b6bqRgJUYXaRwDXviYCqCif41mnf51K9KDJP3kwM/we
NSLUqmYTnDkiEFrOXQHhLAkosKbs17B4+7jCIJk8D+6PInBpStc0Ms3PAp0fwK+o
wC8Mus7dOQU/1nMu4vSjyOD+CYOTGLqWotaOLIqAtIdfF/Z1zsgwWdezDux3tK9v
FwsXfBoA60pdWBZlhvMIYAtjyEvWM6tjKESUEfJ73nnbWRk1mj6g4eqSfFm/IKA/
PRpo0nHSQ69rw9YQt9CF5AgnjU7YAvCjptlDDwsoJRmLEf6tIJrqp29I9Y+M8506
iRDOQreoY3ZUVwsUPaEn
=SQMw
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] [PATCH] Accept /32 and /0 as valid CIDR prefixes for rev-server directive

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/02/17 22:46, Olivier Gayot wrote:
> On Tue, Feb 14, 2017 at 03:17:54PM +0000, Simon Kelley wrote:
>> That's an improvement, but I tend to agree that /0 doesn't make
>> much sense. If we're going to patch this, it seems to make more
>> sense to reject anything other that /32 /24 /16 or /8.
>> 
>> The  ideal solution would be to accept any prefix length and
>> generate the (up to) 256 --server equivalents  that it
>> corresponds to. If you're going to have syntactic sugar, it may
>> as well work for you.
> 
> That would be fantastic! I guess that would be up to 128 though. 
> However it sounds like a much bigger change than what I came up
> with. It will add some complexity.
> 
> To summerize, after reading your answer and rob0's answer, I think
> that there are three things that can be addressed:
> 
> - The first one being that /32 is not considered a valid value in
> the rev-server directive. And it would really be useful if it were.
> (That was the purpose of my patch in the first place).
> 
> - The second one being that values considered invalid (or at least
> not considered valid) in the rev-server directive are implicitly
> converted to /16. And I think they should be rejected instead (0
> included). Besides, /5 is also currently converted to /16
> without notice.
> 
> - And the last thing being a possible improvement: accepting any
> CIDR in the range [1; 32]. And indeed we would need to generate
> multiple server directives accordingly.
> 
> If you agree with the above, Simon, I think that I can quickly come
> up with two patches to address the first two issues. Would that be
> okay for you as a first step ?
> 

It would certainly be OK, and if you could also then do number three,
I'd be happy to have that patch too.


Cheers,

Simon.


> Kind regards,
> 
> Olivier
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYqd4DAAoJEBXN2mrhkTWibh4P/A/LsEE4JzQASHUVN6C0hpV3
H5Bl56gxZab5virbrP4a/6YXxiD1uQ9kBWFT+jKXacinUXkSDsQwtjs0xNGjpeov
4lv2XauRZZVEbdCPBx0wgLQQEM2s1hukDqw6eANeiN1ra+foAISB6SLx1vt9d7k3
PojcbBN48cLKOZtKWj4F559yPRYt3JBpi20x3henMeIsZB0MNPqYewbTzgKD2NCd
qvUw7vl4F/SYHHrYG0P70bB3yriKFHpVDASxA5VKUkXaX4jjsC1fF6yyFCq8AX2P
6KTQ/XHECxMCrLMmqWmyE4ZgSzg/fEKytBomWAkJtF2H4ORFc6zG4rhaVy7zHd/P
WMsziwfW9O5D66/qym5C9fxawUS9LAJ29J/f3ZXOkpVEq/ugJYSbvwQnbhallLeI
ZUid3zg0k18ujt+XeNaOvYMgZo+DMVUUqh7j6YI5L/e2MCL8ZL8PuplDC+yPP+GW
dFaZ/st+Hdu49PDvU44zwyoKLwNmuaFBGEP6DmxZqj7pnYqJ7KbB9FgLWE8+lcuy
GiIjvYGLR7kJFPEWJTXh2xHmKh+sWtQiFfjk/GyerkyKEItR5cbotxlBBrvu7y7g
Kdresj/IStw7eUm/uSTeAauszlrXGtlInb3CBAyif3EjZotXe3Wc2AYxqhu+SyTX
iGx9lz8pmbovB0TH7GPB
=JkSx
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Support of labels in --interface

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/02/17 17:38, Petr Mensik wrote:
> Hi!

> Let's say my configuration is: 4: virbr0:
>  mtu 1500 qdisc noqueue state UP
> group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
> ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
> global virbr0 valid_lft forever preferred_lft forever inet
> 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
> forever preferred_lft forever
> 

Quick question from the lazy: how do you set the "secondary" flag on
the second address?

ip addr add  dev virbr0 label virbr0:1

doesn't seem to.

Dunno if it matters, just want to replicate this exactly


Cheers,

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYpum7AAoJEBXN2mrhkTWi74gP/A1nDuRres/jwNlJBBa1Ooa1
GFS3gGsMTxlZpank4bsH9MUnezzLMwkTa/F3Pz2jztnVzGwSplmZqtqFQErYaLWR
wyJXGGeNNlRt/u2dChLMWTO/qyf2AVfa+Ght66npzwJ0laVVkBishPHDcCKPhLIY
Rv5+WSsgqFgUwMFpjj8xj0WJJU7iNjCG4G9dwlmHu9kElwnW9xiL9dC6dDZuLOrd
GHlDodp7c5L5R7UQkvnfmlLWCOgz6/21Z1LkLBlsDyjpQcX+e7G5shb7r2UEEX0o
5RX2+3utnyGAGysiaVF9logiGCN7Hx/dBhvwtrvdcDSxa944GavLtHVSftuwIGZG
RDZIMea2DixSJUuOjGJ0MIfLg6IeoigSGIlNgLP++EupOz6fqxT2iJbaQ0M4Mqtm
H6haQkMT7Xj5OUfdfptXmR89idQRoPP7WIGU8CPQrs70vLpdGwKoF7nbT3KqeVpK
C+9CvHAxFKtWoElIzVPn7Oa2Zz/alXBBXdIfRg5TEP0QrJZCgPBixZ9Yy5F2fVxE
fP88SazdH7Yq6HDlS6KfPPq6N+0IklD0Y6GoBcchxxPpJpKFCkhXAS8EKFb04QLg
ZgPOzu73LFmed9YAXSFggR+eMmxN2M5ImPidiW8/xLCvHgtvn3/EOEi3VcU2gOS6
wczS9ivnbdarmpyPP4i/
=8wXW
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Reading the dhcp.leases file

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Albert's suggestions are good, and you can't reliably read the leases
file - in gets modified by delete-and-rewrite, so if the timing is
wrong, you'll see an incomplete write.

DHCP script gets all the information needed to maintain a database
equivalent to the leases file, using whatever engine you prefer.



Cheers,

Simon.


On 12/02/17 05:53, Albert ARIBAUD wrote:
> Hi Sam,
> 
> Le Sat, 11 Feb 2017 16:06:55 -0600 Sam Weber 
> a écrit:
> 
>> In our system, when a change occurs to the DNS entries we want 
>> dnsmasq to respond to, we scan the directory of active entries
>> and then grep the dhcp.leases file to see if the entry exists
>> there.  If the entry is not found in the leases file, we omit it.
>> Once the scan and check is completed, we write a new hosts file
>> and then send SIGHUP to dnsmasq so it knows to read the new file.
>> This works well most of the time.  Sometimes, however, a
>> perfectly valid entry is not found in the dhcp.leases file so we
>> incorrectly omit the entry from the dnsmasq hosts file.  We can
>> see that the leases file gets written very often in our system,
>> and we think that sometimes we must be reading the leases file
>> whilst dnsmasq is writing it, resulting in our reading the file
>> when a value of interest has not yet been written.  Is this idea
>> of our sometimes reading an incomplete leases file a possibility?
>> Is there a workaround other than reading the leases file several
>> times?
> 
> Not sure I understand your problem right, so I'll rephrase it and
> let you tell me if that's what you do and want to happen:
> 
> - you have a list of names associated with IP addresses;
> 
> - you want to filter this list, keeping only the entries where the
> IP address is currently being leased;
> 
> - you want the filtered list to be used by dnsmasq in its name 
> resolution process.
> 
> - you want the list to be kept up to date with the current leases.
> 
> - IOW, you want DHCP clients that get an IP which appears in your 
> list one to be assigned the corresponding name in the DNS, and you 
> want the DNS to NOT map names in this list if the corresponding IP
> is not leased right now.
> 
> Is that it?
> 
> If so, /maybe/ dhcp-script is what you need or at least can help
> you detect when you need to run your update, as it would give you a
> sign that the leases just changed.
> 
> But it seems to me what you are doing is not really different from 
> what dnsmasq already does (i.e. reflexting DHCP names into the DNS)
> when the MAC-to-IP mapping is done with static leases and each
> dhcp-host line specifies a name.
> 
> If this is indeed what you are doing, then maybe you can achieve
> that with options dhcp-hostsfile and dhcp-ignore-names.
> 
> You'd use dhcp-hostsfile to point to your list written as a list
> of dhcp-host options, minus the "dhcp-host=" prefix.
> 
> You'd specify dhcp-ignore-names to make sure no host can overrule
> your list and choose its own name in its DHCP requests.
> 
> You would then only have to tell dnsmasq whenever your list changes
> by sending it SIGHUP, but you would not have to care about DHCP
> leases being granted or released, as that is automatically
> reflected in the DNS part of dnsmasq.
> 
> HTH (again, IIUC)
> 
> Amicalement,
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYox3bAAoJEBXN2mrhkTWiO7gP/0fTR+9xbNPupk1pDBbE/Y90
5XQ5/LnS++uqhfUYBL8UPzjqk+l1PpKKb3nvTlGGQ/Ul68UsZ968awQbvZQgFy0l
5WxrLyzTHnKLKzksII2ZKOGjOZ/fvU3+USHyPo6hgfKSQbCfV9+LyW3vYLBGfFMW
n84r6mCzeUSLTOAwzXk813x7z5suHaNs3Rhc0lxHUTI/Lim4Lvg9oJE6yKAP3pqY
YE7BhOvtIbGKx3JGrWoy6EyAvSzirci2b5Kol+gJ+rCi7TvTqUP5BdvLY0QLYdbY
BS7l4xxR8DWNJCrgwa+VMnEMeYIlSZ9vlkWBnGiw++ksI0M4K9C3kWAmIM0/Anfv
fBNGtjV4SsOlpydBbuQmizkZQty3NiWo1XqcGlPOS/0YVQhrLqyTBFmCbovLs0LU
v43Iqj2z01XcP+znD/FDlY41kgC3UHJPKR/1RhL966Yz7ZkHyl9d4unV2B69OLCE
gjN3HahWa8j9RJ7Y8rXmJeUbN7UPnZWuWUwR0dgid6qUMfnlo3EQniBbbNQW6Fso
EpB9N2R2npTs3cTitAJiE536Y+0jv0ICsX7GJUaWLxGGhqKmDxBQrF8V0sX1pO2g
5it7PWOY1cNONqG05QXlSsf83IMogOPlajEok6vKcsUSg/oy38HqH29UiW/fOr8N
WSvLT3mkikRqFv9hkCXZ
=Qo5a
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] client-identifier in server reply

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

There's a link that produces a patch file.


Cheers,

Simon.


On 13/02/17 22:18, Reddeiah Raju Konduru wrote:
> Hi Simon,
> 
> Can I get the access to patch? If not possible let me know when
> 2.77 will be available to public?
> 
> Thanks, Raju
> 
> 
> On Sat, Feb 11, 2017 at 9:05 AM, Simon Kelley
> mailto:si...@thekelleys.org.uk>> wrote:
> 
> On 10/02/17 01:22, Reddeiah Raju Konduru wrote:
>> Hi,
>> 
>> I am using dnsmasq 2.72. In dhclient after setting client
>> identifier to device mac address, I could see client-identifier
>> option in DISCOVER and REQUEST messages. But dhcp server(dnsmasq)
>> not setting client identifier option in OFFER and ACK replies.
>> 
>> As per RFC 6842 Section 3, If client is sending client-identifier
>> server also MUST include this option in reply.
>> 
>> Is this feature implemented in dnsmasq?
>> 
> 
> No, it's not implemented, but it should be, four years after the
> RFC.
> 
> 
> I just committed a patch to the git repo. It will be in 2.77.
> 
> Cheers,
> 
> 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 
> <http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
> 
> 
> 
> 
> -- Thanks & Regards,
> 
> Reddeiah Raju Konduru +918095133903
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYox0tAAoJEBXN2mrhkTWiX5AQAKkDTaE8QPAZ7OHpHpxDYlzh
MC2cm3+WnUFjDfEM+NgiX458jY+Vz0rVd+wVTQZimQUv+1SbBSLFMNtWs2fuMqB7
lK/rdNNh1kimWe43DW6Z5xQahG44lcvE2uImni2MsYms0nOHoyEEaP4E53I0xyMr
paNiHls7RQfY/0zvdSQDvojOEe9ql1hltOYL5wL2U6htwswYZFmCzS0JLj1jd2dq
tegWxP4c9PUFT0roTUloNpapzqGM+6ZMU7YkfJ1jr/9XXfCXsy5rXSjXZlIONTSH
E8KQE8dVNDvbbGJlrgw+6495273FpiL+m0CDM5VH9uy0RB1kBFcohpBs2ZkDty0T
NYe8/5WMPjwwsO9Pq9BUQPQJ6c/ilACOBl6OrYUWB0uoIOK8jK+PLMx5LVVNSVME
fIVK20p7PFdIIcdefUdFKgSkjps0ADWQCmdjBtmeBAsyCvvfb6zU2ko1m24RcKQU
ikXPSjfLOWEoHDKcO8/rMgIIjM0AEj/h9JbKpzQsK7qooUM9Ro5cX+fb7dVbEB16
PbuzhS4aYefLr8zFief9rPLVwINAwtKyRk4V3VoP6HVCVL4i60SlclVlaKZ/NmpN
s1V+ZD0FZ6lb9jNsIbM9PauQOD4wOVu1ILwN+mnmzgikL/X14fLlNZYIekQrCQwD
gc9usyn0Z5YIkVdbVurn
=tzEi
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] [PATCH] Accept /32 and /0 as valid CIDR prefixes for rev-server directive

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

That's an improvement, but I tend to agree that /0 doesn't make much
sense. If we're going to patch this, it seems to make more sense to
reject anything other that /32 /24 /16 or /8.

The  ideal solution would be to accept any prefix length and generate
the (up to) 256 --server equivalents  that it corresponds to. If
you're going to have syntactic sugar, it may as well work for you.


Cheers,

Simon.



On 13/02/17 23:31, olivier.ga...@sigexec.com wrote:
> From: Olivier Gayot 
> 
> [ excerpt from the man page ] The rev-server directive provides a
> syntactic sugar to make specifying address-to-name queries easier.
> For example --rev-server=1.2.3.0/24,192.168.0.1 is exactly
> equivalent to --server=/3.2.1.in-addr.arpa/192.168.0.1
> 
> It is not mentioned in the man page but specifying anything but /8
> or /24 as the CIDR prefix has the same effect as specifying /16.
> 
> It is not a big deal for subnets on non-octet boundaries since
> they cannot be represented using a single in-addr.arpa address.
> However, it is unconvenient for /32 and /0 prefixes while their
> analogous server directives behave as expected. E.g. the following
> server directives work as expected:
> 
> server=/42.10.168.192.in-addr.arpa/1.2.3.4 
> server=/in-addr.arpa/1.2.3.4
> 
> but the following do not:
> 
> rev-server=192.168.10.42/32,1.2.3.4 
> rev-server=192.168.10.42/0,1.2.3.4
> 
> and, in practice, they behave the same as:
> 
> server=/168.192.in-addr.arpa/1.2.3.4 
> server=/168.192.in-addr.arpa/1.2.3.4
> 
> This strange behaviour is fixed by accepting /32 and /0 CIDR
> prefixes as valid values. Any other value will still be considered
> the same as /16.
> 
> Signed-off-by: Olivier Gayot  --- 
> src/option.c | 31 +-- 1 file changed,
> 21 insertions(+), 10 deletions(-)
> 
> diff --git a/src/option.c b/src/option.c index 4a5ef5f..eeca3d6
> 100644 --- a/src/option.c +++ b/src/option.c @@ -850,19 +850,30 @@
> char *parse_server(char *arg, union mysockaddr *addr, union
> mysockaddr *source_a static struct server *add_rev4(struct in_addr
> addr, int msize) { struct server *serv = opt_malloc(sizeof(struct
> server)); -  in_addr_t  a = ntohl(addr.s_addr) >> 8; +  in_addr_t
> a = ntohl(addr.s_addr); char *p;
> 
> memset(serv, 0, sizeof(struct server)); -  p = serv->domain =
> opt_malloc(25); /* strlen("xxx.yyy.zzz.in-addr.arpa")+1 */ - -  if
> (msize == 24) -p += sprintf(p, "%d.", a & 0xff); -  a = a >>
> 8; -  if (msize != 8) -p += sprintf(p, "%d.", a & 0xff); -  a =
> a >> 8; -  p += sprintf(p, "%d.in-addr.arpa", a & 0xff); +  p =
> serv->domain = opt_malloc(29); /*
> strlen("xxx.yyy.zzz.ttt.in-addr.arpa")+1 */ + +  switch (msize) +
> { +case 32: +  p += sprintf(p, "%d.", a & 0xff); +  /*
> fall through */ +case 24: +  p += sprintf(p, "%d.", (a >>
> 8) & 0xff); +  /* fall through */ +default: +case 16: +
> p += sprintf(p, "%d.", (a >> 16) & 0xff); +  /* fall through
> */ +case 8: +  p += sprintf(p, "%d.in-addr.arpa", (a >> 24)
> & 0xff); +  break; +case 0: +  p += sprintf(p,
> "in-addr.arpa"); +}
> 
> serv->flags = SERV_HAS_DOMAIN; serv->next = daemon->servers;
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYox+hAAoJEBXN2mrhkTWiBSUQAJQxq6yD3Tcw/39On0QcLcfy
aZTerALrzgrwlpyH4yVWeztrA3pFK1uVLIhnQP161zR+NJRI5Bo0J7tAOElETm3k
QQ0HEu16skPHdmzlmbR1MMLoVKn4myh6hDm5iFSAf+jsCpItAzYo5Cy9/oAz3PNU
Hp1SKxYNwrcSTw5FQrLpNuhZxbqvkA5KiU3URcnzv3mW2YbMzcjrULL7hF7xfN0t
2iwI8shObm/3FMDux7jX1wuRPQALWokaXFhAyOTDUVBONavA4W/PxS+8VvV4noi4
dFh6FMhJYPggUh7v02PTOoPtSuvaLNGt1vgWeHt1sqTXEo6rVsft085fKwH1uONw
SGWrGhnFaVDewHeEoB46K6qg7LYSoLa1cgv8li8QJ9ZTSiFC7ZqIWsXBQ5oqlGzr
0iR6jo1yqISvwyek8nogsgNWI4zx/mmC1AXhR/OjE8Y/3MA87rhpY+t/U2ZJug5e
f611DvKCl4iQuL/EyWY7hCIK7XCHi4ACx7sosN21zgL2/ToLshaF7i3rcYC6F/Bx
5GGgv6x6WiXWRMk82YiqcEphnOdphsWen4ZMHTdlBIzZ1EXpD5XwhDHTzzmD3SlT
oNjwPR1Gmkt1yXxLSvvr6mp7XFRDQOJMWDHvmfroH4p2hcxyB/2dSbhLjrfri0nL
WsjDDAhdIM1aHokLmLqi
=mtD9
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] client-identifier in server reply

[Simon Kelley]

On 10/02/17 01:22, Reddeiah Raju Konduru wrote:
> Hi,
> 
> I am using dnsmasq 2.72. In dhclient after setting client identifier to
> device mac address, I could see client-identifier option in DISCOVER and
> REQUEST messages. But dhcp server(dnsmasq) not setting client identifier
> option in OFFER and ACK replies.
> 
> As per RFC 6842 Section 3, If client is sending client-identifier server
> also MUST include this option in reply.
> 
> Is this feature implemented in dnsmasq?
> 

No, it's not implemented, but it should be, four years after the RFC.


I just committed a patch to the git repo. It will be in 2.77.

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] decrease the amount of individual sites listed in log

[Simon Kelley]

Patch applied. Many thanks.


Cheers,

Simon.

On 07/02/17 18:03, Hannu Nyman wrote:
> By default 30 first servers are listed individually to system log, and
> then a count of the remaining items. With e.g. a NXDOMAIN based adblock
> service, dnsmasq lists 30 unnecessary ad sites every time when dnsmasq
> evaluates the list. But the actual nameservers in use are evaluated last
> and are not displayed as they get included in the "remaining items" total.
> 
> Handle the "local addresses only" separately and list only a few of them.
> Remove the "local addresses only" from the general count.
> 
> Signed-off-by: Hannu Nyman 
> ---
> 
> --- a/src/config.h
> +++ b/src/config.h
> @@ -27,6 +27,7 @@
>  #define FORWARD_TEST 50 /* try all servers every 50 queries */
>  #define FORWARD_TIME 20 /* or 20 seconds */
>  #define SERVERS_LOGGED 30 /* Only log this many servers when logging state */
> +#define LOCALS_LOGGED 8 /* Only log this many local addresses when logging 
> state */
>  #define RANDOM_SOCKS 64 /* max simultaneous random ports */
>  #define LEASE_RETRY 60 /* on error, retry writing leasefile after 
> LEASE_RETRY seconds */
>  #define CACHESIZ 150 /* default cache size */
> --- a/src/network.c
> +++ b/src/network.c
> @@ -1438,6 +1438,7 @@ void check_servers(void)
>struct server *serv;
>struct serverfd *sfd, *tmp, **up;
>int port = 0, count;
> +  int locals = 0;
>  
>/* interface may be new since startup */
>if (!option_bool(OPT_NOWILD))
> @@ -1541,7 +1542,11 @@ void check_servers(void)
>   s1 = _("domain"), s2 = serv->domain;
> 
> if (serv->flags & SERV_NO_ADDR)
> - my_syslog(LOG_INFO, _("using local addresses only for %s %s"), 
> s1, s2);
> + {
> +   count--;
> +   if (++locals <= LOCALS_LOGGED)
> + my_syslog(LOG_INFO, _("using local addresses only for 
> %s %s"), s1, s2);
> + }
> else if (serv->flags & SERV_USE_RESOLV)
>   my_syslog(LOG_INFO, _("using standard nameservers for %s %s"), 
> s1, s2);
> else 
> @@ -1558,6 +1563,8 @@ void check_servers(void)
>   }
>  }
>
> +  if (locals > LOCALS_LOGGED)
> +my_syslog(LOG_INFO, _("using %d more local addresses"), locals - 
> LOCALS_LOGGED);
>if (count - 1 > SERVERS_LOGGED)
>  my_syslog(LOG_INFO, _("using %d more nameservers"), count - 
> SERVERS_LOGGED - 1);
>  
> 


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

Re: [Dnsmasq-discuss] [PATCH] Stop treating SERVFAIL as a successful response from upstream servers

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Patch applied. Thank you.

And thank you for the comprehensive documentation.

The original change was made as a part of the DNSSEC stuff, and I have
a nagging feeling that there was some, theoretical, situation that
could occur in conjunction with DNSSEC which prompted the change.
Despite much puzzling, I can't come up with waht this might have been,
so I've applied the patch. If it breaks with DNSSEC, we'll find out,
but I suspect I'm chasing shadows.


Cheers,

Simon.


On 01/02/17 22:54, Baptiste Jonglez wrote:
> From: Baptiste Jonglez 
> 
> This effectively reverts most of 51967f9807 ("SERVFAIL is an
> expected error return, don't try all servers.") and 4ace25c5d6
> ("Treat REFUSED (not SERVFAIL) as an unsuccessful upstream
> response").
> 
> With the current behaviour, as soon as dnsmasq receives a SERVFAIL
> from an upstream server, it stops trying to resolve the query and
> simply returns SERVFAIL to the client.  With this commit, dnsmasq
> will instead try to query other upstream servers upon receiving a
> SERVFAIL response.
> 
> According to RFC 1034 and 1035, the semantic of SERVFAIL is that of
> a temporary error condition.  Recursive resolvers are expected to
> encounter network or resources issues from time to time, and will
> respond with SERVFAIL in this case.  Similarly, if a validating
> DNSSEC resolver [RFC 4033] encounters issues when checking
> signatures (unknown signing algorithm, missing signatures, expired
> signatures because of a wrong system clock, etc), it will respond
> with SERVFAIL.
> 
> Note that all those behaviours are entirely different from a
> negative response, which would provide a definite indication that
> the requested name does not exist.  In our case, if an upstream
> server responds with SERVFAIL, another upstream server may well
> provide a positive answer for the same query.
> 
> Thus, this commit will increase robustness whenever some upstream
> servers encounter temporary issues or are misconfigured.
> 
> Quoting RFC 1034, Section 4.3.1. "Queries and responses":
> 
> If recursive service is requested and available, the recursive
> response to a query will be one of the following:
> 
> - The answer to the query, possibly preface by one or more CNAME 
> RRs that specify aliases encountered on the way to an answer.
> 
> - A name error indicating that the name does not exist.  This may
> include CNAME RRs that indicate that the original query name was an
> alias for a name which does not exist.
> 
> - A temporary error indication.
> 
> Here is Section 5.2.3. of RFC 1034, "Temporary failures":
> 
> In a less than perfect world, all resolvers will occasionally be
> unable to resolve a particular request.  This condition can be
> caused by a resolver which becomes separated from the rest of the
> network due to a link failure or gateway problem, or less often by
> coincident failure or unavailability of all servers for a
> particular domain.
> 
> And finally, RFC 1035 specifies RRCODE 2 for this usage, which is
> now more widely known as SERVFAIL (RFC 1035, Section 4.1.1. "Header
> section format"):
> 
> RCODE   Response code - this 4 bit field is set as part of 
> responses.  The values have the following interpretation: (...)
> 
> 2   Server failure - The name server was unable to
> process this query due to a problem with the name server.
> 
> For the DNSSEC-related usage of SERVFAIL, here is RFC 4033 Section
> 5. "Scope of the DNSSEC Document Set and Last Hop Issues":
> 
> A validating resolver can determine the following 4 states: (...)
> 
> Insecure: The validating resolver has a trust anchor, a chain of 
> trust, and, at some delegation point, signed proof of the 
> non-existence of a DS record.  This indicates that subsequent 
> branches in the tree are provably insecure.  A validating resolver 
> may have a local policy to mark parts of the domain space as 
> insecure.
> 
> Bogus: The validating resolver has a trust anchor and a secure 
> delegation indicating that subsidiary data is signed, but the 
> response fails to validate for some reason: missing signatures, 
> expired signatures, signatures with unsupported algorithms, data 
> missing that the relevant NSEC RR says should be present, and so 
> forth. (...)
> 
> This specification only defines how security-aware name servers
> can signal non-validating stub resolvers that data was found to be
> bogus (using RCODE=2, "Server Failure"; see [RFC4035]).
> 
> Notice the difference between a definite negative answer
> ("Insecure" state), and an indefinite error condition ("Bogus"
> state).  The second type of error may be specific to a recursive
> resolver, for instance because its system clock has been
> incorrectly set, or because it does not implement newer
> cryptographic primitives.  Another recursive resolver may succeed
> for the same query.
> 
> There are other similar situations in which the specified behaviour
> is similar to 

Re: [Dnsmasq-discuss] Spelling fixes for dnsmasq

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Patch applied, many thanks for that.

(I'll reject the message containing the patch from the mailing list,
to save all the subcribers from a 110K message. If they want to see
what was in it, they can look in the git repo now.)


Cheers,

Simon.


On 05/02/17 14:13, Josh Soref wrote:
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYmKIwAAoJEBXN2mrhkTWiH40QAI/lqpcJ0jiTxH0Zexlwfsud
ArbVAS5baT8Zm2kusq+KRYZzHrnT8VG1vkGfGF0j6Qxa+llj9AkATJyYXt3xV4N8
Z+uetX5quHUgvDzP+2HB8lBmcYkFj457I/t5qcfH54vnlwdxrXIpWgUDnqWv2Dpp
tQosrJo3NMr4TLJgtwRO6ZoDEU+kAX+0AUStBqp9gdBIuAElCZtEbBChVeOewDR3
q8l5P82fcNNFNaGN2lo3ckUc18/yboJRTeEKtsb7L6Dz8C1RFgNiLpSqtZJxfJPa
lpI/zzS5PprJ4tKOjbh8Z3ra99UK/Y3tV9IMoTeTIgFFMGm8evKutlgxnjY2zBV5
zs03NVp8sg7eQ9IOKlXXJZfvp8nGsNvWC2TkFbdzffz9m7AoengOpBG0/VW7AI0l
TeQ/a8p2r7PSV4Zv/6xiP7aPHPMs01mF7mMtNYXsNl1v2sKc/FUVSGXXpYG2jsd7
9RN7Y7WifZhtoctxzB/NNXEeHibfH3etpjxV6/uuLg0grSZOUGJJuW25gSbiXSTO
wzUnXQirk7jfleKhWBOWcFt/lE6pBq5HAd80ponKyUi/nGtrTZPQi1lB6snS8cl/
csvHtSEzJHV3SS0gX8VXx7Z6XX6jI/V/oqQVnxW23hDEoJLypQAid+rLGdt5P3BD
8Smsw3HlPR/M0RDiJwvV
=ccNl
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Spelling fixes for dnsmasq

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This may explain the Entire State of the World Today.

Simon.


On 02/02/17 17:05, Jim Alles wrote:
> Careful, we could have a fatal recursion:
> 
> quible is speeled wrong.
> 
> (smiley face)
> 
> .ja.
> 
> On Thu, Feb 2, 2017 at 8:30 AM, Simon Kelley
> mailto:si...@thekelleys.org.uk>> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> 
> Wow, what a lot of typos! ​...​
> 
> 
> Modulo that, and Neil's quible, I'd love to take this as a diff.
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYk2t/AAoJEBXN2mrhkTWi7HAP/27eI2wImMIt6KbEBfIXdRm3
4d1Mobkb4yM4Xt+WARKXwnf1E3JN2/C6tpTfrbpkx2dK2laKAAcaFiK5uzawGaRf
6wIcuHl8SkXFh16wpE0f0yzAlqSwWuPBW3fmUCqHhAUCdm08SmW+MKyHclrSjzbR
2TaWZXq605LmPFSFfsOdgg4CU/ST5v9V9WeTMp151ASaDLO/WCNrtHIP6eW2587O
f9cdZL7s773+w4AiktfSnnCSzEtngId4JhzTmN3lydWeBtTwITRL1+DlGLT2n/qT
LBvzwTMsUvgOhJBCE17pNsxulSMrv+B+Mm5vPejqMz5bIhNgD3N7gHXgor4qRs+E
1dzYeaiTDadAnHivS5enZmSa9OyE3XHNEKZTDgwxf5kkO4Xdj6x4R1N8teaR1Mt6
oLAf9hmMC+BOHE2FKNpA1YQeWkH4hbvf2tIFq75sip4jWUVYS8yq0eDHHG80D2Qp
pRI1qPatLeWkVChRuIgS/62DD6n/Vmh6o6SJnyZZtjHjWYJrOz/AhEuRV6WjQsxf
nf2pMRe7OFIi8npiE7lbF2yDYSsjRY03XDaWUzmSjMdQ37Pf5AhWi+42y8p2NnlG
zQp49DQJK2gYFyXzlUet7oXY4Lo6Xj0+wdAWuisDeEhatuT1ZEZNCGiQFzCq2CZ0
ZVvgP0Axygz/KYr8mslX
=DDLt
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] interface-name records vs localise-queries

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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


Have fun.


Cheers,

Simon.



On 01/02/17 13:41, Kevin Darbyshire-Bryant wrote:
> 
> 
> On 17/01/17 04:05, Eric Luehrsen wrote:
>> Hi Kevin,
>> 
>> Reading the man page, I would expect the primary address is
>> returned (localized) and  it acts just like any /etc/hosts entry.
>> This would imply that this is a bug or oversight.
>> 
>> quote: -interface-name=,[/4|/6] Return a DNS
>> record associating the name with the __ primary address __ on the
>> given interface. This flag specifies an A or  record for the
>> given name in the __ same way as an /etc/hosts line __, except
>> that the address is not constant, but taken from the given 
>> interface
>> 
>> 
>> (I don't use router DNS that specifically, so I failed to test
>> this detail before submitting to LEDE. )
>> 
>> Eric
> 
> Hi Eric,
> 
> Sorry for the the late reply - I've been distracted by many other 
> things.  Your recent lede/dnsmasq.init changes are absolutely
> wonderful and really useful.  If it weren't for this 'featurette'
> of localised queries not working, it would be perfect.
> 
> I wonder if Simon could be persuaded to look into this ready for
> 2.77?
> 
> :-)
> 
> Kevin
> 
> 
>> 
>>> Kevin Darbyshire-Bryant Wed, 11 Jan 2017 10:24:34 -0800 Hello
>>> All, Recently LEDE changed the way it allocates names to
>>> interfaces, now using '-interface-name' rather than putting
>>> names in /etc/hosts or similar. Unfortunately this new method
>>> appears incompatible with 'localise-queries' in that all
>>> interfaces/aliases are included in the reply to 'nslookup 
>>> hostname' and not in a 'preferred local interface' order. Is
>>> this an oversight/feature/bug? Cheers, Kevin
>> ___ 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYk2TiAAoJEBXN2mrhkTWierAQAJUTwrSa6uRmCWp2cNvxlxWO
lnkehQhnqq43TVH5kg4waao71nigM7K77PnBIDuujs1gpYE1cgXDNIHbIjaBe28L
zEYdhp/AKoEb9RAFdBApQFjPz6Io5PEKivtLDTDf/EKpN878GTy0LfumQGL7yvc/
TrvUX6XFGZVaqI3sih9p5tHchg64jrs9fsSv/wmUZCSeJmAUgM22Ovb38rQkJrmW
wWKsMfNFSxPuDmvkCzrKp6F+G+sXXoPpwEC41BhLRn60mrY5O6G0ytp8qVsCC6Ax
5a/7G/8hBX3bGvDHyHx3yRdXNqdDuyqSvjP1BIeunr+emwVoReNkrEowfY3EE9+b
7/dQtfbwJx3auL1oRW5IhwqcWFgQ2GtupZapkpJ9hN4uE5KtI0FGx2JWuh1GRWrR
OQ8mmvyWr00BVJI3TjPbmmkTwPjNGKydSwWNHXwkdUh1K9ZALyN6ezvxuJx4Ptit
2ZMtBqc6+PqHO3FL25fTjMETza4ubP/OwU+9LXdnlNc1/Lk0UDTEN5YwU/yx2bDc
RV2Hwu2d826EvatiW6SmTikLt2vL9ow+4yFdUJZPWg3X8A9pJe/aroymW09NUP1w
jlE3fwmdVPNoex3TgNwpwRUfJF/qKkZ68ETo+hT8+sRyLIJ04fs8VUvYOxGcPgK5
HFI7upWmBSHUdZTlpoOe
=lPRg
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] why does dnsmasq reject lease request?

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Some possible confusion here between DNS servers and DHCP servers. If
the two _DNS_ servers the OP refers to are both also DHCP servers,
then Jim's advice is good. If the OP has two DNS servers, one of which
is dnsmasq which is also acting as the DHCP server (which is how I
read it) then the problem looks like a broken DHCP client, which is
attempting to restart using a DHCP lease it has on some other DHCP
server.

On receipt of the DHCPNAK reply, it should react by doing a
DHCPDISCOVER and find a DHCP server and lease from scratch, rather
then continually retrying. A work around may be to remove whatever
state the broken DHCP client has (/var/lib/dhcp or similar, forget
leases using the GUI in Windows/Apple, factory reset for IoT-type stuff.

Cheers,

Simon.


On 02/02/17 14:00, Jim Alles wrote:
> Hello Will,
> 
> You would need a wireshark capture to see the issue here, the log
> does not tell the whole story.
> 
> It would appear that both DHCP servers are answering the clients's
> requests.
> 
> We don't know your network configuration, or how the ISP's 'router'
> is set up to be able to say for sure. But you should limit the IP
> range of each to avoid the other.
> 
> What I do, is use dnsmasq in a (mostly) open source GUI wrapper
> called NGFW by Untangle. It can replace the
> NAT/router/firewall/DNS/DHCP services of the ISP device, if you get
> it (ISP device) into bridged mode. You would have to provide for a
> Wi-Fi Access Point separately.
> 
> What is your ISP?
> 
> Nice .conf, for home, BTW.
> 
> Jim A.
> 
> On Wed, Feb 1, 2017 at 5:39 PM, Will Parsons
> mailto:varro@nodomain.invalid>> wrote:
> 
> I have two DNS servers on a single network - one on the router 
> provided by the ISP and one running dnsmasq on one of my own
> machines (which I'd like to be preferred if it's available).
> 
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYk116AAoJEBXN2mrhkTWinLMP/i3XiOdDm8qvJbXup13/Npqe
SkzCIxkoXxw7yEg0OmGjWce7v2CWeZiIdz9MKcPpobtMGHkDnRJRTlMfhHwpR9+D
LbbxbYjexZGcRfSLCGw/g47/K1CVMOARYWd8QOEH36lC0nIwkSmh1fwTRVP/Gh38
SojmrW7LEbrYJZzJdQuvXofFkg+bk9U+ECeGjiW8Y1Sv8qEwagSFa3D/rjuAPtbO
UG50CgNaUJ9qQNwKUYeT5dQDDBU7+VlTEsar+slmJ/ywea1JoxVABMu/l2VCquYe
9eRh/8RIe/1K9XpH+g4s4ElMUsnYtr2HpuoEkJZt43UjLhcviLAq9A28uZtTNWZI
PvRdI82u9qw5hCJ+4CUAyXNMZZNy2cOmh1H8Jut0LXYP++4+9KZ9tVza/u7gQ5If
83LlwUQnUvyc6HyVINSVkYslCe24wvEoOpkmNMb1iV5Sg8p/96LnbDEM0Y2rV7tZ
vvsal9NCs74I31cF45aLA32Rh3D6UADQzqHjbHIbijjP67rn2qG6jz+WaG6KHnm7
C3I1arIZgP9t1YF5haj8ljlZVAzUt1PTzN5RKZnQfr3hFGrGLVU3KERKwsVw+rsZ
HZ/9VAY12GKMxohGxLfD+yKzS8OuKmwz2t+AoVAY+crh11C2ZH4jouYIN3vs0N3k
EqPshF3kxpz/tgq42rhA
=wQYl
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] interface-name records vs localise-queries

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I looked at this, and the man page LIES. --interface-name returns all
the addresses associated with an interface.

Question: is openWRT associating the same name with more than one
interface (which would be the only way that localise-queries would
make sense, if you believed the man page.)

ie

interface-name=myrouter,eth0
interface-name=myrouter,eth1
localise-queries

and expecting to get the address of eth0 or eth1, depending on where
the query was sent to.

If it is, then it's probably working by accident, but I have to make
sure that doesn't break;

Cheers,

Simon.




On 01/02/17 13:41, Kevin Darbyshire-Bryant wrote:
> 
> 
> On 17/01/17 04:05, Eric Luehrsen wrote:
>> Hi Kevin,
>> 
>> Reading the man page, I would expect the primary address is
>> returned (localized) and  it acts just like any /etc/hosts entry.
>> This would imply that this is a bug or oversight.
>> 
>> quote: -interface-name=,[/4|/6] Return a DNS
>> record associating the name with the __ primary address __ on the
>> given interface. This flag specifies an A or  record for the
>> given name in the __ same way as an /etc/hosts line __, except
>> that the address is not constant, but taken from the given 
>> interface
>> 
>> 
>> (I don't use router DNS that specifically, so I failed to test
>> this detail before submitting to LEDE. )
>> 
>> Eric
> 
> Hi Eric,
> 
> Sorry for the the late reply - I've been distracted by many other 
> things.  Your recent lede/dnsmasq.init changes are absolutely
> wonderful and really useful.  If it weren't for this 'featurette'
> of localised queries not working, it would be perfect.
> 
> I wonder if Simon could be persuaded to look into this ready for
> 2.77?
> 
> :-)
> 
> Kevin
> 
> 
>> 
>>> Kevin Darbyshire-Bryant Wed, 11 Jan 2017 10:24:34 -0800 Hello
>>> All, Recently LEDE changed the way it allocates names to
>>> interfaces, now using '-interface-name' rather than putting
>>> names in /etc/hosts or similar. Unfortunately this new method
>>> appears incompatible with 'localise-queries' in that all
>>> interfaces/aliases are included in the reply to 'nslookup 
>>> hostname' and not in a 'preferred local interface' order. Is
>>> this an oversight/feature/bug? Cheers, Kevin
>> ___ 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYk1XfAAoJEBXN2mrhkTWiXhUQAJfYoPb9i/egmOf1d417TdOF
hX0khXuboOHObp+6FK7QREduQ7yCG1QbdxSKNJPWT6q3GBotYSwmfSd9F/EETyBs
/OGRhvBZtk2kFyf79tJvLBNtJAOcmm8ml9K8mOl/NYtBP6yYkwwjcYXUEp9dLKUB
xuS+MPvI4Z1+DqmrDkmayevfgwRLuz1S+0SmMBMo+K6yZ2853HwKGBh7+U5+ZBB8
DfwFsriisJbSc2EG5RJBGuXH7aclB3+5+8UAMdgmT68/M2Eb9icnjqpJMLF90nm7
h3sEz4YtBDVeVm1ki4cpbtzFCOouZfEpe/jekHSRtwycH+dm51W/T2kTPCjg2shk
aNfLxQURZcVrx0ZhbZkyk0zFmbchHWuhWY9KDn93jcwyU4ESkf44t2A0hhFAn6Xp
bu37/7ZdYmBekTaO7PohRtFcCmTe9oRXhfYDTzgbEG+cbWb1ITf4rvJPaj4x9ZVN
vkVCWd54UF7CV1t/tgfBtEldNDkwkxxm6a0kxdi7q1B5mis6fig79Aj9Yu+GrXdI
j3Jmb/TTQzjtFGqiK7zjOXBinZa+j+ih1nzrn4qupz20pXf8RlwCf7fV4M5qi5E2
ogx4VkiIDgLvLouGRZ8/o8R78JK1jppuTwazRUywbl4HkZJ5ZbTRv6mQ5ZVMuw2D
PjHoM4/xBls7wsU6wDrg
=vMD4
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Spelling fixes for dnsmasq

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Wow, what a lot of typos!

A couple of observations from a random sampling:

1) I don't want the code changes - if I missed vowels out of variable
names, I want them to stay missed out :)

2) I found two changes to proper names, Falempin and Murname. How did
you determine that those were (in)correct, and are there any more I
missed?

3) dnmasq is wrong.


Modulo that, and Neil's quible, I'd love to take this as a diff.


Cheers,

Simon.


On 02/02/17 06:43, Josh Soref wrote:
> Hi... I'm wondering if you'd be interested in any of these
> commits: https://github.com/jsoref/dnsmasq/commits/spelling 
> https://github.com/jsoref/dnsmasq/compare/master...jsoref:spelling?exp
and=1
>
>  I could send a single diff for the changes, but I find that it's 
> usually best to let people think about changes individually, and
> it's much easier for me to drop things when they're isolated
> commits than after I've squashed them together.
> 
> 144 misspelled word families; 47 files changed; 214 lines changed;
> 
> There are only a handful of changes to actual code: dnsservers 
> errsave ra_start_unsolicited
> 
> I understand that some pieces in the git repo are contrib/
> including a tarball with misspellings (contrib/webmin/dnsmasq.wbm).
> I can easily drop more things, but I'd need guidance.
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYkzSHAAoJEBXN2mrhkTWi/Y4QAJjwOOy9Zu9wgM3Mw177cRmB
ZkhLNdrY1cKC9i4YVPTqRP4Pb/bepMH/FehZkZgTXp78A8sA6Y7u/sZ87Hkg/HxD
L18rpLy3Fg8RzdTI+kensMKjMJkBOBDbpK3khbebSVRGBh4448plHHv15jluVrTb
rp44WRtFI3cGp8Eqg3wkpCwvxCLTXO9C4oJETgE6bDJb0cMLtGSmnigvc3fFh04+
IlFozcC1u48Bm27i7n91gQTQOnkg467kB58/nzNFQcrWeuTxCMcMSjIsCKywU7l1
egpGaTkNd4UR9wJ4sV5SqiPjSvfBsNABDHstIPAhdHXcTYxusXnw4kHgDWha//RU
lLJkSBADEI5jTGyVuO63amfUqfdI4GLNDq8IMFTMKJM7NOUv+SDlXpoJmIn9iCWM
C+QB53mQ+lU4/N8QVPUdGTgTQ9d12qiPpjSATzREx7ZvcNqk219KibjtwNXiF39J
dlV5SCy8Arle2IA1R/Yt2hO4DMUoHyFOmYvkHQvN9fDyui68/Hyw8MjthVZIL6qf
F8lO1nKJj0eDV8SBTRRScpoIiBQv3a69cPdf1m6rj2p0PSTDVU4Xc+IM+Rwisdll
AJVTP/zSNzOI2B5TmxHj098mABkt9IY8ilTCA6Ys3QJU41jgE2SQ3V4RTbYULILa
2Z0Fta0eDoss0yQ1Vg3+
=Dmhf
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] dnsmasq drops CNAME cache entries when CNAMEs collide

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Answered here:


http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011068.h
tml


Cheers,

Simon.

On 02/02/17 11:23, Aaron Jacobs wrote:
> Hi all,
> 
> I've found what seems to me an odd behavior in dnsmasq related to
> CNAME caching, and am wondering if it's a bug, or just a subtlety
> of the DNS standard that I don't understand.
> 
> I'm using dnsmasq 2.76, invoking in a way that should enable
> caching:
> 
> % ./src/dnsmasq -v Dnsmasq version 2.76
> 
> % sudo ./src/dnsmasq --no-resolv --server= --keep-in-foreground 
> --no-hosts --bind-interfaces --listen-address=127.0.2.1 
> --cache-size=400 -dq
> 
> Normally it caches fine. The first query for a domain takes awhile,
> and the second takes no time at all:
> 
> % dig @127.0.2.1 photos.yahoo.com ; sudo killall -USR1 dnsmasq 
> [...] ;; ANSWER SECTION: photos.yahoo.com.   299 IN
> CNAME   rc.yahoo.com. rc.yahoo.com.   299 IN  CNAME
> src.g03.yahoodns.net. src.g03.yahoodns.net.   155 IN  A
> 98.137.236.150
> 
> ;; Query time: 144 msec ;; SERVER: 127.0.2.1#53(127.0.2.1)
> 
> % dig @127.0.2.1 photos.yahoo.com ; sudo killall -USR1 dnsmasq 
> [...] ;; ANSWER SECTION: photos.yahoo.com.   289 IN
> CNAME   rc.yahoo.com. rc.yahoo.com.   289 IN  CNAME
> src.g03.yahoodns.net. src.g03.yahoodns.net.   145 IN  A
> 98.137.236.150
> 
> ;; Query time: 0 msec ;; SERVER: 127.0.2.1#53(127.0.2.1)
> 
> Note that photos.yahoo.com has a CNAME of rc.yahoo.com, which in
> turn has a CNAME of src.g03.yahoodns.net. When I query another
> domain with that CNAME, it appears to kill the cache entries for
> those CNAMES; the next query for photos.yahoo.com is slow again,
> clearly not hitting cache:
> 
> % dig @127.0.2.1 www.flicker.com ; sudo killall -USR1 dnsmasq 
> [...] ;; ANSWER SECTION: www.flicker.com.1799IN
> CNAME   rc.yahoo.com. rc.yahoo.com.   299 IN  CNAME
> src.g03.yahoodns.net. src.g03.yahoodns.net.   264 IN  A
> 124.108.105.150
> 
> ;; Query time: 143 msec ;; SERVER: 127.0.2.1#53(127.0.2.1)
> 
> % dig @127.0.2.1 photos.yahoo.com ; sudo killall -USR1 dnsmasq 
> [...] ;; ANSWER SECTION: photos.yahoo.com.   299 IN
> CNAME   rc.yahoo.com. rc.yahoo.com.   299 IN  CNAME
> src.g03.yahoodns.net. src.g03.yahoodns.net.   299 IN  A
> 124.108.105.150
> 
> ;; Query time: 147 msec ;; SERVER: 127.0.2.1#53(127.0.2.1)
> 
> Here are the cache dumps after each query above:
> 
> === dnsmasq: Host Address 
> Flags  Expires dnsmasq: photos.yahoo.com
> rc.yahoo.com CF Thu Feb  2 22:13:43 2017 dnsmasq:
> src.g03.yahoodns.net   98.137.236.150 4F Thu Feb  2
> 22:11:19 2017 dnsmasq: rc.yahoo.com
> src.g03.yahoodns.net CF Thu Feb  2 22:13:43 2017 === 
> dnsmasq: Host Address Flags
> Expires dnsmasq: photos.yahoo.com   rc.yahoo.com CF
> Thu Feb  2 22:13:43 2017 dnsmasq: src.g03.yahoodns.net
> 98.137.236.150 4F Thu Feb  2 22:11:19 2017 dnsmasq:
> rc.yahoo.com   src.g03.yahoodns.net CF Thu
> Feb  2 22:13:43 2017 === dnsmasq: Host
> Address Flags  Expires dnsmasq: photos.yahoo.com CF Thu
> Feb  2 22:13:43 2017 dnsmasq: src.g03.yahoodns.net
> 124.108.105.150 4F Thu Feb  2 22:13:22 2017 dnsmasq:
> rc.yahoo.com   src.g03.yahoodns.net CF Thu
> Feb  2 22:13:57 2017 dnsmasq: www.flicker.com
> rc.yahoo.com CF Thu Feb  2 22:38:57 2017 === dnsmasq:
> Host Address Flags
> Expires dnsmasq: photos.yahoo.com   rc.yahoo.com CF
> Thu Feb  2 22:14:00 2017 dnsmasq: src.g03.yahoodns.net
> 124.108.105.150 4F Thu Feb  2 22:14:00 2017 dnsmasq:
> rc.yahoo.com   src.g03.yahoodns.net CF Thu
> Feb  2 22:14:00 2017 dnsmasq: www.flicker.com CF Thu Feb  2
> 22:38:57 2017
> 
> It appears that when dnsmasq discovers the CNAME for
> www.flicker.come, it knocks the CNAME for photos.yahoo.com out of
> the cache (and vice versa). Is this intended behavior?
> 
> Thanks, Aaron
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYkzVeAAoJEBXN2mrhkTWirzgP/RtsUl84PxNrQImJaD3VRUgR
HHwdHEDrpb7wNUgMNDzoBABqjAyn0eJH/amzoz7/5ZBPegioTJ4jiOpKenQgCZA5
XVmgyX7EoFf/sOB6H1vjxuSvt25TZbTNE6WaL9LhuE/RD+xuEX31M0HGvlUHC1J3
zW5zT1tA9O2A3n6ZtaVsuS7YDYLqXvlblAIJzEb+emFq8dm1kz4it6JniWvRcL67
nIrkwBG7K/uFvevq0VVVI74YpFJIsi/epUAK3uY5xgPXukRW7d7dV8dmGg03L8Tc
TmE/rZEQnYACzUl+VlA/TSB8dPlJUJmbkizApfI6kEON/HXtB9rNJPSyjp5zqdjR
NRxdspoi+bB9KyMI4cngnfEMMxEieViaarv62tbIlX+2BN0QD7y4eB3ukiM3S1W5
/XRb/fEKbDM+ym8bAcc6EdBN57w7l3I+K/urxmi7bOegLdipUh3vaiGhGSX64JGA
4U

Re: [Dnsmasq-discuss] IDN (internationalized domain name) support

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It's included in the Debian, (and therefore Ubuntu) packaging.

Of course the only difference it makes is to the interpretation of
domain names in /etc/hosts and friends and config files. - IDNs get
cached and forwarded by dnsmasq fine without the support being included.

OK, it also affects logging, I think. göögle.com  appears in the logs
göögle.com and not as xn--ggle-5qaa.com


Cheers,

Simon.



On 28/01/17 21:09, Dave Taht wrote:
> I am curious as to the deployment status of IDN in the field?
> 
> and to how often others are building it into their default distro
> of dnsmasq, and any issues that may exist (other than improving the
> ease of domain name phishing)
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYkMHnAAoJEBXN2mrhkTWi2vUP/iX/Z/tnB/Skw6yGWxlIu28W
bcajXnUjCfph8xixJXGKDJNWzLSxPgPpEGhJfzZQvtDOrC7rr4MAKxBSuhpfciVV
PWQm9t6JAwwIfaW9u4gLw9dTifiHJovbgNsR1KMwcqNARy3S6WSTjERpmm9h2Tp2
pI4n1Bg+IAEG/f5b9QxjPTFlbGrZbiVpsp+hVUftUGykQjugtP6lo4UpeLXjPrjJ
a2ZVi4Qpz/G9ujRkStq9PcLy4NOjc8ZHc85QBmUowCiGv5FJYJFUKRnEU2ChmFnY
tztFXgDjXHMaGV/Am44w+HpCTWHDyENEd2iKFhm+hSfnD89P5N02mRUxstQJdKrE
yEBv22/U2mAW6o4XJWWVIB31h4gMNAFQPiAlSlLVquFx40kcWRswoqZKrCCIvYsy
tJm8FjawA/Yt9kIdM71ymJ6NkwYPr0rfgZE95p/5L5q+nidOVVbDN/eGNyY4yylM
tcsKo22D+GyRFLmc/NqnuCbq9PaXbHY88s5lJQf1mSKdYKckMYmPgVXnq45M2AaO
auUpTEdhsXsfzOULzOQmXwv2dSfo2IHfRZRFJeSpMf7JwAMjgxiK3tEidPL75LUt
vM6xkVNBCD8LlFj5BK94EhSw+3QDCZmQUBU4FImF8aOCxsdq+Vk+/D4nGJW1SgGC
9aMz4z1pFq3IM44GP+fN
=X8Ni
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] About UEFI PXE booting in proxy mode

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There's no DHCP traffic in that capture. It appears to all be ssh.

Wrong interface?


Cheers,

Simon.


On 24/01/17 08:50, Steven Shiau wrote:
> Hi Simon,
> 
> Attached please find the dump file of the command "tcpdump -s 0 -w 
> capturefile". Let me know if you need more info. Thank you very
> much.
> 
> Steven
> 
> 
> On 1/24/2017 AM 05:25, Simon Kelley wrote: Thanks for the reply.
> Please could you repeat the tcpdump using the command
> 
> tcpdump -s 0 -w capturefile
> 
> and send me the resulting file? That has far more information than 
> tcpdump prints.
> 
> 
> Cheers,
> 
> Simon.
> 
> On 20/01/17 08:39, Steven Shiau wrote:
>>>> Hi Simon,
>>>> 
>>>> Thanks for your reply. I am answering you in the following.
>>>> 
>>>> On 2017/01/20 06:47, Simon Kelley wrote:
>>>>> Your example 3 - I'm confused why that shouldn't work - the
>>>>> PXE client seems to be making further requests which are
>>>>> bring ignored. Would it be possible for you to get a packet
>>>>> dump of that exchange using tcpdump?
>>>> $ sudo tcpdump -ni ens38 'udp port 67 and udp port 68'
>>>> tcpdump: verbose output suppressed, use -v or -vv for full
>>>> protocol decode listening on ens38, link-type EN10MB
>>>> (Ethernet), capture size 262144 bytes 16:18:33.208355 IP
>>>> 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
>>>> 00:0c:29:1d:9a:d1, length 347 16:18:36.205647 IP
>>>> 192.168.22.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply,
>>>> length 341 16:18:36.385548 IP 0.0.0.0.68 > 
>>>> 255.255.255.255.67: BOOTP/DHCP, Request from
>>>> 00:0c:29:1d:9a:d1, length 359 16:18:36.386212 IP
>>>> 192.168.22.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply,
>>>> length 341 ^C 4 packets captured 4 packets received by filter
>>>> 0 packets dropped by kernel
>>>> 
>>>>> Example 4 looks quite hopeful - the client is
>>>>> succerssfully downloading the bootx64.efi file (ignore the
>>>>> error before, that's just testing for the existance of the
>>>>> file.
>>>>> 
>>>>> Can you see what's displayed on the client system at this
>>>>> point?
>>>> It's blank screen due to the background_image for grub is
>>>> not downloaded,  and in the end the grub shows no grub.cfg
>>>> error, as attached. That format is from the grub prefix we
>>>> added by: === set 
>>>> prefix=(tftp)/grub-efi.cfg echo "Grub CPU and platform:
>>>> \$grub_cpu, \$grub_platform" echo 'Network status: '
>>>> net_ls_cards net_ls_addr net_ls_routes
>>>> 
>>>> tr --set pretty_mac x: x- \$net_default_mac
>>>> 
>>>> echo "Loading config file
>>>> \$prefix/grub.cfg-01-\$pretty_mac..." configfile
>>>> \$prefix/grub.cfg-01-\$pretty_mac
>>>> 
>>>> echo "Loading config file
>>>> \$prefix/grub.cfg-\$net_default_ip..." configfile
>>>> \$prefix/grub.cfg-\$net_default_ip
>>>> 
>>>> echo "Loading config file: \$prefix/grub.cfg" configfile 
>>>> \$prefix/grub.cfg
>>>> 
>>>> echo "Could not find config file
>>>> \$prefix/grub.cfg-\$pretty_mac, 
>>>> \$prefix/grub.cfg-\$net_default_ip or \$prefix/grub.cfg!"
>>>> sleep 15 === This is
>>>> exactly the same problem as mentioned here: 
>>>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q4/010
931
>
>>>> 
.html
>>>> 
> i.e., only grub efi is downloaded, while the rest of required files
> are
>>>> not downloaded. As I mentioned for comparison, for non-proxy
>>>> mode with same configuration, it works well.
>>>> 
>>>> Thanks again.
>>>> 
>>>> Steven
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> Dnsmasq-discuss mailing list
>>>> Dnsmasq-discuss@lists.thekelleys.org.uk 
>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>>
>>
>>
>>>> 
___
>> Dnsmasq-discuss mailing list 
&g

Re: [Dnsmasq-discuss] Bluetooth networking issue

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Make sure you're not getting confused between "connection refused" and
a DNS reply with a REFUSED return code. The former means there's
nothing listening on port 53 at the address you're sending the query
to, which is possible if the bluetooth interface is new and network
manager hasn't prodded dnsmasq suitably. The later means the the query
is getting to dnsmasq and it's replying, which as you say, it only
does when it has no upstream servers. The log you posted doesn't seem
to show that dnsmasq has no servers, or that it's getting queries from
any address which could plausibly be a bluetooth device, so the
connection refused option looks quite likely, but it's important to
work which it is.



Cheers,

Simon.


On 26/01/17 17:26, Aaron Brice wrote:
> So, to summarize: after disconnecting and reconnecting the network 
> device, DNS queries are returning REFUSED, with no error messages 
> showing in the logs.  Is there any option to increase verbosity?  I
> read somewhere that the only reason dnsmasq returns REFUSED is if
> there are no nameservers or one of the nameservers returns REFUSED
> status. However there are several "using nameserver" entries in the
> logs, and no traffic occurs to those nameservers.
> 
> Thanks, Aaron
> 
> On 01/23/2017 02:47 PM, Aaron Brice wrote:
>> I am testing a bluetooth networking (bnep0) device on an Ubuntu
>> 16.04 laptop.  Everything works fine if I comment out dns=dnsmasq
>> from the NetworkManager.conf.  With dnsmasq on, everything works
>> fine the first time I connect my bluetooth network device.  When
>> I disconnect it and reconnect it, DNS lookups fail immediately
>> with a REFUSED status. When I restart the NetworkManager service
>> everything works again.
>> 
>> I turned on log-queries, and it shows the query is received, but
>> no response is shown in the logs and also no error messages.  The
>> logs show that on the reconnect the DHCP succeeded, and dnsmasq
>> received the upstream nameservers from the DHCP response, but
>> tcpdump does not show any DNS traffic to those nameservers when I
>> use dig.  Is there a verbosity setting that might show some more
>> information on why the DNS queries are being refused?
>> 
>> Logs:
>> 
>> Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: setting upstream 
>> servers from DBus Jan 18 16:56:02 datasoft-travel dnsmasq[7973]:
>> using nameserver 192.168.10.2#53(via bnep0) Jan 18 16:56:02
>> datasoft-travel dnsmasq[7973]: using nameserver 
>> 68.105.29.16#53(via bnep0) Jan 18 16:56:02 datasoft-travel
>> dnsmasq[7973]: using nameserver 68.105.28.16#53(via bnep0) Jan 18
>> 16:56:02 datasoft-travel dnsmasq[7973]: query[A] daisy.ubuntu.com
>> from 127.0.0.1 Jan 18 16:56:02 datasoft-travel whoopsie[883]:
>> [16:56:02] Cannot reach: https://daisy.ubuntu.com Jan 18 16:56:02
>> datasoft-travel dnsmasq[7973]: query[SOA] local from 127.0.0.1 
>> Jan 18 16:56:02 datasoft-travel NetworkManager[7926]:  
>> [1484783762.2180] device (5C:31:3E:EC:71:B3): Activation:
>> successful, device activated. Jan 18 16:56:02 datasoft-travel
>> nm-dispatcher: req:2 'up' [bnep0]: new request (1 scripts) Jan 18
>> 16:56:02 datasoft-travel nm-dispatcher: req:2 'up' [bnep0]: start
>> running ordered scripts... Jan 18 16:56:02 datasoft-travel
>> whoopsie[883]: [16:56:02] The default IPv4 route is:
>> /org/freedesktop/NetworkManager/ActiveConnection/2 Jan 18
>> 16:56:02 datasoft-travel deja-dup-monito[3334]: Source ID 948 was
>> not found when attempting to remove it Jan 18 16:56:02
>> datasoft-travel whoopsie[883]: [16:56:02] Network connection may
>> be a paid data plan: /org/freedesktop/NetworkManager/Devices/3 
>> Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: query[A] 
>> daisy.ubuntu.com from 127.0.0.1 Jan 18 16:56:02 datasoft-travel
>> whoopsie[883]: [16:56:02] Cannot reach: https://daisy.ubuntu.com 
>> Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: query[SOA] local
>> from 127.0.0.1 Jan 18 16:56:02 datasoft-travel systemd[1]:
>> Reloading. Jan 18 16:56:02 datasoft-travel systemd[1]:
>> snapd.refresh.timer: Adding 4h 43min 19.514615s random time. Jan
>> 18 16:56:02 datasoft-travel systemd[1]: apt-daily.timer: Adding
>> 2h 3min 35.943181s random time. Jan 18 16:56:02 datasoft-travel
>> dnsmasq[7973]: query[SOA] local from 127.0.0.1 Jan 18 16:56:02
>> datasoft-travel systemd[1]: Reloading. Jan 18 16:56:02
>> datasoft-travel systemd[1]: snapd.refresh.timer: Adding 1h 9min
>> 9.603579s random time. Jan 18 16:56:02 datasoft-travel
>> systemd[1]: apt-daily.timer: Adding 6h 19min 48.788489s random
>> time. Jan 18 16:56:03 datasoft-travel dnsmasq[7973]: query[A] 
>> fsodqcsvqrxnlyy.corp.datasoft.com from 127.0.0.1 Jan 18 16:56:03
>> datasoft-travel dnsmasq[7973]: query[A] xasqjyv.corp.datasoft.com
>> from 127.0.0.1 Jan 18 16:56:03 datasoft-travel dnsmasq[7973]:
>> query[A] ftmkaipfpi.corp.datasoft.com from 127.0.0.1 Jan 18
>> 16:56:03 datasoft-travel dnsmasq[7973]: query[A] daisy.ubuntu.com
>> from 127.0.0.1 Jan

Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OK, that's a bit difficult to correlate the client and upstream, but I
can see in the responses coming back from upstream that the order of
the RRs in the Auth section of the "no-such name" replies is

NSEC
RRSIG (for NSEC)
SOA
RRSIG (for SOA)

That's different than for the google public DNS which returns

SOA
NSEC
RRSIG
RRSIG

Both are valid, but the first exercises code-paths the second doesn't,
since the SOA RR has to be moved when the NSEC and its RRSIG are
deleted from the packet.

The address of the upstream server in the captures is an RFC1918
address. Is there a comcast server at  a public address that I can
point to and get the same answers? That should allow me to reproduce
the bug here.

I just tried the first 5 or 6 servers in google's answer to the query
"public dns" and they all reply in the SOA-first order. Need to find a
public DNS server that replies in the NSEC-first order.

Cheers,

Simon.


On 18/01/17 20:49, Dave Taht wrote:
> The offputting part of your outline of what to check for was "some 
> hairy pointer code". :) I'm in the middle of some crash bugs 
> elsewhere, and I didn't realize how fast I could get you data
> without thinking about the "hairy" parts.
> 
> 
> dnssec and dnssec-check-unsigned are enabled, and I'm using
> cachesize  (what's the limit nowadays?)
> 
> I put packet captures of the external interface on the router
> (comcast upstream) and captures taken at the client, a log, and
> conf file, here:
> 
> http://www.taht.net/~d/dnssecbug/
> 
> Basically hammering on nslookup for the two internal and internal 
> captures there.
> 
> Hammering on "dig" later, I was unable to trigger it on A, or  
> requests. Was able to easily trigger it on a MX request.
> 
> flent-freemont does not exist, btw. Flent-fremont, does. It will
> go boom on both.
> 
> 
> 
> root@dancer:~/dnssecbug# dig flent-freemont.bufferbloat.net MX ;;
> Got bad packet: bad compression pointer 123 bytes a5 c9 81 a0 00 01
> 00 00 00 01 00 01 0e 66 6c 65  .fle 6e 74 2d 66
> 72 65 65 6d 6f 6e 74 0b 62 75 66 66  nt-freemont.buff 65 72
> 62 6c 6f 61 74 03 6e 65 74 00 00 0f 00 01
> erbloat.net. c0 1b 00 06 00 01 00 00 0e 10 00 34 06 61 72 6e
> ...4.arn 6f 6c 64 02 6e 73 0a 63 6c 6f 75 64 66 6c 61 72
> old.ns.cloudflar 65 03 63 6f 6d 00 03 64 6e 73 c0 eb 78 9d d7 47
> e.com..dns..x..G 00 00 27 10 00 00 09 60 00 09 3a 80 00 00 0e 10
> ..'`..:. 00 00 29 02 00 00 00 00 00 00 00
> ..) root@dancer:~/dnssecbug# dig
> flent-freemont.bufferbloat.net MX
> 
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> flent-freemont.bufferbloat.net MX 
> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode:
> QUERY, status: NOERROR, id: 34631 ;; flags: qr rd ra ad; QUERY: 1,
> ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;;
> QUESTION SECTION: ;flent-freemont.bufferbloat.net.INMX
> 
> ;; AUTHORITY SECTION: bufferbloat.net.3600INSOA
> arnold.ns.cloudflare.com. dns.cloudflare.com. 2023610183 1 2400
> 604800 3600
> 
> ;; Query time: 72 msec ;; SERVER: 172.26.16.1#53(172.26.16.1) ;;
> WHEN: Wed Jan 18 12:42:02 PST 2017 ;; MSG SIZE  rcvd: 123
> 
> 
> 
> On Wed, Jan 18, 2017 at 12:01 PM, Dave Taht 
> wrote:
>> On Wed, Jan 18, 2017 at 11:48 AM, Simon Kelley
>>  wrote:
> I won't have access to a MIPS system 'till the weekend.
> 
> I assume you're using the git head code?
>>> 
>>> No. Lede-project head. package claims to be dnsmasq-2.76-6.
>>> libc is musl.
>>> 
>>> Box under test was an archer c7v2. Can go try a few other mips
>>> boxes like the wndr3800, but I've seen it there too. The arm
>>> box (that is working) is an linksys-1200ac. (overall it's
>>> looking like a fine release of lede)
>>> 
> Did you manage to see a dump of the upstream reply?
>>> 
>>> Not yet. I'll touch bases with you later in the week.
>>> 
> 
> 
> Simon.
> 
> 
> 
> On 18/01/17 07:31, Dave Taht wrote:
>>>>> so far I can only make it happen on mips. Doesn't happen on
>>>>> arm. Haven't tried harder yet.
>>>>> 
>> 
>> 
>> 
>> -- Dave Täht Let's go make home routers and wifi faster! With
>> better software! http://blog.cerowrt.org
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhn5+AAoJEBXN2mrhkTWiTS8QAIwA9Ue2ovYfA/orURvb0V

Re: [Dnsmasq-discuss] tftp: provide dbus signal for downloaded files

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Yes. Seems sensible. Can I make a request that the patch includes
updates to the documentation: at least dbus/DBus-interface, and also
the man page if that's appropriate.


Cheers,

Simon.


On 20/01/17 14:29, Yegor Yefremov wrote:
> I have an application, where a bootloader downloads files from my 
> dnsmasq tftp instance. I'd like to log these operations or to react
> on them.
> 
> Format would be like for DHCP lease:
> 
> STRING "192.168.1.115" STRING "01:23:45:67:89:ab" STRING
> "filename"
> 
> Would such functionality be accepted for integration?
> 
> Yegor
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhnV4AAoJEBXN2mrhkTWiqwYP/0EkQDbm46CQqkiOX4GQGAQC
dy/1UowiMB7koeEh/Ira3FvFq9puVq5R1tVxaVwIC4aCva/+v2nf7G55mhp7hXnW
agsIBaipwXEvbig9LGI0kg+L1hppgScVP6bVzHSOL0Dj1GrH063GUjPaMeVezWY3
pnaaANmfTSk+DSH99ZVBC56NxKCvWibnf8lD5h5dkq39Wz88vH1SUaBw0mkjJFnk
xL+q0lSUskE/NN/RpId9a647pQ+xjZ2Fj4qr+aiHXOJSODw7NAZMf/oz0fWStA+k
s29VRN99+hqtL1ytoXqNH+dOwWWJOJILmKlakrQtc8cNU2AhEr+Y6rIxv4rXSHKo
J8XX6N+k8VKQWPH9qMiRPwt4p/Mh1H3MJEnheMgrt6cb1ooWM8QRqAz4zjE4UXca
kWBPx0GwBpVoWVAeYdAg0N2Y+M1E6nFB3T2BB5C4PMeJKqJvbHUcQX6cJCwQsRIf
mE5yCVuRlM2nhAmtzYB/gVbpxG00c4jvPfDiQGGPwwoE2LYT3y6BAZIDK/fH+3IW
MMQ3sacSU0/fMct2UeSzEU3PMr/MWqx7zH1zdy/XZk1S2gC7bYqSwL9t3wY6fEdI
h8hflV3l48WtEXzYcnf4FjSUz3OT7unLRd74F/nGk8xTp6g2Ju22LVFkyaNASn5D
/LPt5q2wFdeABruMPgjq
=cq8Z
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] About UEFI PXE booting in proxy mode

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thanks for the reply. Please could you repeat the tcpdump using the
command

tcpdump -s 0 -w capturefile

and send me the resulting file? That has far more information than
tcpdump prints.


Cheers,

Simon.

On 20/01/17 08:39, Steven Shiau wrote:
> Hi Simon,
> 
> Thanks for your reply. I am answering you in the following.
> 
> On 2017/01/20 06:47, Simon Kelley wrote:
>> Your example 3 - I'm confused why that shouldn't work - the PXE
>> client seems to be making further requests which are bring
>> ignored. Would it be possible for you to get a packet dump of
>> that exchange using tcpdump?
> $ sudo tcpdump -ni ens38 'udp port 67 and udp port 68' tcpdump:
> verbose output suppressed, use -v or -vv for full protocol decode 
> listening on ens38, link-type EN10MB (Ethernet), capture size
> 262144 bytes 16:18:33.208355 IP 0.0.0.0.68 > 255.255.255.255.67:
> BOOTP/DHCP, Request from 00:0c:29:1d:9a:d1, length 347 
> 16:18:36.205647 IP 192.168.22.254.67 > 255.255.255.255.68:
> BOOTP/DHCP, Reply, length 341 16:18:36.385548 IP 0.0.0.0.68 >
> 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:1d:9a:d1,
> length 359 16:18:36.386212 IP 192.168.22.254.67 >
> 255.255.255.255.68: BOOTP/DHCP, Reply, length 341 ^C 4 packets
> captured 4 packets received by filter 0 packets dropped by kernel
> 
>> 
>> Example 4 looks quite hopeful - the client is succerssfully 
>> downloading the bootx64.efi file (ignore the error before, that's
>> just testing for the existance of the file.
>> 
>> Can you see what's displayed on the client system at this point?
> It's blank screen due to the background_image for grub is not 
> downloaded,  and in the end the grub shows no grub.cfg error, as 
> attached. That format is from the grub prefix we added by: 
> === set
> prefix=(tftp)/grub-efi.cfg echo "Grub CPU and platform: \$grub_cpu,
> \$grub_platform" echo 'Network status: ' net_ls_cards net_ls_addr 
> net_ls_routes
> 
> tr --set pretty_mac x: x- \$net_default_mac
> 
> echo "Loading config file \$prefix/grub.cfg-01-\$pretty_mac..." 
> configfile \$prefix/grub.cfg-01-\$pretty_mac
> 
> echo "Loading config file \$prefix/grub.cfg-\$net_default_ip..." 
> configfile \$prefix/grub.cfg-\$net_default_ip
> 
> echo "Loading config file: \$prefix/grub.cfg" configfile
> \$prefix/grub.cfg
> 
> echo "Could not find config file \$prefix/grub.cfg-\$pretty_mac, 
> \$prefix/grub.cfg-\$net_default_ip or \$prefix/grub.cfg!" sleep 15 
> === This is exactly the same
> problem as mentioned here: 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q4/010931
.html
>
> 
i.e., only grub efi is downloaded, while the rest of required files are
> not downloaded. As I mentioned for comparison, for non-proxy mode
> with same configuration, it works well.
> 
> Thanks again.
> 
> Steven
> 
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhnTjAAoJEBXN2mrhkTWiHX8QAJhjmt1VYRoJ3DuaA6f3s9o+
Tpoie2+4VgFHf3q/wQjq+miQ+da75+0sii9UAdjBtAAHDgLdyzPJSxCHU3neKYYF
dY8ww789lJlUAyvmvKm7Pnv3psMWhy22WLxeJGFXPIz+DjpH+tatZ507ZTQ7946o
nbTPdnfOO5ADF/Spuors6ioB+cmyZD9cPASSvMUQm7EwunBpAORB2S11ZRbeqSb/
84EdzTTtWomq7oP4NtSV98SDo0sTH2MYQtF1ht4INlutQs/zOP6P7NuzdFFJLcb8
Bieq1FYWxK6x4FcTqNdw9SJJon/jRjoxhF3Lvovkwb/00RuQuJRHqHpw+laY6yNA
MGS5LOIps/fIP42gxs7zftgqvfXVMfBLPUDRS3G+IwOZeteKvzNGwV0LrGFGKcZZ
iRDRAIhWH8RImb6gSpt1YXNxyR6Or1m0IuqR+jvYPOjtmXBjRYupZ89B0FKHR9jv
r2tJKSVq/uJa4ScW5R8ezGxaQB8iVFFj6CKDWeWEKxb4NxJUYrJ8RVb1IhAxZJUg
6EqXAZ/tvsIDRlveXk1nMqJ12pJlA68mnLzQ4Z5yarGTsoi6zlLecyhQkThp/LxP
E4lGqyuJEamggwyLd0WUYH7TMqXimCd9Nyv36rurfDZOVbT3G/JaS980SkTbsjZ2
c6JPXEqLshQyjdbht/1b
=msps
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Making dnsmasq make OFFER faster than virtualbox NAT DHCP

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 23/01/17 17:45, wkitt...@gmail.com wrote:
> On 01/23/2017 06:49 AM, Simon Kelley wrote:
>> Actually, it's permitted to have more than once DHCP server, but
>> the client is entitled to wait for some time to hear from them
>> all, and then pick whichever one it prefers,
> 
> that's interesting... i can't say that i've ever heard that
> before... maybe it has been corporate policy on all the networks
> i've dealt with over the years?
> 
> it is something that i may do more research on because i don't want
> to pass bad information as i have apparently just done... do you
> have any pointers to documentation on this aspect of DHCP servers?
> 
>> so trying to implement server priority by speed-of-reply is
>> doomed to failure.
> 
> yup! seems to be that way :)
> 
> thanks for the clarification!
> 

To be honest, I've never seen it used, except possibly in
high-availability fail-over scenarios, nevertheless it's in the spec:
see RFC-2131 para 4.4.1 Initialization and allocation of network address
.

  "The client collects DHCPOFFER messages over a period of time, selects
   one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
   messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
   from the previously used server) and extracts the server address from
   the 'server identifier' option in the DHCPOFFER message.  The time
   over which the client collects messages and the mechanism used to
   select one DHCPOFFER are implementation dependent."



Cheers,

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhkr+AAoJEBXN2mrhkTWiIuEP+wYazoN9/6AleAFaAnEljxPI
kAf9dklY+Xc2CG4gK5Y6+2k1Y5yhveLJ4OWN3DEzvGx9djjHvIdowvuUM2X16DJo
de0qxTQEJPKU2KGSdhohAYqhJsSr0HwTyNBFxYQuKABePlEHoX0/8+EJ2LUAWPmh
k7PdnTfHbjWAtBZ7xqXYjfJKDklCZm+9WowsRY8PGaT008oxt9j9WWLTbtoy4fpn
f+Yd8IUqjfLqvlNC5TmjX+MKi3OiKncIZd0/PzPkr26dHvFb6wlNvrxBSz5m46oE
UMcqZvV5QmiaMV7YUVRk9S42/Sep5N4/s1hNwOM08DkeMLH/+k1t14FjtI3/I2CE
9cEDxpOuTHsmst9aUWzRRR9Bzr9rMJttWtBLXAoRViVtLc5LkYEu6P7EdTXSeOi3
2X8GVnP9XZ26m70maAH4yEdQkQsLgeJmpcsrIfsWkvWBJNNDrSEYyVkqkeyAPQC1
/XRoNEbqW62iZDRTtcE8hFAZI6QL2fRtVMdBpQEP8ebeGrEPmCFUfwG7S7aHq16V
Q0sJYD1gtjT4KmFWkIlhgEAishfxnYvLselA2rxsM0KDLp6ADC/78RZIaEYWBgKq
4X7ggiKoua8FSTmf0pc04iUrtLDiecF0Hrfj/zB1fwmnnr0y+FeZVih9Ln4/SqjF
DeJLms4zLkE0XIGV369y
=vs1A
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

If I've understood the problem correctly, dnsmasq is never even seeing
these packets. If the destination address in the IP-level header is
for a random IP address then the kernel network stack will discard the
packet, even if the link-layer MAC address is correct so that the
packet arrives at the network hardware.

Since dnsmasq is listening at the IP level, and doesn't do raw packet
capture, it won't ever see the packets. Note that other DHCP servers
are available (such as ISC dhcpd) which do work at raw packet level.
I'm not sure if dhcpd would behave as you wish in this case, but it
would certainly be simpler to modify it to do so. Unless dnsmasq is
completely re-written to do raw packet capture (which it won't be)
there is not way to modify it to do what you want.


Cheers,

Simon.



On 21/01/17 07:37, Nikita N. wrote:
> Hi, I confirm --dhcp-authoritative works *PERFECTLY* with all other
> clients. Meaning it works when client matches the IP layer address,
> and when Dst: Broadcast (ff:ff:ff:ff:ff:ff) and Src: 0.0.0.0
> (0.0.0.0) and Dst: 255.255.255.255 (255.255.255.255). Unfortunately
> my bugged client has IP Src bugged, and IP Dst gateway bugged. No
> matter that, I see those DHCP request frames in the server network 
> where I run dnsmasq (because my net conf is so), so also dnsmasq
> sees them. I believe the option I'm looking for is smtng like: if a
> UDP frame with Dst Port: 67 comes from Src: macX, and is *NOT*
> protocol/standard valid, then dnsmasq sends a DHCP NAK with Dst:
> macX (e.g. similar to the different cases when dnsmasq sends NAK
> with option Message wrong network, whatever) Is that possible? 
> Thanks
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhfNUAAoJEBXN2mrhkTWik3kP/jeqWsbPY0TCXvgpSORy3aPG
WjU99BQsDth+EJDFrDwNlhqlq8iLrMRGHnyK8BCLcu9d7kqHuqPJrECIdzs8pyVx
J7qoux6lJI/hqWrQihFLaZbxPl4XkAxPBw+zZDecjBA5m4JzSfX4Zutq9jgjiVAJ
EMgPFgc/RZbm7eiid2Mrd5FhOei7aH//S99p7EQjSk+X6eNiHdpnvXfaNQjeQRQ/
2JSMcI3hkjc3GJgcD7a/NIfLYpMFeW48RZ7eUyFYm3FAx1PbBKf1OaqeO0eCjZ4u
C2CwjWRX+qefdQtQ/GzyYtHWCUX5sIrNCwKO6+zwhn74Yjm48TKV7IKtK/ypGCGH
2eqsYo32W1fa5e4QaG7IzcmV0uew20MgcKWjjKYBxr3K8edp4t55c4bS1gwLS1ou
9b5KK6s6uUvM0IcMxP6y71JPlvkndDwRjRqaeFdxD+Lr6HL5Faxw20eBOv/C9PNe
nzfJVZQ2+ReEHMThKakmXrEICbv3yNY2axnTg7an4fuheLDVNY5+9SENUb+PAOwt
o/ACsW2ue/2ufgGJjmoW5mU+3/e/TlKi1v8MqUcxeCoC7JeeD/qk5oySDgNXaZZp
X5FZWj/Nb+7qBSJtoWre8v9J3g70oKNTFyQ5x6m/9B5h5lBCK5skkpS3LXWr6IJ8
/89setpR61Nh7zD+bA0v
=qGI/
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] will there be a 2.77 release anytime soon?

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

T'would probably be a good idea, just for accumulated bug-fixes. Would
be nice to nail the DNSSEC compression pointers bug first though.


Cheers,

Simon.



On 22/01/17 16:41, Dave Taht wrote:
> just checkin
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhe07AAoJEBXN2mrhkTWiCEMP/ifLtkSJDJgTSGUgcds2t/m5
Dp75uxr+D+03qGGzGrCr5k9PPJ61C6ZuPnhgLUISmaJIzxHGZf/3gyGhCBbtTiCX
b5e7d+1RzGVrCzQu8WXTWaCzvcO2xdS3a5TjCQd7SG+DiXJBzF2xE5h1mABTGylI
WcgWqDXUlZrNVXG2AHoZWJQtUraYwROtK9ZkoTErCCnkFvtP5ea3FS+CMMM1ZXFu
AD85DQqpg5ByrWvt8TpX0NxWVxAHP2ML3nmtNXybMGp0Op5UGzoRKnNDyHrPp7Ep
vCGGSuyV3+o7JeAcNAr5pvVU6zxWVhXT87wFgQG1Djg6yWQ2oLTbxDhL9Iv5cXug
gkuFocmxI5r05LUrwtLA/mAXVX81BQHoM2iG/rHPXeRLjkzcENnKT5mnTWsHaqyk
KUQcTlbPHqIUNv76VaEMl3BNyYCQNEilvWddrlSJ6mjkw3Z720Q8LRr/foHyamPm
Kl0RGw03Emw0SxACSGtGPmpdnKFDzv13zSp3StXAyPmIBnbVwf/sphjQA2YXKHWE
90XzTJ9mfbOGIk5EYSaivZ/aqJFNWtGw5DpUnu//F/CnxGIYbZUTvRO3vcRErUHq
lOKmyy3hI8/bokfYydX6918oqn8yVwBmDPiSY9g834nfJoJrtuaGiw+QLJ44phrQ
4tXLVVtZMIorrlzbHTD9
=pkRV
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Making dnsmasq make OFFER faster than virtualbox NAT DHCP

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Actually, it's permitted to have more than once DHCP server, but the
client is entitled to wait for some time to hear from them all, and
then pick whichever one it prefers, so trying to implement server
priority by speed-of-reply is doomed to failure.


Cheers,

Simon.


On 23/01/17 01:54, wkitt...@gmail.com wrote:
> On 01/22/2017 08:02 PM, Sebastian Tarach wrote:
>> Hello,
>> 
>> I'm trying to make *dnsmasq* work on my Debian Virtualbox guest
>> but I keep getting reply from my VBox host DHCP first.
> 
> there should only ever be one DHCP server running on any net
> segments... turn off or otherwise disable all the others and you
> should see the results you desire...
> 
> FWIW: rogue DHCP servers are the bane of sysdamins everywhere...
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhe3SAAoJEBXN2mrhkTWiKykP/A4vpT9i4v6KDScSrFdux7Ym
0EtCFXXj3A9WYVuW3dnrg+IWvCb/XK4fPoB0Y5MoiLnfeiLhpcV5YcOUc5eSy+sn
MUry54inMu6qjtUATBUXTHSIMha132WDbvuEMad+D5mCgvuJSDJ0qGDrD3DHaoOC
nsAVxoVJKSfEjdcCIKUvgkVnrRX8rm6BfWfUIHiT9MoihVv/wyI7mitiStnCP32y
q3TcOaOgFgdqiaWGhBckPm2HUefGf8dlwlM9VDNhccYozAIH4XDp/KRiaRVIVfIk
/qh5ckYlZ9vXXmx+HRHb7AtQV9ZXlVOozJYRrnpe8OHZlXg2SkFL3y3HL+xEMNH/
1x15Rr2PLWFIqQmVcehFimUt14zWhnF9Wg/F1jRH+75r3Os/ewwO1Y/frOSMb2V5
1aiA6NsKAUwZ5yc878AYeHEGpLs5GnNWfhNeoTXcel59imJWIX8NMkotJIx8RyoX
Xm2JLPsKHMU8QTmmNNGplyMJ3kHhoCgBygFPOHnbYfG8TyxV4zqDLueIp6ZBoz3H
FyiOh/DUp5wSE+wpUDNtN0PGKyYuX5WPtuQooJHRB+ReDCpaOyJGFUhJigwciJCu
ngO/UlizUAz3q+zDaZTBD9H2X5zJnwLzwqezB6c3verLVBEoZX28BAilLCGLYVp5
MYYVgKaCr6Ibpv3GEXdQ
=pZLP
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Is there a way to disable file/directory polling for specific addn-hosts files or conf-dir changes?

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dnsmasq won't re-read /etc/hosts or files in a directory specified by
- --addn-hosts automatically. It _will_ re-read files in a directory
specified by --hostsdir. Armed with that information, the first thing
to do might be to look at exactly what configuration you're using.

Once that's sorted out, I'd be interested to know why dnsmasq is
behaving so badly in that case. Are these files very big?


Cheers,

Simon.


On 22/01/17 13:06, TheWerthFam wrote:
> The openwrt platform I'm using seems to support the ionotify
> feature( I believe that many openwrt platforms don't).  The
> application I'm working on updates files in the addn-hosts and
> conf-dir daily.  When this happens the dnsmasq process identifies
> that files have changed and automatically tries to reload/reread
> them(I understand because of the dnsmasq option polling).  For some
> reason dnsmasq doesn't seem to reload/reread them well/properly.
> The reload process takes 5 minutes at very high cpu load on a
> reload/reread.  Where if dnsmasq where just restarted it startups
> with in 10 seconds, while also loading the entries in the
> addn-hosts and conf-dir locations.
> 
> Question is: Is there a way to either turn off polling for just
> these specific addn-hosts and conf-dir locations while keeping the
> polling active to allow dnsmasq to watch /etc/hosts and
> /etc/resolv.conf as normal? Or to force a restart on file change vs
> a reload/reread as it does now?
> 
> Thanks Derek
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhezDAAoJEBXN2mrhkTWil6MP/011OJdvw/0ios0hHTooKCuY
rbNuPydkKtT+Jzi2P1BMN/FrpLUtxTEKjWw+KKtNbVaBl7M7EjceECjE4Zk28HgV
pyCXQjQeqGzj2jlUjcv0IUSxQtG7fdWn1pSuiyKuuOUpCc2UTIanuWUe1ibMyC8F
X9YpS6ewF7mTxmStPIydcEbyLHhGLHQ/WklLIt4y0iir5Nzu6MEVgFBjvdOJbJA/
UCOHY5P9pJSoj2LAg4YOtkN0rI6Cqp53pl2mquaQsdl1K+v3EDk2r/+HuzuY5NIz
lyaUHj/kG9fAIJ5LvwMkxvYA2BqcrBOkf4C+zJdTFBd1QGNc9nEUHwXviaz6owuW
13Kv3EHvgTUj1eu+35XwuxwE1E8OCRmou9Ilz22ioY8VjIfpRsZyUKgScsFuAHfa
RzE5oJWa9+x2R2JRfW73OuEb6vNM5w4kdAMlaiMChmICtD/ND4sYzvq6PcDv+AwG
+lubWqmtdJF0tDlquqSjYup8ZPdsqzduAv6cO0Nnos2KKqYk0ilsZSlQObXeZG0P
6qiSIz0+JJUqjthCH1zHY2jERgDBVESe5TqvuElyFpjw4pf/nqXIfiKHlJv6H6Zs
19E1dV/j04Fo0BewyMmxAJWzx+qPs44TqxTPFU983PX2UCA9qibHnKuB5Jrrk/aM
3Vk1P+l2gSwcbACAUO7O
=s6QL
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] About UEFI PXE booting in proxy mode

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Below is the reply I sent to your original mail to me. The reply
bounced, seemingly due to a misconfiguration of the MX record for your
domain. Hopefully this will get to you via the list.


Simon.


- 
- --

I can shed some light on this, but not give you a complete answer.

Firstly, your 2-not-working example fails because it's not using PXE.
PXE clients do sensible things when the "bootfile name" is set in DHCP
replies, which is what dhcp-boot does, but this isn't the complete PXE
protocol. Hence example one works. That trick doesn't work for
PXE-proxy, since you need the PXE protocol to do proxy. Any
configuration without pxe-service enabled will never work for PXE
proxy. That explains config 2.

Your example 3 - I'm confused why that shouldn't work - the PXE client
seems to be making further requests which are bring ignored. Would it
be possible for you to get a packet dump of that exchange using tcpdump?

Example 4 looks quite hopeful - the client is succerssfully
downloading the bootx64.efi file (ignore the error before, that's just
testing for the existance of the file.

Can you see what's displayed on the client system at this point?


On 18/01/17 14:36, Jr-Huang Shiau wrote:
> Dear all, I am having the same issue as Juan García-Pardo described
> here: 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q4/010931
.html
>
>  On Ubuntu 16.04, I use dnsmasq which is backported from Ubuntu
> 16.10: dpkg -l dnsmasq Desired=Unknown/Install/Remove/Purge/Hold | 
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tri
g-pend
>
> 
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version  Architecture
> Description 
> +++-==---=

>
> 
ii  dnsmasq2.76-5   all  Small
> caching DNS proxy and DHCP/TFTP server
> 
> I configured a PXE server, and disabled the isc-dhcp-server and
> tftpd-hpa so that I can test the DHCP proxy function of dnsmasq.
> 
> 1. When the attached config file "1-working-local.conf" is used as 
> /etc/dnsmasq.conf without DHCP proxy, both PXE or uEFI client boot 
> successfully.
> 
> 2. When the attached config file "2-not-working-proxy.conf" is used
> as /etc/dnsmasq.conf with DHCP proxy, both PXE or uEFI client can
> _NOT_ boot successfully. In the log file "2-not-working-proxy.log"
> you can see either PXE or uEFI client fails to enter network
> booting.
> 
> 3. When the attached config file "3-partial-working-local.conf" is
> used as /etc/dnsmasq.conf without DHCP proxy, PXE client can boot 
> successfully. However, EFI client did not. The log file was
> attached as "3-not-working-efi-local.log".
> 
> 4. When the attached config file "4-partial-working-proxy.conf" is
> used as /etc/dnsmasq.conf with DHCP proxy, PXE client can
> successfully enter network booting, as shown in
> "4a-working-pxe-client-proxy.log". However, for EFI network client,
> just "bootx64.efi" was downloaded, no other files were downloaded,
> as shown in "4b-not-working-efi-client-proxy.log". For comparison,
> you can see in "1-working-efi-no-proxy.log", without DHCP proxy,
> the clients should download grub config file "grub.cfg" and other
> files.
> 
> Therefore it seems there is some uEFI network booting issues, no 
> matter it's using proxy or not.
> 
> If you need me to do more tests or more info, please let me know. 
> Thank you very much.
> 
> Steven
> 
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYgUIIAAoJEBXN2mrhkTWiJPkP/1yjXLO6q7UbhvhM0b3Hdwfc
v19A39lp4VhL3ujt21+jSdsWwsqPCJcLfkkkW2OCI6niRR40UVPMU3eYvk+Uxc1p
LlP/ZJj5ayNUQ1EvuqqJQwRTwdnaYFmgxvR6HhCKXWnEzKK+3x52p273O2B/O9Ld
V429G4y7G8Or3UKC4Bk6ww9I/KZ/r0ufTVstWW0nW2wqA9zzf009JofN6yUbJcUN
dT1jetjbiiHCgyeFodtm7PVcda/E2uwVr/8ScXQgvqbser78AId6O72FkysLplDd
Fo59KWsawqJO8+C/YCKCTXIMp3yFPgcv1KCgBmieR4eEr7RXcu0l4+iEsYvamvsJ
MJ1KV6ts2Pt5bA7gszuP2PDNlt+t0K/dnpDaxRcGbyI4lhamqEnzH/wd7FUylcLl
U8K7EYwlz7CoQKXqi6qP6EU4qeTyVMQmKoeY907WKt1DZMqWH7Ye9iTvihA+3a95
RqCuEWk3BsrZ/hOEKpeEmVy8cwh4gkrI6elszjmC5rYEvlwRwVezZK9zA/xRdfn+
7jkE4P08/L5qhtrOCnBCW3+6AbHyRblJGSR/dEB8cSIUdqGXTJpGtxWAQPjgOrzJ
Q0iE/2omLUcjgWGvZwZTsm2bWlqC9Lj9jIW00QXCZDo//QgUBVlkUMiO+l6IdggT
ctKEAYejg9k832KJt3J0
=OwJE
-END PGP SIGNATURE-

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