Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Simon Kelley]

On 16/02/2022 20:19, Martin-Éric Racine wrote:

The startup message DOES suggest that DHCP is bound to an exclusive
interface, not to wildcard.  This is misleading.


No it's not. it calls setsockopt(SO_BINDTODEVICE) which binds the socket 
to the physical interface, instead of to a IP address.



Meanwhile TFTP is not meant to appear on loopback.


Why? I guess we could argue the 15-year old design decision to do that, 
but it would be pointless since I'm not going to change it now and risk 
breaking installations which rely on it.


As I said, that option is available using --listen-address.

Simon.



Martin-Éric

On Wed, Feb 16, 2022 at 10:11 PM Simon Kelley  wrote:


67 is DHCP and always binds the wildcard: that's necessary to make DHCP
work. It checks the arrival address of packets and discards those which
are not valid.

interface= is documented to listen on the addresses of the given
interface AND LOOPBACK. If you want to exclude loopback, you can do


listen-address=17n172.16.1.22.16.1.2
(
instead.

Simon.

On 16/02/2022 19:58, Martin-Éric Racine wrote:

bind-enterfaces is supposed to restrict the services to exactly those
defined in interfaces. It currently doesn't.

My reduced config:

bogus-priv
conntrack
dns-loop-detect
dnssec
domain-needed
domain=lan
local=/lan/
expand-hosts
dhcp-hostsfile=/etc/dhcp-hostsfile
dhcp-fqdn
dhcp-option=option:dns-server,0.0.0.0,9.9.9.9,1.1.1.1
dhcp-option=option6:dns-server,[::]
dhcp-range=tag:br0,172.16.0.0,static,infinite
dhcp-range=tag:br0,::,constructor:br0,ra-names,ra-stateless,infinite
quiet-ra
interface=br0
bind-interfaces
enable-tftp
tftp-root=/srv/tftp
dhcp-boot=net:eth,/debian-installer/i386/undionly.kpxe
dhcp-boot=net:pxe,/debian-installer/i386/pxelinux.0
dhcp-vendorclass=eth,Etherboot
dhcp-vendorclass=pxe,PXEClient
dhcp-option=vendor:pxe,6,2b
#EOF

What the startup log shows:

Feb 16 21:51:07 voima systemd[1]: Starting dnsmasq - A lightweight
DHCP and caching DNS server...
Feb 16 21:51:07 voima dnsmasq[8813]: started, version 2.85 cachesize 150
Feb 16 21:51:07 voima dnsmasq[8813]: compile time options: IPv6
GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack
ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Feb 16 21:51:07 voima dnsmasq[8813]: DNSSEC validation enabled
Feb 16 21:51:07 voima dnsmasq[8813]: configured with trust anchor for
 keytag 20326
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, static leases only on
172.16.0.0, lease time infinite
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, sockets bound
exclusively to interface br0
Feb 16 21:51:07 voima dnsmasq-tftp[8813]: TFTP root is /srv/tftp
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: reading /etc/resolv.conf
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: read /etc/hosts - 20 addresses
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: read /etc/dhcp-hostsfile
Feb 16 21:51:07 voima systemd[1]: Started dnsmasq - A lightweight DHCP
and caching DNS server.

Yet netstat shows me:

$ netstat  | grep dnsmasq | grep -v p6
tcp0  0 127.0.0.1:530.0.0.0:*
LISTEN  7036/dnsmasq
tcp0  0 172.16.1.2:53   0.0.0.0:*
LISTEN  7036/dnsmasq
udp0  0 0.0.0.0:67  0.0.0.0:*
   7036/dnsmasq
udp0  0 127.0.0.1:530.0.0.0:*
   7036/dnsmasq
udp0  0 127.0.0.1:690.0.0.0:*
   7036/dnsmasq
udp0  0 172.16.1.2:53   0.0.0.0:*
   7036/dnsmasq
udp0  0 172.16.1.2:69   0.0.0.0:*
   7036/dnsmasq

67 is on wild card and 69 appears on loopback. Neither of these should
happen. They should only be on 172.16.1.2 yet they aren't. Basically,
unless I misunderstood something, nothing except 53 should appear on
loopback as per the above config.

Cheers!
Martin-Éric


On Wed, Feb 16, 2022 at 9:36 PM Simon Kelley  wrote:


I'm not clear what you think is happening, and what you want to happen.

bind-interfaces works for tftp; there will be a socket for each address
on each valid interface bound to that address and port 69

no-dhcp-interface does indeed suppress tftp on that interface too, and
is documented so to do.


Cheers,

Simon

Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Simon Kelley]

67 is DHCP and always binds the wildcard: that's necessary to make DHCP 
work. It checks the arrival address of packets and discards those which 
are not valid.


interface= is documented to listen on the addresses of the given 
interface AND LOOPBACK. If you want to exclude loopback, you can do



listen-address=17n172.16.1.22.16.1.2

instead.

Simon.

On 16/02/2022 19:58, Martin-Éric Racine wrote:

bind-enterfaces is supposed to restrict the services to exactly those
defined in interfaces. It currently doesn't.

My reduced config:

bogus-priv
conntrack
dns-loop-detect
dnssec
domain-needed
domain=lan
local=/lan/
expand-hosts
dhcp-hostsfile=/etc/dhcp-hostsfile
dhcp-fqdn
dhcp-option=option:dns-server,0.0.0.0,9.9.9.9,1.1.1.1
dhcp-option=option6:dns-server,[::]
dhcp-range=tag:br0,172.16.0.0,static,infinite
dhcp-range=tag:br0,::,constructor:br0,ra-names,ra-stateless,infinite
quiet-ra
interface=br0
bind-interfaces
enable-tftp
tftp-root=/srv/tftp
dhcp-boot=net:eth,/debian-installer/i386/undionly.kpxe
dhcp-boot=net:pxe,/debian-installer/i386/pxelinux.0
dhcp-vendorclass=eth,Etherboot
dhcp-vendorclass=pxe,PXEClient
dhcp-option=vendor:pxe,6,2b
#EOF

What the startup log shows:

Feb 16 21:51:07 voima systemd[1]: Starting dnsmasq - A lightweight
DHCP and caching DNS server...
Feb 16 21:51:07 voima dnsmasq[8813]: started, version 2.85 cachesize 150
Feb 16 21:51:07 voima dnsmasq[8813]: compile time options: IPv6
GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack
ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Feb 16 21:51:07 voima dnsmasq[8813]: DNSSEC validation enabled
Feb 16 21:51:07 voima dnsmasq[8813]: configured with trust anchor for
 keytag 20326
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, static leases only on
172.16.0.0, lease time infinite
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, sockets bound
exclusively to interface br0
Feb 16 21:51:07 voima dnsmasq-tftp[8813]: TFTP root is /srv/tftp
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: reading /etc/resolv.conf
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: read /etc/hosts - 20 addresses
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: read /etc/dhcp-hostsfile
Feb 16 21:51:07 voima systemd[1]: Started dnsmasq - A lightweight DHCP
and caching DNS server.

Yet netstat shows me:

$ netstat  | grep dnsmasq | grep -v p6
tcp0  0 127.0.0.1:530.0.0.0:*
LISTEN  7036/dnsmasq
tcp0  0 172.16.1.2:53   0.0.0.0:*
LISTEN  7036/dnsmasq
udp0  0 0.0.0.0:67  0.0.0.0:*
  7036/dnsmasq
udp0  0 127.0.0.1:530.0.0.0:*
  7036/dnsmasq
udp0  0 127.0.0.1:690.0.0.0:*
  7036/dnsmasq
udp0  0 172.16.1.2:53   0.0.0.0:*
  7036/dnsmasq
udp0  0 172.16.1.2:69   0.0.0.0:*
  7036/dnsmasq

67 is on wild card and 69 appears on loopback. Neither of these should
happen. They should only be on 172.16.1.2 yet they aren't. Basically,
unless I misunderstood something, nothing except 53 should appear on
loopback as per the above config.

Cheers!
Martin-Éric


On Wed, Feb 16, 2022 at 9:36 PM Simon Kelley  wrote:


I'm not clear what you think is happening, and what you want to happen.

bind-interfaces works for tftp; there will be a socket for each address
on each valid interface bound to that address and port 69

no-dhcp-interface does indeed suppress tftp on that interface too, and
is documented so to do.


Cheers,

Simon.


On 16/02/2022 13:42, Martin-Éric Racine wrote:
  > Package: dnsmasq
  > Version: 2.85-1
  > Severity: important
  >

If 'enable-tftp' is set, the TFTP server appears on all interfaces. It 
completely disregards bind-interfaces and friends. One would think that TFTP 
would only be offered on interfaces where dnsmasq happens to offer DHCP 
services (since DHCP essentially is a superset of BOOTP, to which TFTP is 
related), but apparently not.

The relevant part of my config:

bind-interfaces
interface=br0
except-interface=enp4s0
no-dhcp-interface=enp4s0

IMHO, the only service that dnsmasq should offer on both loopback and 
'interface' is DNS. It ought to be possible t

Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Simon Kelley]

I'm not clear what you think is happening, and what you want to happen.

bind-interfaces works for tftp; there will be a socket for each address 
on each valid interface bound to that address and port 69


no-dhcp-interface does indeed suppress tftp on that interface too, and 
is documented so to do.



Cheers,

Simon.


On 16/02/2022 13:42, Martin-Éric Racine wrote:
> Package: dnsmasq
> Version: 2.85-1
> Severity: important
>

If 'enable-tftp' is set, the TFTP server appears on all interfaces. It 
completely disregards bind-interfaces and friends. One would think that TFTP 
would only be offered on interfaces where dnsmasq happens to offer DHCP 
services (since DHCP essentially is a superset of BOOTP, to which TFTP is 
related), but apparently not.

The relevant part of my config:

bind-interfaces
interface=br0
except-interface=enp4s0
no-dhcp-interface=enp4s0

IMHO, the only service that dnsmasq should offer on both loopback and 
'interface' is DNS. It ought to be possible to bind every other service that 
dnsmasq can offer to specific interfaces.

If the above already is possible, but my particular combination of 
bind-interfaces/interface/except-interface/no-dhcp-interface prevents that, I 
welcome tips on how to fix it.

Martin-Éric

-- System Information:
Debian Release: 11.2
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnsmasq depends on:
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  runit-helper 2.10.3

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  

-- no debconf information

Bug#981726: dnsmasq: segfaul after linux update. Then dnsmasq 10u1 has the same problam. Thanks.

[Simon Kelley]

That's not good.

I need to reproduce this here, and I can't as yet.

Could you send a copy of your dnsmasq configuration file and maybe a
copy of /use/sbin/dnsmasq

Simon.



On 03/02/2021 09:32, Marek Jambrich wrote:
> Package: dnsmasq
> Version: 2.80-1+deb10u1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>In my opinion linux update (DSA-4843-1 linux) led to this situation.
> 
> Feb  3 10:11:09 procont systemd[1]: Started dnsmasq - A lightweight DHCP and 
> caching DNS server.
> Feb  3 10:11:10 procont kernel: [ 9048.013608] dnsmasq[31577]: segfault at 0 
> ip 7f4600c97206 sp 7fff6ae1a278 error 4 in 
> libc-2.28.so[7f4600c21000+148000]
> Feb  3 10:11:10 procont kernel: [ 9048.013621] Code: 0f 1f 40 00 66 0f ef c0 
> 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 
> 81 f9 cf 0f
> 00 00 77 6a  0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 
> 83
> Feb  3 10:11:10 procont systemd[1]: dnsmasq.service: Main process exited, 
> code=killed, status=11/SEGV
> Feb  3 10:11:10 procont systemd[1]: dnsmasq.service: Failed with result 
> 'signal'.
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: 10.7
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages dnsmasq depends on:
> ii  dnsmasq-base [dnsmasq-base]  2.80-1+deb10u1
> ii  init-system-helpers  1.56+nmu1
> ii  lsb-base 10.2019051400
> ii  netbase  5.6
> 
> dnsmasq recommends no packages.
> 
> Versions of packages dnsmasq suggests:
> pn  resolvconf  
> 
> -- no debconf information
> 

Bug#958100: fixed in dnsmasq 2.81-2

[Simon Kelley]

On 19/04/2020 09:55, Laurent Bigonville wrote:
> On Sat, 18 Apr 2020 18:48:37 + Debian FTP Masters
>  wrote:
> [...]
>> dnsmasq (2.81-2) unstable; urgency=low
>> .
>> * Fix FTBFS on kFreeBSD. (closes: #958100)
> 
> Thanks for the fast upload, the package is now building fine.
> 
> Why didn't you apply the changes to the debian/control file that I
> proposed as well?
> 
> pkg-config is needed to build the package, it was also needed before my
> patch, so adding it to the build-dependencies is necessary. Packages
> using pkg-config should BD on it and not rely on other -dev packages to
> pull it IMVHO.
> 
> Regarding the build-dependency on libbsd-dev, it is only needed on
> kfreebsd, not hurd, that's why I changed the architecture from
> !linux-any to kfreebsd-any
> 
> Kind regards,
> 
> Laurent Bigonville
> 

Argh. Oversight on my part. Apologies. I just uploaded 2.81-3 which
fixes this.

Simon.

Bug#929884: dnsmasq: please provide runscript file

[Simon Kelley]

On 17/03/2020 01:21, Lorenzo Puliti wrote:
> Package: src:dnsmasq
> Followup-For: Bug #929884
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.5.9-van (SMP w/4 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: runit (via /run/runit.stopit)
> 
>> [ I no longer using Debian, added new runit maintainer into CC. ]
> 
> Hi,
> 
>> Runscript is using #!/lib/runit/invoke-run as interpreter, which sources
>> /etc/default/dnsmasq automatically.
> 
> exactly
> 
> About the patch, I suggest a change in the following part
> 
>> +++ b/debian/dnsmasq.runit
>> @@ -0,0 +1 @@
>> +debian/dnsmasq.runscript name=dnsmasq,logscript,since=2.80-1+runit
>> diff --git a/debian/dnsmasq.runscript/finish 
>> b/debian/dnsmasq.runscript/finish
>> new file mode 100755
>> index 000..cf35240
>> --- /dev/null
>>
> 
> If you use dh-runit >= 2.8.15 to build, the 'since' option is obsoleted (no 
> longer needed);
> I've forgot to mention that in the manpage, I will add a note in the next 
> upload.
> You probably want to add the 'presubj' option instead, that suggest the 
> reporter to add
> the runit maintainer in CC when reporting a bug, if he is using runit
> 
> the line would look like this
> 
> +debian/dnsmasq.runscript name=dnsmasq,logscript,presubj
> 
> In any case, if you decide to merge this and some runit-specific bug should 
> arise, feel
> free to add me in CC, I will provide assistance.
> 

Thanks for the info. I merged the original patch with some changes and
I've made the change you suggest as well.

If you could check out the package as it stands in the dnsmasq git repo
before the imminent 2.81 release, that would be great.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary

Cheers,

Simon.

Bug#929884: dnsmasq: please provide runscript file

[Simon Kelley]

A query: the runscript/run file in the patch ignores
/etc/default/dnsmasq. If that deliberate, or an oversight?


Simon.



On 02/06/2019 14:34, Dmitry Bogatov wrote:
> Source: dnsmasq
> Version: 2.80-1
> Severity: wishlist
> Tags: patch
> User: ru...@packages.debian.org
> Usertags: runscript
> 
> Dear maintainer,
> 
> please include native script for runit init system into 'dnsmasq'.
> Below is diff aganist latest package release (2.80-1).
> 
> Here are some links:
> 
>  * http://smarden.org/runit -- more information about 'runit'
>  * https://bugs.debian.org/746715 -- technical committe position
>on support of init systems, other then sysvinit.
> 
> From 3c516dde2b8dd552b141196ed98379800b3e0611 Mon Sep 17 00:00:00 2001
> From: Dmitry Bogatov 
> Date: Sun, 26 May 2019 18:54:36 +
> Subject: [PATCH] Add integration script for runit init
> 
> ---
>  debian/control  |  5 ++--
>  debian/dnsmasq.runit|  1 +
>  debian/dnsmasq.runscript/finish |  5 
>  debian/dnsmasq.runscript/run| 43 +
>  debian/rules|  7 +-
>  5 files changed, 58 insertions(+), 3 deletions(-)
>  create mode 100644 debian/dnsmasq.runit
>  create mode 100755 debian/dnsmasq.runscript/finish
>  create mode 100755 debian/dnsmasq.runscript/run
> 
> diff --git a/debian/control b/debian/control
> index 9d4d7e8..40ad6c6 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -4,7 +4,7 @@ Priority: optional
>  Build-depends: gettext, libnetfilter-conntrack-dev [linux-any],
> libidn11-dev, libdbus-1-dev (>=0.61), libgmp-dev, 
> nettle-dev (>=2.4-3), libbsd-dev [!linux-any],
> -liblua5.2-dev
> +liblua5.2-dev, dh-runit, debhelper-compat (= 10)
>  Maintainer: Simon Kelley 
>  Homepage: http://www.thekelleys.org.uk/dnsmasq/doc.html
>  Standards-Version: 3.9.8
> @@ -12,8 +12,9 @@ Standards-Version: 3.9.8
>  Package: dnsmasq
>  Architecture: all
>  Depends: netbase, dnsmasq-base,
> - init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6)
> + init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6), ${misc:Depends}
>  Suggests: resolvconf
> +Breaks: ${runit:Breaks}
>  Conflicts: resolvconf (<<1.15)
>  Description: Small caching DNS proxy and DHCP/TFTP server
>   Dnsmasq is a lightweight, easy to configure, DNS forwarder and DHCP
> diff --git a/debian/dnsmasq.runit b/debian/dnsmasq.runit
> new file mode 100644
> index 000..6a457f7
> --- /dev/null
> +++ b/debian/dnsmasq.runit
> @@ -0,0 +1 @@
> +debian/dnsmasq.runscript name=dnsmasq,logscript,since=2.80-1+runit
> diff --git a/debian/dnsmasq.runscript/finish b/debian/dnsmasq.runscript/finish
> new file mode 100755
> index 000..cf35240
> --- /dev/null
> +++ b/debian/dnsmasq.runscript/finish
> @@ -0,0 +1,5 @@
> +#!/bin/sh -eu
> +if [ -x /sbin/resolvconf ] ; then
> + /sbin/resolvconf -d lo.dnsmasq
> +fi
> +
> diff --git a/debian/dnsmasq.runscript/run b/debian/dnsmasq.runscript/run
> new file mode 100755
> index 000..1a43393
> --- /dev/null
> +++ b/debian/dnsmasq.runscript/run
> @@ -0,0 +1,43 @@
> +#!/lib/runit/invoke-run
> +
> +readonly name=dnsmasq
> +readonly daemon=/usr/sbin/dnsmasq
> +readonly marker=/usr/share/dnsmasq/installed-marker
> +
> +test -e "${marker}" || exec sv down "${name}"
> +test -x "${daemon}" || exec sv down "${name}"
> +
> +if [ ! "${RESOLV_CONF:-}" ] &&
> +   [ "${IGNORE_RESOLVCONF:-}" != "yes" ] &&
> +   [ -x /sbin/resolvconf ]
> +then
> + RESOLV_CONF=/run/dnsmasq/resolv.conf
> +fi
> +
> +# This tells dnsmasq to ignore DNS requests that don't come from a local 
> network.
> +# It's automatically ignored if  --interface --except-interface, 
> --listen-address 
> +# or --auth-server exist in the configuration, so for most installations, it 
> will
> +# have no effect, but for otherwise-unconfigured installations, it stops 
> dnsmasq
> +# from being vulnerable to DNS-reflection attacks.
> +
> +DNSMASQ_OPTS="${DNSMASQ_OPTS:-} --local-service"
> +
> +# If the dns-root-data package is installed, then the trust anchors will be 
> +# available in $ROOT_DS, in BIND zone-file format. Reformat as dnsmasq
> +# --trust-anchor options.
> +
> +ROOT_DS="/usr/share/dns/root.ds"
> +
> +if [ -f $ROOT_DS ]; then
> +DNSMASQ_OPTS="$DNSMASQ_OPTS `env LC_ALL=C sed -rne 
> "s/^([.a-zA-Z0-9]+)([[:space:]]+[0-9]+)*([[:space:]]+IN)*[[:space:]]+DS[[:space:]]+/--trust-anchor=\1,/;s/[[:space:]]+/,/gp"
>  $ROOT_DS | tr '\n' ' '`"

Bug#942363: dnsmasq breaks "dig +trace"

[Simon Kelley]

Can I query the version number for this? I think that this behaviour was
fixed in the 2.80 upstream release and therefore the Debian 2.80-1 package.

Simon.

Bug#923746: dnsmasq: ra advertises wrong ipv6 link MTU

[Simon Kelley]

On 04/03/2019 23:02, Chris Carr wrote:

>    * What outcome did you expect instead?
> 
> I expected Windows to receive the correct MTU size of 1280 as set in
> /proc/sys/net/ipv6/conf/he-ipv6/mtu
> 

> interface=int0
> dhcp-range=tag:int0,::1,constructor:int0,ra-names,24h

There seem to be two different interfaces here. It looks like dnsmasq
may be advertising on int0 with the MTU for int0, and I'm not clear
where he-ipv6 comes into the equation.

Simon.

Bug#911408: dnsmasq breaks systemd autopkgtest

[Simon Kelley]

: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question kettle.cantina.company IN SOA: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question kettle.cantina.company IN A: no-signature
> 
> So for some reason, with v2.80, DNSSEC is attempted for this query.
> Maybe you have an idea what's going on there.
> 
> Regards,
> Michael
> 


Thanks for the additional information: I think I can see what's
happening here, and it's a combination of things, as usual.

There is a bug in dnsmasq (as I mentioned before) that if the query has
the ad bit set, (requesting DNSSEC validation) then in this particular
case (answer comes from --address in the command line or config file)
the ad bit is set in the answer, even though the answer is NOT DNSSEC
validated.

This bug also exists in 2.79, which made me think that it was not the
source of the problem. As you found, the change in 2.80 which triggers
the error is

commit 1682d15a744880b0398af75eadf68fe66128af78
Author: Simon Kelley 
Date:   Fri Aug 3 20:38:18 2018 +0100

Add missing EDNS0 section.
EDNS0 section missing in replies to EDNS0-containing queries where
answer generated from --local=//


So in 2.79, the test gets an answer with the ad bit set (bad), but no
EDNS0 header, and (I guess) decides that it isn't DNSSEC validated,
because EDSN0 is compulsory for DNSSEC. In 2.80, the EDNS0 header is
present, which is correct, it really should be there, but the
pre-existing bug with the ad-bit is now triggered, because the answer
has everything it needs to make it look like it should have DNSSEC
validation, but it doesn't have the relevant signatures.

The two bugs in 2.79 cancelled each other out. The one remaining in 2.80
is now made patent by the fix of the other.

To test this, please could you apply

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

to 2.80 and run the test again? If that fixes the problem, I'll gladly
take to bug back and issue a 2.80-2 with that fix.

Sorry for the back-and-forth. I've not worked out how to run the systemd
test suite and reproduce the problem here.


Cheers,

Simon.





signature.asc
Description: OpenPGP digital signature

Bug#911408: dnsmasq breaks systemd autopkgtest

[Simon Kelley]

On 21/10/2018 00:05, Michael Biebl wrote:
> After rebuilding the LXC chroot, I was able to reproduce the issue after
> all.
> 
> Runnig a git bisect shows the following as the first faulty commit
> 
> 
> commit 1682d15a744880b0398af75eadf68fe66128af78
> Author: Simon Kelley 
> Date:   Fri Aug 3 20:38:18 2018 +0100
> 
> Add missing EDNS0 section.
> EDNS0 section missing in replies to EDNS0-containing queries where
> answer generated from --local=//
> 
> 
> Reverting that commit on top of 2.80-1, I was able to make the systemd
> test suite pass again.
> At this point I consider this a dnsmasq issue and leave it up to Simon
> to deal with it.
> Simon, if you see in an issue in how systemd is using dnsmasq in the
> test-suite, please let us know.
> 


There are a couple of things here.

First, on looking at the reply from the query in the test, there is a
problem. The ad (authenticated data) bit is getting copied straight
though from the query to the reply. If the ad bit is set in the query
(dig does this by default) then a bogus ad bit will be set in the
answer. That's wrong, and will be fixed.

However, that's not a regression introduced by the commit you're
fingering. It happens in the 2.79 release code too, so can't be what is
failing the test.

What the commit does is to add an EDNS0 pseudoheader to the reply. This
is correct, in fact it's more correct than before the commit, when
dnsmasq would usually reply with an EDNS0 header, but omit it when the
reply came from --address=/example.com/1.2.3.4 Ironically, this
inconsistency confuses systemd-resolved, so the change was introduced to
get dnsmasq to work better with  systemd :)


I'm not sure how to find out exactly what the systemd test is, and what
it's looking for in the reply, but if it's looking for

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 -p 1 wibble.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12712
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;wibble.com.IN  A

;; ANSWER SECTION:
wibble.com. 0   IN  A   1.2.3.4

;; Query time: 0 msec
;; SERVER: 127.0.0.1#1(127.0.0.1)
;; WHEN: Sun Oct 21 21:57:20 BST 2018
;; MSG SIZE  rcvd: 44

and receiving


; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 -p 1 wibble.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64851
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wibble.com.IN  A

;; ANSWER SECTION:
wibble.com. 0   IN  A   1.2.3.4

;; Query time: 0 msec
;; SERVER: 127.0.0.1#1(127.0.0.1)
;; WHEN: Sun Oct 21 21:58:48 BST 2018
;; MSG SIZE  rcvd: 55


instead, fails the test then the test needs to be revised.


Cheers,

Simon.



signature.asc
Description: OpenPGP digital signature

Bug#888771: dnsmasq: dhcp-option 'router' is ignored for tagged ranges

[Simon Kelley]

On 29/01/18 18:28, Drexl Johannes wrote:
> Package: dnsmasq
> Version: 2.76-5+deb9u1
> Severity: normal
> 
> Dear Maintainer,
> 
> when using tags for different address ranges (e. g. privilege separation) for 
> IPv4, option 3 (router) is not forwarded to the client. In its stead the 
> interface IP of the server is forwarded as router, which in some scenarios is 
> not the case at all. 
> 
>>From the config file:
> # Defining subnet
> # enp31s0 has 192.168.1.8
> dhcp-range=interface:enp31s0,192.168.1.128,192.168.1.254,255.255.255.0> # 
> Setting tags
> dhcp-range=set:wan,192.168.1.128,192.168.1.254
> # Defining domains
> domain=wan.domain.tld,192.168.1.0/24
> # Defining netmask, router, dns server and ntp-server
> # WAN
> dhcp-option = tag:wan, option:netmask, 255.255.255.0
> dhcp-option = tag:wan, option:router, 192.168.1.1
> dhcp-option = tag:wan, option:dns-server, 192.168.1.8
> dhcp-option = tag:wan, option:ntp-server, 192.168.1.8
> 
>

This config is wrong, the first dhcp-range makes no sense.  You need a
single dhcp-range statement


dhcp-range=set:wan,192.168.1.128,192.168.1.254,255.255.255.0

Also the netmask option will be ignored and can be removed,


Since you have log-dhcp switched on, it useful to check that the "wan"
tag is actually set. You have not included that part of the log.


Cheers,

Simon.

Bug#889144: stricter PIDfile handling breaks several daemons

[Simon Kelley]

On 04/02/18 20:26, Sven Hartge wrote:

> Does dnsmasq need a PIDfile when running under systemd? Can't it just
> not double fork, stay in the foreground using a Type=simple systemd unit?
> 
> That way the whole problem could be avoided all together.
> 

Sending signals to the dnsmasq process cause it to take various actions,
so it's likely that there are scripts out there that do the equivalent of

kill - `cat /run/dnsmasq/dnsmasq.pid`

The double-fork code in dnsmasq is also quite careful about error
handling; for instance passing an error code back through a pipe from
the forked process to the original process, so that any failure gets
reflected in the return code when the original process exits. That's
relevant to Michael's point, I think.

Cheers,

Simon.

Bug#889144: stricter PIDfile handling breaks several daemons

[Simon Kelley]

With my dnsmasq maintainer hat on, the current arrangement looks like this.

1) /run/dnsmasq is a directory owned by dnsmasq:nogroup
2) /run/dnsmasq/dnsmasq.pid gets written by dnsmasq before it drops
root, so is root:root
3) The reason /run/dnsmasq is owned by dnsmasq is so that dnsmasq can
unlink the pidfile at shutdown, after it has dropped root and is running
as 'dnsmasq'


There's a potential security hole here, since an attacker who can become
user dnsmasq, can create a symlink at /run/dnsmasq/dnsmasq.pid to
anywhere, and have the target of the symlink overwritten (as root) at
startup. The dnsmasq PID-file creation code detects and blocks this
case: see src/dnsmasq.c around line 507.

I think that this can be fixed in dnsmasq by chown()ing the pid file to
the same user dnsmasq is about to drop privs too, but I'm not sure is
that's enough to keep the new systemd checks happy.

Cheers,

Simon.

Bug#883596: Wron exit code of dhcp_release6

[Simon Kelley]

OK, thanks for that useful information. I see the problem. Fixed upstream at

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


Cheers,

Simon.




signature.asc
Description: OpenPGP digital signature

Bug#883596: Wron exit code of dhcp_release6

[Simon Kelley]

On 05/12/17 15:00, Gaudenz Steinlin wrote:
> 
> Hi
> 
> Sorry for the incomplete bug report. I wanted to resume a reported I did
> not finish with reportbug, but it decided to send the backup copy as is
> instead of letting me edit it before sending.
> 
> Looking at the code the wrong error code results from the return code of
> the parse_packet function which is passed through via
> send_release_packet to main and used as exit code there. Returning -1
> from main results in an exit code of 255 in the shell.
> 
> Gaudenz
> 


Are  sure that this isn't a real error? From a quick look, successfully
doing the release results in a reply with a STATUS_CODE structure
containing a SUCCESS status value, which is zero. This is returned via
parse_packet and send_release_packet to main, and results in a zero
return code. A -1 return from parse_packet implies no STATUS_CODE or
IA_NA in the reply, which is an error.

Cheers,

Simon.




signature.asc
Description: OpenPGP digital signature

Bug#864085: unblock: dnsmasq/2.76-5

[Simon Kelley]

On 04/06/17 16:36, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> On Sun, Jun 04, 2017 at 09:58:44AM +0100, ? wrote:
>> The dnsmasq package in testing has a serious problem when dns-root-data is
>> installed, due to changes in the format of the dns-root-data files.
>> The effect is to render dnsmasq unusable.
> 
> Bother.
> 
>> There are several serious bugs filed to this effect, but they should
>> really be release-critical, eg 863896
>>
>> There are also several bugs in the DNSSEC validation code, which are fixed
>> upstream, and really should be in stretch.
>>
>> Therefore, if we can get dnsmasq-2.77-1, currently in unstable, into Stretch,
>> that would be a Good Thing. If not, it will need a point release.
> 
> The delta from testing to unstable right now is not really suitable this
> late in the process. I would prefer a targetted fix through t-p-u.

I understand.

> 
> However, I wonder if that format change in dns-root-data risks problems in
> other packages. Ondřej, is there any advantage to reverting that (keeping
> the RC fix for parse-root-anchors.sh)?
> 

The patch to fix this in dnsmasq is at :

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=44eb875a5ab2e3b862a6b2bc9fbbb919475d2107

(that regexp handles both old and new formats.)

Cheers,

Simon.

Bug#860274: Root cause

[Simon Kelley]

That change is the fix, not the cause. It's not on 2.76, but has made it
to 2.77. I've requested that the release-managers push 2.77-1 into Stretch.

Cheers,

Simon.


On 04/06/17 13:08, Colin Wetherbee wrote:
> This regression is caused by the following change upstream in dnsmasq:
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=44eb875a5ab2e3b862a6b2bc9fbbb919475d2107
> 
> 
> For those affected by this bug, the work-around is to revert the
> DNSMASQ_OPTS line of /etc/init.d/dnsmasq to its previous format.
> 
> The fix would be to detect the format of root.ds, perhaps by checking
> the version of the package to which it belongs, before attempting to
> parse it.
> 
> - Colin Wetherbee
> 



signature.asc
Description: OpenPGP digital signature

Bug#721751: dnsmasq-base: Always listens on all interfaces

[Simon Kelley]

On 05/08/16 16:59, Clément Hermann wrote:
> Hi,
> 
> Just want to add my bit on this one.
> 
> The documentation states that when "interface" option is used, the
> daemon binds on * but reject queries that come to interfaces not listed.
> 
> This does not work, so eitheir the documentation is misleading or there
> is a bug (arguably a security one, since it leads to a false sense of
> security when you think you're not enabling DNS service on a public
> interface when in fact you are).
> 
> Cheers,
> 

Could you give a specific configuration where this occurs? It would
indeed by a bad bug, but I can't reproduce it.


Cheers,

Simon.

Bug#819856: dnsmasq: diff for NMU version 2.76-1.2

[Simon Kelley]

Hi,

Thanks for this. I need to upload 2.76-2, which has a fix for a
different bug, #831372. I've patched this with the 2.76-1.1 and 2.76-1.2
NMUs, so they're included. However by the time 2.76-1.2 gets to the end
of the delay, 2.76-2 will be in place. That's not going to confuse
things, is it? 2.76-2 > 2.76-1.2, so the NMU won't overwrite my later
upload, which includes the NMU patch?

Cheers,

Simon.




On 16/07/16 01:31, z...@debian.org wrote:
> Control: tags 819856 + patch
> Control: tags 819856 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for dnsmasq (versioned as 2.76-1.2) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
> 
> Best,
> Chris
> 
> 
> diff -u dnsmasq-2.76/debian/changelog dnsmasq-2.76/debian/changelog
> --- dnsmasq-2.76/debian/changelog
> +++ dnsmasq-2.76/debian/changelog
> @@ -1,3 +1,11 @@
> +dnsmasq (2.76-1.2) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * dnsmasq: Install marker file to determine package installed state,
> +for the benefit of the init script. (Closes: #819856)
> +
> + -- Christian Hofstaedtler   Sat, 16 Jul 2016 00:17:57 +
> +
>  dnsmasq (2.76-1.1) unstable; urgency=medium
>  
>* Non-maintainer upload.
> diff -u dnsmasq-2.76/debian/init dnsmasq-2.76/debian/init
> --- dnsmasq-2.76/debian/init
> +++ dnsmasq-2.76/debian/init
> @@ -33,7 +33,7 @@
>  # The following test ensures the dnsmasq service is not started, when the
>  # package 'dnsmasq' is removed but not purged, even if the dnsmasq-base 
>  # package is still in place.
> -test -d /usr/share/doc/dnsmasq || exit 0
> +test -e /usr/share/dnsmasq/installed-marker || exit 0
>   
>  test -x $DAEMON || exit 0
>  
> diff -u dnsmasq-2.76/debian/rules dnsmasq-2.76/debian/rules
> --- dnsmasq-2.76/debian/rules
> +++ dnsmasq-2.76/debian/rules
> @@ -105,6 +105,7 @@
>   -d debian/daemon/etc/dnsmasq.d \
>   -d debian/daemon/etc/resolvconf/update.d \
>   -d debian/daemon/usr/lib/resolvconf/dpkg-event.d \
> + -d debian/daemon/usr/share/dnsmasq \
>   -d debian/daemon/etc/default \
>   -d debian/daemon/lib/systemd/system \
>  -d debian/daemon/etc/insserv.conf.d
> @@ -113,6 +114,7 @@
>   install -m 755 debian/init debian/daemon/etc/init.d/dnsmasq
>   install -m 755 debian/resolvconf 
> debian/daemon/etc/resolvconf/update.d/dnsmasq
>   install -m 755 debian/resolvconf-package 
> debian/daemon/usr/lib/resolvconf/dpkg-event.d/dnsmasq
> + install -m 644 debian/installed-marker debian/daemon/usr/share/dnsmasq
>   install -m 644 debian/default debian/daemon/etc/default/dnsmasq
>   install -m 644 dnsmasq.conf.example debian/daemon/etc/dnsmasq.conf
>   install -m 644 debian/readme.dnsmasq.d 
> debian/daemon/etc/dnsmasq.d/README
> only in patch2:
> unchanged:
> --- dnsmasq-2.76.orig/debian/installed-marker
> +++ dnsmasq-2.76/debian/installed-marker
> @@ -0,0 +1,2 @@
> +# This file indicates dnsmasq (and not just dnsmasq-base) is installed.
> +# It is an implementation detail of the dnsmasq init script.
> 

Bug#819856: dnsmasq: removing /etc/dnsmasq.d/README prevents dnsmasw from starting

[Simon Kelley]

On 04/04/16 17:13, Thilo Six wrote:
> Simon Kelley schrieb/wrote:
>>
>> The following code in /etc/init.d/dnsmasq is responsible for this
>> behaviour.
>>
>> # /etc/dnsmasq.d/README is a non-conffile installed by the dnsmasq
>> package.
>> # Should the dnsmasq package be removed, the following test ensures that
>> # the daemon is no longer started, even if the dnsmasq-base package is
>> # still in place.
>> test -e /etc/dnsmasq.d/README || exit 0
> 
> for the purpose you described this line can be dropped completely IMHO.
> The following line in the init script already has:
> 
> test -x $DAEMON || exit 0
> 
> so when the dnsmasq package is removed but not purged the init script already
> exits zero.
> 
> 
> 
> kind regards,
> 
>  Thilo
> 

It's not that simple, unfortunately. There are actually _two_ dnsmasq
packages, dnsmasq, and dnsmasq-base. Dnsmasq-base provides the binary
and documentation, and is depended on by various things like
networkmanager. The dnsmasq package provides the system-started daemon.

The problem that this code is trying to solve is the case when both
packages are installed, then just dnsmasq is removed. At this point
dnsmasq should not be started at boot time, but the binary still exists
(since dnsmasq-base is still installed.)

That explains why the code looks at /etc/dnsmasq.d/README since that's
installed by the dnsmasq package and isn't a conffile. SO when the
dnsmasq package is removed /etc/dnsmasq.d/README is removed.

Any suggestions for a cleaner approach gratefully accepted..



Cheers,

Simon.



0xE19135A2.asc
Description: application/pgp-keys

Bug#819856: dnsmasq: removing /etc/dnsmasq.d/README prevents dnsmasw from starting

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


The following code in /etc/init.d/dnsmasq is responsible for this
behaviour.

# /etc/dnsmasq.d/README is a non-conffile installed by the dnsmasq
package.
# Should the dnsmasq package be removed, the following test ensures that
# the daemon is no longer started, even if the dnsmasq-base package is
# still in place.
test -e /etc/dnsmasq.d/README || exit 0

The reason it's there is to stop the dnsmasq-base package from
automatically starting dnsmasq if it has been removed. The binary for
the daemon in in another package (dnsmasq-base) and
/etc/init.d/dnsmasq is a conffile so will not be removed when the
dnsmasq package is removed.

Maybe there should be a comment in the file to this effect, or even
another file should be used.


Cheers,

Simon.




On 03/04/16 07:22, Thilo Six wrote:
> Package: dnsmasq Version: 2.75-1 Severity: normal
> 
> Hello Simon,
> 
> by mistake i found that removing the file /etc/dnsmasq.d/README
> prevents dnsmasq from starting. systemd says rough vaguely: -<
> -< -< -< -< -< -< -< -< -< Job
> for dnsmasq.service failed because a configured resource limit was
> exceeded. See "systemctl status dnsmasq.service" and "journalctl
> -xe" for details. -< -< -< -< -< -< -<
> -< -< -<
> 
> touching /etc/dnsmasq.d/README then and all is fine again.
> 
> 
> 
> kind regards,
> 
> Thilo
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJXAolaAAoJEBXN2mrhkTWiKkYP/i9PuGtkQ5FIaxBG10f5U2dO
K+YGbLC8G23yZeve04MKpUx0g07Sn1+kNiEgpbIFw5ozmYywrrjF7bdM5YjQMlh4
YS5Zgkfj3yg7yj0bWh+UznPvHf8Xu3SzUrlpax3Sfd7GtmnT6ENNUegKsp5CE1nG
jRgdTf72ZVTq63W/ga3FnQPJHO0+KHbWKVvUf8X7S0peRfCsH3M+ODwRCcRvHAJx
qz6qUHuMYpySVS/A/0PJFMAtuQTYaNEcI3A1thMpPfLV6hmYmzQwIsnAP0xOpL2Z
sCtCQiv85QfroU2CJArpGLu6WfDd3ip4rn0/VIm4hbWWCNHbk0XtMbV/P3yRYIxW
fQfeohpNhtQznkcsF6jMPN+a1WUq6XwX7X0KW70UEybAPmmIR8uphWRyG1UtwfHI
Jf2Im6Nx5e8nRlUJ3NHOXhJId9U4nqTYzDUwYwm4e5IiH9WGTKlKSi7zNmjVjOQO
pslHAn6UYZB1iM7PlNyC6M8z5kK0Je77lnZoFpBJJ80WmsbYhq7vwFCFhg5V06R/
h2XK5XvO5N75d+zZ7AmEKpb13LVXhj+eonTRvDdXaY2Nsm85T5HH+/NY6K0oVNuA
tqjG4QkYJ8zqO9xo7djHajKCc08Wqy/aFDAf5YvfR5Kz33o1ZWydw/x8bC8IUOzG
+rwEo3c7Hn20gNkNhPj/
=7TPW
-END PGP SIGNATURE-

Bug#805596: dnsmasq: Fails to resolve cloudflare.com domains with dnssec

[Simon Kelley]

I suspect that the proximate cause of this is lack of support for the
ECDSA ciphersuite in 2.72. As you pointed out, this works OK in 2.75.

2.72 was a very early release for DNSSEC in dnsmasq, and there have been
many changes and fixes between 2.72 and 2.75. Backporting so many
changes is not really practical, so I guess the only solutions are to
use backports, or move stable to 2.75. I'm not sure how the later fits
with policy these days.


Cheers,

Simon.



On 19/11/15 22:17, Norbert Summer wrote:
> Package: dnsmasq
> Version: 2.72-3+deb8u1
> Severity: normal
> 
> Dear Maintainer,
> 
> Since cloudflare.com changed to dnssec dnsmasq can't resolve any domain
> which is hosted by them.
> I can easyly reproduce this issue if I create a blank debian jessie (I
> used docker), install dnsmasq and enable dnssec as in the changed config
> file attached. As parent dns server I used 8.8.8.8, I also try other
> servers but always the same issue.
> 
> If I use now dig I get an empty response.
> With nslookup I get the follow error:
>   ** server can't find cloudflare.com: SERVFAIL
> 
> In the docker container I can resolve the problem with a update to the
> newer version of dnsmasq from stretch. But I think it should also get
> fixed in the stable release.
> 
> 
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.utf8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages dnsmasq depends on:
> ii  dnsmasq-base 2.72-3+deb8u1
> ii  init-system-helpers  1.22
> ii  netbase  5.3
> 
> dnsmasq recommends no packages.
> 
> Versions of packages dnsmasq suggests:
> pn  resolvconf  
> 
> -- Configuration Files:
> /etc/dnsmasq.conf changed:
> conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
> dnssec
> resolv-file=/etc/resolv.dnsmasq.conf
> 
> 
> -- no debconf information
> 

Bug#798981: dnsmasq: dhcp offers not accepted by client

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

A quick Google found this:


http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynam
ic-ports/

which appears to be relevant.

AFAIK dnsmasq doesn't explicitly store the MAC address of the
interface on which it's listening, but the MAC address will appear in
ARP entries, so there's a possibility of a mismatch there. It might be
worth following the procedure in that link and nailing the MAC address
of the bridge, to see if that helps.

Another possibility is this:

Sep 14 22:29:05 learner dnsmasq-dhcp[1556]: DHCP, sockets bound
exclusively to interface lxcbr0

Which tells you that dnsmasq called the sockopt SO_BINDTODEVICE on the
socket used for DHCP. It's possible that the identify of the interface
is changing enough to affect that. An easy test for this theory is to
remove

bind-interfaces

from your dnsmasq configuration.



Cheers,

Simon.



On 27/09/15 10:58, Ritesh Raj Sarraf wrote:
> On Sat, 2015-09-26 at 22:08 +0100, Simon Kelley wrote:
>> It's a fairly tall order to reproduce this, but I have one idea.
>> What is the MAC address associated with lxcbr0? Is it possible
>> that that is changing as a result of the suspend/resume cycle?
> 
> Hello Simon,
> 
> Thanks for the pointer. I never had paid attention to the MAC.
> 
> So when nothing is in use, the status of the bridge interface is:
> 
> rrs@learner:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc 
> noqueue state UNKNOWN group default link/loopback
> 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host
> lo valid_lft forever preferred_lft forever inet6 ::1/128 scope
> host
> 
> valid_lft forever preferred_lft forever 2: wlan0: 
> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group 
> default qlen 1000 link/ether 2c:33:7a:8e:d6:2f brd
> ff:ff:ff:ff:ff:ff
> 
> inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic wlan0
> 
> valid_lft 6618sec preferred_lft 6618sec inet6 
> fe80::2e33:7aff:fe8e:d62f/64 scope link valid_lft forever 
> preferred_lft forever 3: lxcbr0:
> <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state
> DOWN group default link/ether 00:00:00:00:00:00 brd
> ff:ff:ff:ff:ff:ff inet 172.16.10.1/16 brd 172.16.255.255 scope
> global lxcbr0 valid_lft forever preferred_lft forever inet6
> fe80::20d8:7aff:fe71:53a5/64 scope link
> 
> valid_lft forever preferred_lft forever 2015-09-27 / 15:23:22 ♒♒♒ ☺
> 
> 
> 
> 
> And interestingly, based on which VM / Container starts, the bridge
> interface gets a matching MAC address.
> 
> When booting a Fedora Container:
> 
> rrs@learner:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc
> noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00
> brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft
> forever preferred_lft forever inet6 ::1/128 scope host valid_lft
> forever preferred_lft forever 2: wlan0:
> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
> default qlen 1000 link/ether 2c:33:7a:8e:d6:2f brd
> ff:ff:ff:ff:ff:ff inet 192.168.1.100/24 brd 192.168.1.255 scope
> global dynamic wlan0 valid_lft 6730sec preferred_lft 6730sec inet6
> fe80::2e33:7aff:fe8e:d62f/64 scope link valid_lft forever
> preferred_lft forever 3: lxcbr0:
> <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state
> DOWN group default link/ether e2:29:b7:8d:a0:4e brd
> ff:ff:ff:ff:ff:ff inet 172.16.10.1/16 brd 172.16.255.255 scope
> global lxcbr0 valid_lft forever preferred_lft forever inet6
> fe80::20d8:7aff:fe71:53a5/64 scope link valid_lft forever
> preferred_lft forever 6: vb-fedoraTempl@if2:
> <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
> master lxcbr0 state LOWERLAYERDOWN group default qlen 1000 
> link/ether e2:29:b7:8d:a0:4e brd ff:ff:ff:ff:ff:ff link-netnsid 0 
> 2015-09-27 / 15:21:30 ♒♒♒  ☺
> 
> 
> When booting a Debian container.
> 
> 
> rrs@learner:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc
> noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00
> brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft
> forever preferred_lft forever inet6 ::1/128 scope host valid_lft
> forever preferred_lft forever 2: wlan0:
> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
> default qlen 1000 link/ether 2c:33:7a:8e:d6:2f brd
> ff:ff:ff:ff:ff:ff inet 192.168.1.100/24 brd 192.168.1.255 scope
> global dynamic wlan0 valid_lft 6596sec preferred_lft 6596sec inet6
> fe80::2e33:7aff:fe8e:d62f/64 scope link valid_lft forever
> preferred_lft forever 3: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP>
> mtu 1500 qdisc noqueue state UP group default link/ether
> 96:07:08:fd:b1:af brd ff:ff:ff:

Bug#798981: dnsmasq: dhcp offers not accepted by client

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It's a fairly tall order to reproduce this, but I have one idea. What
is the MAC address associated with lxcbr0? Is it possible that that is
changing as a result of the suspend/resume cycle?


Cheers,

Simon.



On 14/09/15 18:17, Ritesh Raj Sarraf wrote:
> Package: dnsmasq Version: 2.75-1 Severity: normal
> 
> Please forgive my vague title. It is a bug that has been hitting me
> for some time, but since I had a work around, I never reported it.
> But doing now. I hope I can explain it.
> 
> 
> 
> rrs@learner:/media/SSHD/rrs-home/devel/config_validator (master)$
> cat /etc/network/interfaces.d/lxcbr0.conf # This bridge will is
> used to NAT LXC containers' traffic auto lxcbr0 iface lxcbr0 inet
> static #bridge_stp off address 172.16.10.1 netmask 255.255.0.0 #up
> ip link set dev lxcbr0 up #down ip link set dev lxcbr0 down pre-up
> brctl addbr lxcbr0 post-down brctl delbr lxcbr0 post-down echo 0 >
> /proc/sys/net/ipv4/ip_forward post-down echo 0 >
> /proc/sys/net/ipv6/conf/all/forwarding post-up echo 1 >
> /proc/sys/net/ipv4/ip_forward post-up echo 1 >
> /proc/sys/net/ipv6/conf/all/forwarding #post-up iptables -A
> POSTROUTING -t nat -s 172.16.10.1/16 -j MASQUERADE #pre-down
> iptables -D POSTROUTING -t nat -s 172.16.10.1/16 -j MASQUERADE 
> #post-up iptables -A FORWARD -i lxcbr0 -s 172.16.10.1/16 -j ACCEPT 
> #pre-down iptablesudo dnsmasq -d -p 5353 -r
> /path/to/resolv-file.dnsmasq  --all-serverss -D FORWARD -i lxcbr0
> -s 172.16.10.1/16 -j ACCEPT # add checksum so that dhclient does
> not complain. # udp packets staying on the same host never have a
> checksum filled else post-up iptables -A POSTROUTING -t mangle -p
> udp --dport bootpc -s 172.16.0.0/16 -j CHECKSUM --checksum-fill 
> pre-down iptables -D POSTROUTING -t mangle -p udp --dport bootpc -s
> 172.16.0.0/16 -j CHECKSUM --checksum-fill 2015-09-14 / 22:35:20 ♒♒♒
> ☺
> 
> 
> This is what my bridge interface is. I like it this way, because I
> can instrcut both, Containers and Virtual Machines, to bind to this
> bridge, and then I can focus on all my management on this
> interface. And all the VMs and Containers get to talk to each other
> on the bridge.
> 
> 
> I use dnsmasq to serve the DHCP requests. My settings are as
> defined below:
> 
> rrs@learner:/media/SSHD/rrs-home/devel/config_validator (master)$
> cat /etc/dnsmasq.d/50myLXC # Bind it to the LXC interface 
> interface=lxcbr0 bind-interfaces
> 
> # Want DHCP client FQDN #dhcp-fqdn
> 
> # Domain name and ip range with lease time 
> domain=lxc.local,172.16.10.0/16 
> #dhcp-range=192.168.122.100,192.168.122.200,1h 
> dhcp-range=lxcbr0,172.16.10.10,172.16.10.200,1h
> 
> # DHCP options dhcp-option=40,lxc.local log-dhcp 2015-09-14 /
> 22:37:49 ♒♒♒  ☺
> 
> 
> 
> The name got stuck because I started with configuring it for
> containers, but I use the same setup for the VMs. In VirtualBox,
> for each Guest VM, I choose "Bridged Adapter" as the setting.
> 
> 
> The problem:
> 
> I use my laptopt as usual. Multiple suspends/resumes. And then I
> just fire up a Guest VM. And it timesout in getting a DHCP
> address.
> 
> In the logs, it shows that the DHCP address was offered.
> 
> Sep 14 22:18:54 learner dnsmasq-dhcp[1407]: 1240112453 next server:
> 172.16.10.1 Sep 14 22:18:54 learner dnsmasq-dhcp[1407]: 1240112453
> broadcast response Sep 14 22:18:54 learner dnsmasq-dhcp[1407]:
> 1240112453 sent size:  1 option: 53 message-type  2 Sep 14 22:18:54
> learner dnsmasq-dhcp[1407]: 1240112453 sent size:  4 option: 54
> server-identifier  172.16.10.1 Sep 14 22:18:54 learner
> dnsmasq-dhcp[1407]: 1240112453 sent size:  4 option: 51 lease-time
> 1h Sep 14 22:18:54 learner dnsmasq-dhcp[1407]: 1240112453 sent
> size:  4 option: 58 T1  30m Sep 14 22:18:54 learner
> dnsmasq-dhcp[1407]: 1240112453 sent size:  4 option: 59 T2  52m30s 
> Sep 14 22:18:54 learner dnsmasq-dhcp[1407]: 1240112453 sent size:
> 4 option:  1 netmask  255.255.0.0 Sep 14 22:18:54 learner
> dnsmasq-dhcp[1407]: 1240112453 sent size:  4 option: 28 broadcast
> 172.16.255.255 Sep 14 22:18:54 learner dnsmasq-dhcp[1407]:
> 1240112453 sent size:  4 option:  3 router  172.16.10.1 Sep 14
> 22:18:54 learner dnsmasq-dhcp[1407]: 1240112453 sent size:  4
> option:  6 dns-server  172.16.10.1 Sep 14 22:18:54 learner
> dnsmasq-dhcp[1407]: 1240112453 sent size:  9 option: 15 domain-name
> lxc.local Sep 14 22:18:57 learner dnsmasq-dhcp[1407]: 1240112453
> available DHCP range: 172.16.10.10 -- 172.16.10.200 Sep 14 22:18:57
> learner dnsmasq-dhcp[1407]: 1240112453 client provides name:
> debian Sep 14 22:18:57 learner dnsmasq-dhcp[1407]: 1240112453
> DHCPDISCOVER(lxcbr0) 172.16.10.77 08:00:27:ec:39:96 Sep 14 22:18:57
> learner dnsmasq-dhcp[1407]: 1240112453 tags: lxcbr0 Sep 14 22:18:57
> learner dnsmasq-dhcp[1407]: 1240112453 DHCPOFFER(lxcbr0)
> 172.16.10.77 08:00:27:ec:39:96 Sep 14 22:18:57 learner
> dnsmasq-dhcp[1407]: 1240112453 requested options: 1:netmask,
> 28:broadcast, 2:time-offset, 3:router, Sep 14 

Bug#798653: hosts from hostsdir=/dir/ picked up but not served

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256




> What does not seem to work is that addresses removed from the file
> are removed from the cache immediately. So if I remove the entry
> for sid it will still be served.
> 

That's documented behaviour. New or changed files are read, so extra
information is added, but old information is not removed. Doing that
needs a SIGUSR1 as it's a rather heavyweight operation that involves
deleting everything are re-reading all the relevant files.


Cheers,

Simon.

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

iQIcBAEBCAAGBQJWAHOqAAoJEBXN2mrhkTWiCbcP/1eP2bqhSSkob3BSeuSA7OLM
6wQ8eGdVRiiMysX0+eY2nTDuXyNPM9rjKCXR6R1iLr5/Rf8zU7rvqhgwoAjg8PPM
yt8E9Jke2TeJ4Ju2hZGjzGpwYjWcWmKMpgGISg+Bk5kT/F6Wa5iNoRin8Vsy65Bs
T6DTO8B1yCD8XP2vUwrOgwyw8/vYu6FAhWzDP1TdfF5uDDkZRiovD3j7zrgvb7R9
UVDmBtw8OTWGhlD+/OYqvLyPUJodL0Zl0DAcWzt12WR1y0Syhl0xkLECIdXmWj9+
xcDYkUHdCe3nnzEC2IIWJuc3lu9DQXeNhGmFBeFQZl8tgqInWsjt0iCA5hVR6bM5
H2FAmp/gGQn4zO2pKjIuRjtqvDi6/SZR2h4YUyT5Hvafjrtzz4YHo6/RC+RZTLJC
4FzhuWw5uPTk96YNKNJKzxAAXnAUaf+8i+5EtYX6MVEvCtaCMUWdAQ+Ws5im4thL
ZBRRT3tLVh33Cv+D+XMP9MqLMr2WdCFoyacEkPPE7mKnHzEsOwCCLELgwIuQWNks
9IKfJ8cNEz4QatYTCzJnfhCrjRhCfa05wgXpHZGe+zNDeOXWGKem9IYKXmko8Wef
BnsR4VhtK9qmc45GdIU4KzE/l6km/eb/Ce5EvVvTKAbhTl2zS7+tPz5yQVIhRRpV
Jrq+lv4sczyxaXXDn62k
=8Ksr
-END PGP SIGNATURE-

Bug#798653: hosts from hostsdir=/dir/ picked up but not served

[Simon Kelley]

On 11/09/15 15:54, Guido Günther wrote:
> On Fri, Sep 11, 2015 at 03:57:19PM +0200, Guido Günther wrote:
>> Package: dnsmasq
>> Version: 2.75-1
>> Severity: normal
>>
>> Hi,
>> I just tried your suggestion with --hostdir=/tmp/test. While I see these
>> log messages nicely:
>>
>> Sep 11 15:53:49 foo dnsmasq[14616]: inotify, new or changed file 
>> /tmp/test/libvirt-qemu%3A%2F%2F%2Fsystem.hosts.tmp
>> Sep 11 15:53:49 foo dnsmasq[14616]: read 
>> /tmp/test/libvirt-qemu%3A%2F%2F%2Fsystem.hosts.tmp - 3 addresses
>> Sep 11 15:53:49 foo dnsmasq[14616]: inotify, new or changed file 
>> /tmp/test/libvirt-qemu%3A%2F%2F%2Fsystem.hosts
>> Sep 11 15:53:49 foo dnsmasq[14616]: read 
>> /tmp/test/libvirt-qemu%3A%2F%2F%2Fsystem.hosts - 3 addresses
>>
>> these addresses are _only_ being served if they are already present in
>> the file during daemon start. New entries are not being served. Note
>> that my program writes to a .tmp first and then does a rename so this
>> might confuse dnsmasq (and I can't use s.th. like:
> 
> Even when I skip the writing to .tmp file step dnsmasq does only server
> entries that are present in the file at startup.
> 
> A SIGHUP also lets the daemon server the entries from the hostdir.
> 
> Cheers,
>  -- Guido
> 

Ok, a trivial attempt to reproduce this fails for me. I create a new
file in the directory with a new name in it and I can immediately look
up the new name. What is in your hosts file? Are the names or addresses
re-used?

I would be interesting to set --log-queries, and to look at the cache
dump created in the log by sending SIGUSR1.


Cheers,

Simon.

Bug#798586: dnsmasq --no-resolv fails if /etc/resolv.conf is a symbolic link pointing to a file in a nonexistent directory

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/09/15 20:35, Alexander Kurtz wrote:
> Package: dnsmasq Version: 2.75-1
Thanks, I just pushed the fix upstream, it will be in the next release.



Cheers,

Simon.

> 
> Hi,
> 
> dnsmasq(8) says ...
> 
> -R, --no-resolv Don't  read /etc/resolv.conf. Get upstream servers
> only from the command line or the dnsmasq configuration file.
> 
> ... yet dnsmasq still fails to start if /etc/resolv.conf is a
> symbolic link pointing to a file in a nonexistent directory:
> 
> # ln --symbolic --force /nonexistent/foobar /etc/resolv.conf #
> dnsmasq --conf-file=/dev/null --no-resolv
> 
> dnsmasq: directory /etc/resolv.conf for resolv-file is missing,
> cannot poll
> 
> This can be worked around by explicitly specifying the list of
> "resolv" -files to be empty:
> 
> # dnsmasq --conf-file=/dev/null --no-resolv --resolv-file= # echo
> $? 0
> 
> This is problematic because when running systemd-resolved it's 
> recommended to make /etc/resolv.conf a symbolic link to 
> /run/systemd/resolve/resolv.conf for compatibility reasons (see
> systemd -resolved(8)). Since dnsmasq.service has no dependency or
> ordering relation on systemd-resolved.service (which is of course
> correct), it's possible for /etc/resolv.conf to be a symbolic link
> pointing to a file in a nonexistent directory when dnsmasq starts.
> 
> Best regards
> 
> Alexander Kurtz
> 

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

iQIcBAEBCAAGBQJV8f+wAAoJEBXN2mrhkTWixvsP/1C+iKtjtjwI8QU05yiPYHRK
U0mRnFGYm0wlChwgALa8ABYs56/ejoVB+lsCZ5dJeCdpgxg14bZ4wUrPJTkjJl+e
7fSC4jv5sDx1YwEOZk4r0Hc6i9V8CAIXnUwMXk/kTuc5UJ+r8SDSbPh230g5y7XS
xpsEtKOpOSodogUwWyGl1SInjFC0NdbZNAUpHCXUhzY3UN8IBHKz6+1lAMMkjK4X
hxpN8RxdQbCiNFhbWLixJE8/dYMjnJSOYA1riKDzsoD+clCzYXAK2Mis4Sl0/0Yn
Uluobd9ExkQS3Bp5Nz0DkqiNOmmma+U4QCzyUMrGiDvy6LPn97KlNvYeGEnFGLoX
M9sZtvFq1q06WPzqiuanj7510X1jgHaFA9a5fxfQbShzxd8oxlBS/lL0kCh04qdC
kXQcNkC1beCIejMUQBY7OaVsI8tH3HYlIVBVzAJbj1AGdAtWL/gUpj/Yfwomwvra
FnC3iRGqPKZSDxmuBQ01VdkcHmoLdS2llIwPxeahrW7E3NXN5sLCf94ceeHosolg
LAOYQSb5OYPK6hd0GYBMOUPx+SCFH7uUCuO6Bca3RmmWcD9ushbdqPodXgX1VNLX
TtplvkHU812BKdXRxyqTK93EjjzVE4xitY96dxNMima/JPKPgHRe/Xi2ErzeDvLj
umKO3hZSFbe5+z1kMelc
=YF0e
-END PGP SIGNATURE-

Bug#798093: Please allow to inotify monitor addn-hosts dirs

[Simon Kelley]

On 05/09/15 15:42, Guido Günther wrote:
> Package: dnsmasq
> Version: 2.72-3+deb8u1
> Severity: wishlist
> 
> Hi,
> it would be awesome if dnsmasq could use inotify in case of
> 
> --addn-hosts=/a/directory/
> 
> this would allow one to dump new files in there (and modify existing
> ones) without reloading dnsmasq. The use case is creating hosts entries
> for VMs popping up (and disappearing) on the network.
> Cheers,
>  -- Guido
> 

Note that this functionality is included, as

--hostsdir=/a/directory/

in version 2.73 and later. It's added as a new option so as not to
change the behaviour (re-read on SIGHUP) of --addn-hosts.


Cheers,

Simon.

Bug#798093: Please allow to inotify monitor addn-hosts dirs

[Simon Kelley]

On 05/09/15 15:42, Guido Günther wrote:
> Package: dnsmasq
> Version: 2.72-3+deb8u1
> Severity: wishlist
> 
> Hi,
> it would be awesome if dnsmasq could use inotify in case of
> 
> --addn-hosts=/a/directory/
> 
> this would allow one to dump new files in there (and modify existing
> ones) without reloading dnsmasq. The use case is creating hosts entries
> for VMs popping up (and disappearing) on the network.
> Cheers,
>  -- Guido
> 

The policy in the past has been to re-load /etc/resolv.conf and friends
automatically when they change, as systems which re-write resolv.conf
tend to assume that's all that needs to happen. For other configuration,
(including addn-hosts) sending SIGHUP to the dnsmasq process causes a
re-read. This is more conventional, and safer from race conditions, for
instance reading a file before it has been completely written.


Is there a good reason not to use SIGHUP in this case?


Cheers,

Simon.

Bug#794642: dnsmasq: pick one of the conf-dir directives and un-comment it, please

[Simon Kelley]

The Debian package provides a directory, /etc/dnsmasq.d for config file
fragments. This is automagically enabled with a command-line argument
provided by the init-system start script, without the need to include is
in /etc/dnsmasq.conf

This is documented in para 2 of /usr/shar/doc/dnsmasq/README.Debian

Cheers,

Simon.



On 05/08/15 11:12, Rick Thomas wrote:
 Package: dnsmasq
 Version: 2.72-3+deb8u1
 Severity: wishlist
 
 Dear Maintainer,
 
 The default /etc/dnsmasq.conf file, toward the end of the file, suggests 
 several options
 for allowing local drop-in configurations without changing the dnsmasq.conf 
 file itself.
 But they are all commented out.  If one of them were enabled, it would not be 
 ironically
 necessary to modify /etc/dnsmasq.conf in order to avoid modifying 
 /etc/dnsmasq.conf .
 
 My personal preference would be to activate the last option (once the syntax
 error in it is corrected -- swap the last / for a ,)  I.E.
 
   conf-dir=/etc/dnsmasq.d,*.conf
 
 But nearly anything would be better than nothing.
 
 -- System Information:
 Debian Release: 8.1
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
 'stable'), (500, 'oldstable')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)
 
 Versions of packages dnsmasq depends on:
 ii  dnsmasq-base 2.72-3+deb8u1
 ii  init-system-helpers  1.22
 ii  netbase  5.3
 
 dnsmasq recommends no packages.
 
 Versions of packages dnsmasq suggests:
 pn  resolvconf  none
 
 -- Configuration Files:
 /etc/dbus-1/system.d/dnsmasq.conf 9a18c8a761c2262dbf0c8b3345a85242 [Errno 2] 
 No such file or directory: u'/etc/dbus-1/system.d/dnsmasq.conf 
 9a18c8a761c2262dbf0c8b3345a85242'
 /etc/dnsmasq.conf changed:
 conf-dir=/etc/dnsmasq.d
 
 
 -- no debconf information
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#790341: [Pkg-utopia-maintainers] Bug#790341: network-manager: [regression] change in dnsmasq has broken connection sharing support

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is indeed a dnsmasq bug, introduced in 2.73. My fault, sorry.
Insufficient scrutiny of a clean-up patch. I just committed a fix to
the git repo.

Cheers,

Simon.


On 28/06/15 17:27, Michael Biebl wrote:
 Hi Paul,
 
 thanks for your bug report.
 
 Am 28.06.2015 um 10:23 schrieb Paul Wise:
 Package: network-manager Version: 1.0.2-2 Severity: important 
 Tags: patch
 
 I sometimes share my WiFi connection to the Internet via
 Ethernet. A recent upgrade of dnsmasq-base (I think 2.72-3.1+b1
 to 2.73-1) on my system broke this as dnsmasq now tries to read
 /etc/dnsmasq.conf when --conf-file is given without any argument,
 with only dnsmasq-base, this file is not present. The fix is to
 make it read /dev/null instead. I verified that that works by
 diverting the dnsmasq binary and replacing the --conf-file
 argument with a --conf-file=/dev/null argument.
 
 src/dnsmasq-manager/nm-dnsmasq-manager.c:245 -
 nm_cmd_line_add_string (cmd, --conf-file); +
 nm_cmd_line_add_string (cmd, --conf-file=/dev/null);
 
 I can't find anything in dnsmasq's changelog for 2.73 in that
 regard. To me that looks like a regression in dnsmasq and should
 probably be fixed there.
 
 I've CCed the dnsmasq maintainer, maybe he can comment on this.
 
 If the current usage of --conf-file with an empty parameter was
 not officially supported and only working by accident, then this is
 indeed something which needs adjustments in NM, otherwise this bug
 report should be re-assigned to dnsmasq.
 
 Regards, Michael
 
 
 Jun 28 16:04:19 chianamo NetworkManager[844]: info  Starting
 dnsmasq... Jun 28 16:04:19 chianamo NetworkManager[844]: info
 (eth0): device state change: ip-config - ip-check (reason
 'none') [70 80 0] Jun 28 16:04:19 chianamo NetworkManager[844]:
 info  (eth0): Activation: Stage 5 of 5 (IPv4 Commit) complete. 
 Jun 28 16:04:19 chianamo NetworkManager[844]: dnsmasq --conf-file
 --no-hosts --keep-in-foreground --bind-interfaces
 --except-interface=lo --clear-on-reload --strict-order
 --listen-address=10.42.0.1
 --dhcp-range=10.42.0.10,10.42.0.254,60m
 --dhcp-option=option:router,10.42.0.1 --dhcp-lease-max=50
 --pid-file=/var/run/nm-dnsmasq-eth0.pid Jun 28 16:04:19 chianamo
 NetworkManager[844]: info  (eth0): device state change:
 ip-check - secondaries (reason 'none') [80 90 0] Jun 28 16:04:19
 chianamo NetworkManager[844]: info  (eth0): device state
 change: secondaries - activated (reason 'none') [90 100 0] Jun
 28 16:04:19 chianamo NetworkManager[844]: dnsmasq: cannot read
 /etc/dnsmasq.conf: No such file or directory
 
 
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVmZswAAoJEBXN2mrhkTWiGZUP+gNhjaPO0VHmNBlC+5JiB0fP
KHtlk21e60W22D6MDuii1R2PrJ3BFqkpvV3ysGG+W4Ida8FwvfztL5nLErUBrtdo
+JORheLuWiac2dc87AX0c/vf8auNtMZhoO+iblrTAh6FM3UbLcCUEB6mlWjwHazY
Y6l5brv5HMtY35JMFMoxSEwZhGVkG79lwB13fZmifLLvNDqAad5VE5xnG22uPjAw
+zjzAcBmZqPNfRtFSuBrI0lur5HgujEJa6zRGveONDBrlvI6VdB5PCRa/dWCVO+O
+2pxOOXIl4+5yBufmolkWj7BraUq0nU3MEGe9fIT671LOYW6ngpI83ICxJMyHeUf
QP4bhkV7DCcnKeiSADMtFxQKrMl0xbKyQCY7Ou4/us0BOkhffHpQGQKzcGmuFmwH
dCpuSTT4MzgkPJ7exwZ+uJTmZ+Skjm7/1F6KUsIz5QWzKhGjN1oYq/wUSFrQaIQD
FPh96kdNa7LRGn4egQDq5P+iQK1A5HJ20tlLAWnVjRQlDwlif4c4bA2RL9IVjafI
cmxuCgsk4c6J+4559LLGav97U2BqU5uSJ8VBd2IHOZMtUvxtC9wZ6VbJ7KexveXS
eL8WsW6RKDb0nTZiAJlTWvuwOzCSAClccHeExotTroOLCZ55xdwKqAKoAb0UOMPO
9qhlqNb7A4Yf8lqeDFtS
=2E+b
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683372: squeeze update of dnsmasq?

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 16/05/15 11:26, Santiago Ruano Rincón wrote:
 Hi Simon,
 
 On Fri, May 15, 2015 at 04:24:30PM +0200, Santiago Ruano Rincón
 wrote: ...
 I'm attaching the clean patch to fix CVE-2015-3294.
 
 These other CVEs are related each other and still affect dnsmasq
 in squeeze and wheeze: 
 https://security-tracker.debian.org/tracker/CVE-2012-3411 
 https://security-tracker.debian.org/tracker/CVE-2013-0198
 
 As far as I understand, your fix to those bugs introduces the new 
 --bind-dynamic option in dnsmasq. This fix also depends on libvirt,
 that needs to be modified to pass --bind-dynamic instead of 
 --bind-interfaces. Please, correct me if I'm wrong.
 
 Given that in Debian they have been classified as low priority, do
 you think it's worth to do adapt those changes into squeeze and
 wheeze?
 

Your analysis is correct, and I think it's really not worth the
(large) amount of effort required.

Cheers,

Simon.


 Best regards,
 
 Santiago
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVV3vXAAoJEBXN2mrhkTWiKbQP/2mGC4ewKPjkdllfHaJOqhbE
eycI8mmdVCoyUHGrOOMi6yp985vG7S5tlePsZBTW5INOtSjtq16yqAhwUoy5cjdc
ax1K7iD5qoaQahNj5vlLCZ0/M/y0x452J6vlkjUlkNDnC76RKQrnjZpcoG83NMiK
tfb4rr6W6zuUObTO5U73y4lcM4gMMUp8YRUL9ibtpaBVaW/eCRBBc/i7sOaVTRCG
dKdBRh/XgcNo9a/gBAVYBiu6DeBxpBIHt16fXyoSJ/UzyvXpBO4jWUsmmIlZRw9j
t/lcqL0SQRRRUk2ATyZOSYb7pNgv7RstG7JaXRlSsrKK105xPkUOIvpoDoYyfbxU
/Nq+t4vokzIYLDFIDZO+LZ5qffqAMJEi+zHCWtqXo5CKiTnwDjUtuDu21v5Pz/wB
MQz2gNZfxiOmZoV2mgVwj7Hy471MHKP308pOe3jRfH/L09jwCAh/zFklKvjFA6/+
HfzOgziATtUO6rxWLDMd0FH6C0IINjsUP2EUtrG0ztEHkTg21OPzkHY4H5FUpKUb
YekWLEPBsFuWPkQfAIZlzF8cGvFL67MmWMY5C0Kpy71BDfvemC4GpHaZm9Eb7oN2
L8CuaqEWPH6vLDNGMa1NtCCl+nsOKW8U2x6rnimMV/+MaZsoe2Z19kIrP8WtmgJH
EhgXBERF1nfrU/4yQWJ6
=XVyZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783459: dnsmasq: Wheezy regression caused by CVE-2015-3294/2.62-3+deb7u2 w/ bind-interfaces

[Simon Kelley]

Salvatore.

The problem occurs if the dnsmasq binary is compiled against libc
headers which #define SO_REUSEPORT and then run on a kernel which
doesn't support that option. I guess the security builds have picked up
SO_REUSEPORT from a libc backport.

The fix applied at the time was:

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


Cheers,

Simon.



On 06/05/15 15:16, Salvatore Bonaccorso wrote:
 Hi Ian and Luca,
 
 On Wed, May 06, 2015 at 12:59:03PM +0200, Luca Olivetti wrote:
 On Wed, 06 May 2015 11:30:35 +0100 Ian Campbell i...@debian.org wrote:


 I've just noticed that running kernel on the machine is 3.2.57-3+deb7u1
 which is quite out of date wrt point releases etc. Looking at the
 changelog there have been dozens of stable update fixes, one of which
 might be relevant here.

 I'll reboot when I get home and see if perhaps that fixes the issue.

 I have the same problem, but my machine uses 3.2.68:


 #uname 
 -ahttp://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=56a1142f033234e3ee3b6361e9a1bcdbe606f816
 Linux lacie 3.2.0-4-kirkwood #1 Debian 3.2.68-1+deb7u1 armv5tel GNU/Linux


 I had to comment the bind-interfaces line from /etc/dnsmasq.conf in
 order to make it start.
 
 Thanks to both for feedback. Might it be a problem with the armel
 build?  If you look at the build log (which I have uploaded to [1]) on
 the armel chroot to build the package on the buildd there installed
 linux-libc-dev which is not from stable but from backports, and indeed
 for linux = 3.9. Thus the armel build will have (dhcp.c):
 
 [...]
   int rc = setsockopt(fd, 1, 15, oneopt, sizeof(oneopt));
 
   if (rc == -1)
  die(dcgettext (((void *)0), failed to set SO_REUSE{ADDR|PORT} on DHCP 
 socket: %s, __LC_MESSAGES), ((void *)0), 2);
 }
 [...]
 
 Could either of you try to rebuild dnsmasq in a clean chroot and see
 if the problem resolves? That the buildd have 3.14.13-2~bpo70+1
 installed is odd and should not be.
 
  [1] 
 https://people.debian.org/~carnil/tmp/dnsmasq/dnsmasq_2.62-3+deb7u2_armel-20150505-1143.gz
  [2] https://lwn.net/Articles/542629/
 
 Regards,
 Salvatore
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783459: dnsmasq: diff for NMU version 2.72-3.1

[Simon Kelley]

On 05/05/15 15:15, Salvatore Bonaccorso wrote:
 Control: tags 783459 + pending
 
 Hi Simon,
 
 I've prepared an NMU for dnsmasq (versioned as 2.72-3.1) and
 uploaded it to DELAYED/5. Please feel free to tell me if I
 should delay it longer.
 
 Regards,
 Salvatore
 

That looks fine, thanks for doing this. I replied separately to the
REUSEPORT bug in oldstable, with a solution.


Cheers,

Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776530: dnsmasq: fails to start when dbus is not installed and running systemd

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 10/02/15 09:17, Simon McVittie wrote:
 On Mon, 09 Feb 2015 at 16:33:31 +, Simon McVittie wrote:
 If I was the maintainer, I'd go for option 2, Type=forking, which
 makes the systemd unit work even more like the init script does
 now - signalling readiness via the parent process exiting. I'll
 look into doing a patch at some point.
 
 See attached. Tested successfully in a jessie 'standard' virtual
 machine with and without dbus.
 

Thanks, that looks good, but I think that probably the default
- --enable-dbus should go as well. It's only there for the previous use
with systemd's dbus method. DBus is not enabled by default when
dnsmasq is started by sysvinit.

I'll make a patch with that too. Are you happy if I upload it rather
than your NMU, to save you grief with my mangled config files :)


Cheers,

Simon.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJU28khAAoJEBXN2mrhkTWirxsP/1Qb8ZZlbx999z1BKKR8OWp6
Gv0/GXWIRYf+1SeIcLio+ukMCl+EhNVgWrtCasbCDBkav1INqOAX7b0StI6Ubeig
SPQtLyaus0NypY1t7vo97nt7y3D3DMYaERqRoKn+gFBbwozMRnDQZ0xdG1OKIxiP
uKz/c4yQ4QfN+YJDGV3gaR7F53pURjs7kyIyFs/8uERMdDQZ55HC+R2YOQEP7Ob4
WfivYrZF+yUwIrYpWhzQSc1HnfynEP8mgBwYTIXpqhz5mLyR6iAJ7vswG2Dbteq8
FuGb83UK9+uGpeYnGbvSZbAhBJNVXnKRvZXNrIHg8+qZWjCRFMJgBJzdkPlLOh+Z
3IhwS3hXqeneyen7ucK/yJWBLw46s3bz2qMXBQaPWvNnzYI8zHUk3GcQubZRYmeW
tM2511Ukhh+4PF/c5PqqSk/lw5ji2ERVYz5GVFgK1ZtHj3ypScjHPqnoVtZMIkad
zSzETJwHWhjVjGk9zjEZHOnd1wbiPSMOPJGyYwbjM0VTtCKnJpb/zgtEE3ny1wPT
nUP9w1bqtQO2cbrjwtTVDpqQ89iceXfru9CvUP0yyacnETvkajtYmESe6Trd6FQY
6WVHFyIDfcvI5SkzRbVmGVmfH16rCq6B/kZVN/NkaKV3jgLs5mrO+WEKXAN1K23u
LixgpogYIuSW0AH43ruB
=qjNN
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776530: dnsmasq: fails to start when dbus is not installed and running systemd

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 11/02/15 21:56, Simon McVittie wrote:
 On 11/02/15 21:26, Simon Kelley wrote:
 Thanks, that looks good, but I think that probably the default 
 --enable-dbus should go as well. It's only there for the previous
 use with systemd's dbus method. DBus is not enabled by default
 when dnsmasq is started by sysvinit.
 
 I wondered about this, but I was a little concerned that it would
 be a regression for any systemd users who are currently
 remote-controlling dnsmasq via D-Bus without having specifically
 enabled it.
If it was also enabled when sysvinit was in use, I'd agree, but a
system which is working as a side-effect of using systemd probably
should be fixed, so it will work with sysvinit too.


 
 Given that a D-Bus-enabled dnsmasq seems to cope equally gracefully
 with dbus present or absent, is there a cost to enabling it?
 

There is. Dnsmasq will poll, attempting to create a connection, so
there's some CPU cost.


 I'll make a patch with that too. Are you happy if I upload it
 rather than your NMU, to save you grief with my mangled config
 files :)
 
 Upload whatever you prefer. I mainly prepared my patch in the form
 of an NMU so I wouldn't have to rebuild and re-test if you asked me
 to NMU it later.
 
 S
 

OK. My sid VM is currently updating to allow the test. Will upload soon.


Cheers,

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJU29LrAAoJEBXN2mrhkTWiVwUP/2bDRUk158rS2YoNQqF9BPdm
yPrydm2OMyr+cG5pYQhlcPdXXtVLY1/wd7HAFAbum36tE53APpuSqairdlv/bKRY
bbqyboAqHw04PBqKNJnwkhGuOjXQrkySMXV/tu2CDZjZ+xqGtgB2Nwy+xJKPUpp6
vPSU7FPhXEp1Ik2Bv95mWhRaH9erFL44wbYuUKXYuQeU69vE6Zaj8gQZdQNBVdtP
XOzR4pN75HmVEHFjlCSlQAVec0+mAyCUfEjwbT3yd+be0V6fR0ayF9zr82oRtrEX
sZhhXto14BE5qFwjQUrzqwBn30TuCrucmAC847NXeRbt85wNf2vxmqTMTVcs5J2B
u50Fm1AXFPEwWN8VZMyJOxPXcznNtc5DQgyDgG9r7vNIqLDZewONlbZWIyOERtXX
50YH4ajhzZx5VIjLM1TNEo5hvq+snPqULbd8b4/Py57jMSb5zrZkIHhIDao5nHDT
S040YfTXOGNRObJva+YVcQkPnJb8gTEN05D8nrfucEocvECYxonzZg9q8AwalvAl
XAR8cOnRXDGHpTDbMRgBco0u9Il6g/XjRz3KbEnM1MXYD0NorYMjCL8vyLGERFJ3
luQ6NvrpXM+gaLLKIS/QMD9Sjkxt1UZerylGc/oY6VMBvdA6cLtjmPnkh+n/7sV3
ZAb5girZxA6Bp9HqkJoy
=L8Mk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776530: dnsmasq: fails to start when dbus is not installed and running systemd

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Simon.

Many thanks for the offer of help, not having to wade into the
intricacies of systemd is a big win for me.

The current arrangements are something which was made to work without
big code changes so I'm not wedded to using the dbus method at all,
and most installations of dnsmasq won't need dbus, so removing the
compulsory dependency is good. That eliminates option one.

Of two or three, I'm not sure and I'll take your advice. Two needs no
code changes and adds no dependencies, and that's good, but if there
are advantanges to going with three, then I can handle that by making
the libdbus code conditionally compiled.


Cheers,

Simon.




The current code is Som

On 07/02/15 12:08, Simon McVittie wrote:
 On Wed, 28 Jan 2015 at 17:37:38 -0800, Vagrant Cascadian wrote:
 When runnning dnsmasq with systemd on a freshly installed
 system, without dbus installed, dnsmasq fails to start.  It seems
 like dnsmasq should depend or at least recommend dbus if it needs
 dbus in order to function on a default install with systemd. Some
 ugly chain of dbus | sysvinit-core | upstart might also be
 worth entertaining...
 
 There are three ways this could potentially be fixed:
 
 * depend on dbus or optionally dbus | sysvinit-core | upstart 
 (systemd will think dnsmasq is ready when it claims its bus name, 
 as it does now)
 
 * change from Type=dbus to Type=forking, add PIDFile, and stop
 using --keep-in-foreground in '/etc/init.d/dnsmasq systemd-exec' 
 (systemd will think the dnsmasq child process is ready when the 
 parent process exec'd by the init script exits 0, and will 
 determine what the child process is by reading the PIDFile)
 
 * change from Type=dbus to Type=notify, link to libsystemd, and
 call sd_notify(0, READY=1) when ready (systemd will think dnsmasq
 is ready when it does that)
 
 I can put together a patch for one of these options if the dnsmasq
 maintainer is too busy (the first two are easy, the third is
 slightly harder but not rocket science), but I'd like to know which
 one you'd prefer.
 
 S
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJU2NJQAAoJEBXN2mrhkTWiQ2wP/3xrPZKauBip1lrQ+KMcoq+A
kcxyUkG7Culdmk+j6o1YXaqGGL10+hWc9Dc8Qf6keOQmSEwHcjpb/xhAYTk7TK0z
c//339hE+XhtQKMQRh3DlEx47NqAkAqI68/P9XaHmP7VDAmI/ngGmU4MubajW4NL
80D6Z2e0ej/wp3ks/vwcSzDtDg+Z7yI0wYPrGlmq2C2ke2NCpjzllLwPytVq22eM
VSHFxcwVERmiugIe456tMOAzt6Rhsi1rP+I+xDKwM+Pdo4f/Gw5ulS+DR4xc5maz
YQLFfwioGRyl95weltrLE96YKw4Ma/lF2BaXNne+cOYznbQHKGRkBegK05cN6eFQ
tYVa95IXw71/EJkfKQuVftIH7m4xoE/F/Q/Awa4qcVaH4LmzDK8xqVkUkKA73+UX
13kIl5gef3r9SEQoIOwUMiVefPT/uENMLded7C3DhlIX+0xtdI/IFiOQMJ5Momre
oqQ4ykKaa/P1fJxiGfkAfa716PK6oFvfeMYLFuPRCslJoJE5k/5Xpp74HymaSWjr
LlK04Q+t+EsjrWpuU7uGd+Vywb4QI/HOVO5onGyXo0cYiB+jpANvDzkG1sSvzAWx
rTXHYRcte4LkiJswuCOZeUsVXOvdICU4CGRsh4n3tC5y6CbsCT6vqSmKC+pRdFm5
i2THtdMze50+33HfIBZk
=OYQ2
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771631: dnsmasq: Please add ProtectSystem=yes to systemd service file

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There's a potential problem with this: dnsmasq has an option to invoke
child processes when the DHCP lease database changes, using the
- --dhcp-script option. By making this change, those processes are going
to be invoked with read-only /usr. That's probably fine in most cases,
but there's no certainty that someone's script doesn't write /usr, and
for that script, this is a non-backwards compatible change.

Simon.


On 01/12/14 03:51, Micah Anderson wrote:
 Package: dnsmasq Version: 2.72-2 Severity: wishlist
 
 Dear Maintainer,
 
 *** Reporter, please consider answering these questions, where
 appropriate ***
 
 * What led up to the situation? * What exactly did you do (or not
 do) that was effective (or ineffective)? * What was the outcome of
 this action? * What outcome did you expect instead?
 
 *** End of the template - remove these template lines ***
 
 
 Hello,
 
 If you add the option ProtectSystem=yes to the service file, then
 the daemon will not have the ability to write to /usr.
 
 There is no reason why it needs to write there, so enabling this 
 option should not cause any problems.
 
 This option is one of the systemd security features for systemd 
 service files that was detailed in a talk[0] given by Lennart
 which details various security features you can enable in your
 package's service files.
 
 micah
 
 [0]
 http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

  -- System Information: Debian Release: jessie/sid APT prefers
 unstable APT policy: (500, 'unstable') Architecture: amd64
 (x86_64) Foreign Architectures: i386
 
 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale:
 LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell:
 /bin/sh linked to /bin/dash
 
 Versions of packages dnsmasq depends on: ii  dnsmasq-base
 2.72-2 ii  init-system-helpers  1.22 ii  netbase  5.3
 
 dnsmasq recommends no packages.
 
 Versions of packages dnsmasq suggests: ii  resolvconf  1.76
 
 -- Configuration Files: /etc/dnsmasq.conf changed [not included]
 
 -- no debconf information
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUke0OAAoJEBXN2mrhkTWidS0P/j1V/TZLJ5oj0NdN12Gwa2Dr
QEd5ONcLvklrzgCStjbxI9nRF5N6tYVv/zhe5PwoMRGLog2rrOGLF6scMNxrex0a
xD2typI2PBMCUAoP8eV5kagujbmH5E4gIaKGPQKdQmHGAJ1qFS76AYZ/obdtcEOj
gpUL5CNL32h0U9DQsTVIw/vyT0WlZORlMZmjZhIphzw7RE7uxBbw3WZdd4Psl4Iq
3f80pA3KBT6uKKY+wqlJ6e43tIIXNaHIoOcAIOE7vm0CO9tDC2QVLQd/E3HKAiB9
vDVQ3xL0QfFO/WBVkE4L2ZbzSCAIJtXGT7WPGU2SxULoJg3ErY9w9WDwPDo7peRI
B0tRxQ3M0ekszQd7yi6jHyfFXZxACMl5NHuDkAf6Ps2bEpGo9Xrx65GPgX2mTymP
4EJK3jTPvtdHAqrT9Ee9bTLLFiZiNdlweWRWXPwmMlpiyKA4GFJvPVEndLtbIrxd
FVnE30kCEWk0Ie7SYBgu82FSqHloJa9u/gS4ObJL/yZS1Aq20/shxLDLOo7nrHOi
Bpfr6YwRWgzJXhiphSUG8j2nLwAVOjXXg5LNaE4mxksaZMOlps6u0nFdWK87Hf/X
lcLcwHntYsMSdkuW4vJ6qeg/OLAPlUZvmUxF5lF+ppZeEmE7DHD6cgPB6IZBOLr6
nOfU52P8BcexEK9DcbVc
=XCzf
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773001: dnsmasq starting provoke dbus error

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 12/12/14 22:25, chris21.r...@free.fr wrote:
 
 Package: dnsmasq Version: 2.72-2 Severity: important
 
 Dear Maintainer,
 
 I configured dnsmasq on debian jessie. When starting dnsmasq, I
 receive: Erreur DBus : Connection :1.57 is not allowed to own the
 service uk.org.thekelleys.dnsmasq due to security policies in the
 configuration file
 
 I feel a little puzlleded because I could not find the string
 thekelleys in any file present in /etc neitgher in any file name
 or directory in /etc (except in dnsmasq.conf but the occurences are
 commented).
 
 Then it contradicts bug #769486 saying dnsmasq does not depends on
 DBus.
 
 Further more, where can dnsmasq find this
 uk.org.thekelleys.dnsmasq configuration string?
 
 It appears si...@thekelleys.org.uk is the maintainer of this
 package.
 
 Simon, can you tell me where in the default configuration of
 dnsmasq your domain is registered?

/etc/dbus-1/system.d/dnsmasq.conf


Note that when dnsmasq is started by systemd, it does enabled dbus.

Cheers,

Simon.

 
 Best regards, Christophe
 
 -- System Information: Debian Release: 8.0 APT prefers
 testing-updates APT policy: (500, 'testing-updates'), (500,
 'testing'), (500, 'stable') Architecture: amd64 (x86_64)
 
 Kernel: Linux 3.18.0 (SMP w/24 CPU cores) Locale: LANG=fr_FR.UTF-8,
 LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to
 /bin/dash Init: systemd (via /run/systemd/system)
 
 Versions of packages dnsmasq depends on: ii  dnsmasq-base
 2.72-2 ii  init-system-helpers  1.22 ii  netbase  5.3
 
 dnsmasq recommends no packages.
 
 Versions of packages dnsmasq suggests: pn  resolvconf  none
 
 -- Configuration Files: /etc/default/dnsmasq changed [not
 included] /etc/dnsmasq.conf changed [not included]
 
 -- no debconf information
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUjxeyAAoJEBXN2mrhkTWiu9gQAIZuvERLVGj2G0+ZxRFRekpH
ke/Wv1bAon75vz1CeB1KmRfReFiv+ewpk80Z3U/tDlymm9KNOPGVrH6XNO/P0e31
8ISzWkahM+mZJOl7Nx3Y7O3KlzEs2wysA9QJwDYL29O6uIt3pRo9cXoQ9y9A8pyx
BpQkGYxjE39sz6na8Mk5uIklNp15fU1I37lg3CdaG8BdsQ+us3u+NwM0iXg899ke
IRyI1Oh2NuYnDI0Vx54+bp3JJ5qKkcJ7J4rZgSEtKjFaUpFK0LTo8eYOZ7+JyLLJ
3SZBgAx6E3zoIutuqqCBNNmN0E5d8Sdj1vku/rJ1KZxo5GKGIFnduFLMMZW1Ta/q
En4jNzYNWvvQMI4yEvzNgpY0jNSPVYUfdyCORPHonamUupTbN1hD41n2yjxBzZmX
eZ4VCOAH4BoeGZxph2+HoshDvFrzZImMoMwMNdJs0KL7+/1Ai7miUXmVdzH2dil1
WfzTmuAyg4mqV7CMOKp3UsWjwxkvBMkrYrSN04tszWXdicr4NQdfAFs101hTQHsd
tkqB+I2nqdrYuIDI93HgBHnv2M3wLKf/ry/iF+jKirIq8k2OIKP2+f/N9sxN70Kp
WvSO6O6STh9jRASDKUCztKrbRzZleAcxQs6BwBF765L11XE241cNxTBA7ALEQkld
TmjirBO2zGcgMZ3Y6wsG
=Kzly
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761654: dnsmasq: The AD flag is set in every cached answer.

[Simon Kelley]

Thanks for this. I just checked, and the bug is fixed in later versions
of dnsmasq. (I didn't determine exactly which one, but I expect it was
around 2.67, when DNSSEC validation was added, and the whole code
handling DNSSEC flag bits was re-written.)

Therefore in the next release of Debian, this bug will be fixed.

That leaves only the question of the current Debian release. This bug
would only be fixed there if classified as a security bug. You didn't
file the bug as a security bug, and my feeling is that it isn't. Since
dnsmasq 2.62 can't do DNSSEC validation, the value of the AD bit in
replies is pretty minimal anyway.

Cheers,

Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758119: dnsmasq: fails to start under systemd when dbus is not installed

[Simon Kelley]

On 14/08/14 14:11, Michael Biebl wrote:
 Am 14.08.2014 14:57, schrieb Michael Biebl:
 Am 14.08.2014 14:30, schrieb Paul Wise:
 On Thu, 2014-08-14 at 14:15 +0200, Michael Biebl wrote:

 fwiw, we are using User:
 pkg-systemd-maintain...@lists.alioth.debian.org since a while now.

 Ah, there are still some bugs with the old user, sorry. BTW archived
 bugs can now have their usertags altered so that could be fixed.

 Hm, it seems dnsmasq requires dbus in any case, even when running under
 sysvinit or upstart. So I don't understand the alternative dependency
 you suggest. Afaics, dnsmasq should simply add a Depends on dbus?

 As far as I can tell, dnsmasq doesn't need dbus under sysvinit, not sure
 about upstart though.

 Hm, right. It seems so use --enable-dbus when being run under systemd.

 You've proposed: Depends: dbus | sysvinit-core | upstart

 But even with sysvinit-core installed, one can boot using the
 init=/bin/systemd command line.
 So maybe a simple: Recommend: dbus is better?

 I'm also inclined to just make systemd depend or at least recommend
 dbus, seeing [1]

 Michael

 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758111

 
 After some more discussion on #debian-systemd, we decided to make
 systemd recommend dbus.
 After all, when unprivileged users use systemctl, a dbus system bus is
 required and apparently we also need it for [1]
 
 
 

This seems like the correct solution, certainly from the point of view
of the dnsmasq maintainer. There's no reason why dbus is needed if
dnsmasq is started by sysvinit, so I'm not inclined to make dnsmasq
recommend it.



I'll close the dnsmasq bug.

Cheers,

Simon.
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754402: dnsmasq: Ignore files which do not match *.conf in /etc/dnsmasq.d

[Simon Kelley]

On 05/08/14 17:55, Benjamin Cama wrote:
 Hi Simon,
 
 Le samedi 19 juillet 2014 à 22:01 +0100, Simon Kelley a écrit :
 It would be fairly simple to support this upstream, and with hindsight
 it's a better way to do things. My main concern is that to make the
 change now introduces a behavior change with the potential to break
 existing installations.
 
 Yes, I understand.
 
 There may be a way around this, since the directive which tells dnsmasq
 to load the contents of /etc/dnsmasq.d is in /etc/default/dnsmasq

 # By default search this drop directory for configuration options.
 # Libvirt leaves a file here to make the system dnsmasq play nice.
 # Comment out this line if you don't want this. The dpkg-* are file
 # endings which cause dnsmasq to skip that file. This avoids pulling
 # in backups made by dpkg.
 CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new

 Since /etc/default/dnsmasq is a conffile, that could be left alone for
 existing installations which are upgrading, but new semantics introduced
 for new installations, ie delete the line above and add

 CONFIG_DIR_FILE=etc/dnsmasq.d,.conf

 with suitable scripting in the init script and an extension of the
 --conf-dir dnsmasq flag.


 Opinions?
 
 Well, frankly, making this configurable seems overkill to me. On my
 current setup, I see no other software having a configurable
 configuration dir in /etc/default. Better behave the standard way by
 default (hardcode /etc/dnsmasq.d in the init script), without setting
 any CONFIG_DIR* in /etc/default/dnsmasq.
 
 This way, the libvirt trick is still taken into account; we *may* need a
 way to disable it, but it seems so badly needed that I won't cry if it's
 not possible to do without manual tweaking.
 
 Then we have no more dpkg-* exceptions, as only *.conf are included.
 
 That with a warning on the next upgrade (it seems I already saw such
 warning elsewhere for this kind of transition some times ago; same
 thing, to only choose *.conf and not others), so as not to break too
 much. It's only a renaming issue, if correctly advertised.
 
 The most ugly part (to me) would be to extend the --config-dir flag in a
 not-too-ugly way, which I can't think of right now.
 
 Thanks for investigating this! (and I didn't know you where the
 maintainer too: thanks for all this work)
 

I worry that it's an unfriendly thing to do to make a upgrade break any
existing  installation that uses a file in /etc/dnsmasq.d that doesn't
end in .conf. I guess that the postinst script could check for this, and
generate a warning, or configure differently if such files already exist.

My though for config-dir would be to allow something like

--config-dir=/etc/dnsmasq.d,\*.conf


ie the arguments are the directory (as now) followed by one or more
file-endings to exclude (as now) and one or more file endings to
include, marked by preceding them with *. * is a problem on the command
line, because it's a shell metacharacter, but it make the meaning very
obvious.

Cheers,

Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754299: dnsmasq: Reloading dnsmasq with systctl results in stop

[Simon Kelley]

On 17/07/14 06:40, Vladimir K wrote:
 Hm... usually changing additional hosts file was enough to trigger this bug. 
 But now I can not reproduce it either.
 I've rechecked it on both my home servers and now the bug is gone. Tried 
 adding upstream server in config file and host in addn-hosts file. Reload did 
 not trigger daemon stop this time.
 Maybe it has something to do with recent upgrades. I had this bug o two 
 machines before.
 

My test was on an up-to-date sid system. Since there have been no
changes to dnsmasq, I guess it was a bug in systemd which is now fixed.
I can't see anything obvious in the the changelog though.

Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754402: dnsmasq: Ignore files which do not match *.conf in /etc/dnsmasq.d

[Simon Kelley]

On 10/07/14 18:11, Benjamin Cama wrote:
 Package: dnsmasq
 Version: 2.62-3+deb7u1
 Severity: wishlist
 
 Hi,
 
 While configuring dnsmasq today, I stumbled upon a very annoying
 behavior: dnsmasq doesn't ignore files not ending in .conf in its
 /etc/dnsmasq.d/ configuration directory. I had copied the current config
 alongside the original file renaming it with .old and it took me some
 time to realize that the error message I got when restarting dnsmasq
 from now on were because dnsmasq read the two files and found duplicate
 configuration options.
 
 The usual way of handling .d configuration directories in Debian (to
 me, at least) is to only take into account files ending in .conf, so
 that you can have “backup” files or easily ignore some config files.
 The current behavior is a bit disturbing when trying to configure
 dnsmasq.
 
 I realize that dnsmasq has no easy way of achieving this (it can only
 ignore some patterns, not restrict to some pattern), so this may be
 difficult to implement, but I'd be glad if someone found a way to “fix”
 this.
 

It would be fairly simple to support this upstream, and with hindsight
it's a better way to do things. My main concern is that to make the
change now introduces a behavior change with the potential to break
existing installations.

There may be a way around this, since the directive which tells dnsmasq
to load the contents of /etc/dnsmasq.d is in /etc/default/dnsmasq

# By default search this drop directory for configuration options.
# Libvirt leaves a file here to make the system dnsmasq play nice.
# Comment out this line if you don't want this. The dpkg-* are file
# endings which cause dnsmasq to skip that file. This avoids pulling
# in backups made by dpkg.
CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new

Since /etc/default/dnsmasq is a conffile, that could be left alone for
existing installations which are upgrading, but new semantics introduced
for new installations, ie delete the line above and add

CONFIG_DIR_FILE=etc/dnsmasq.d,.conf

with suitable scripting in the init script and an extension of the
--conf-dir dnsmasq flag.


Opinions?

Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754299: dnsmasq: Reloading dnsmasq with systctl results in stop

[Simon Kelley]

On 09/07/14 18:03, Vladimir Kudrya wrote:
 Package: dnsmasq
 Version: 2.71-1
 Severity: important
 
 Dear Maintainer, when reloading dnsmasq with changed configuration, daemon 
 stops.
 Config is valid, daemon can be started normally after that.
 
 Log of the daemon after systemctl reload action:
 
 July 09 20:53:20 host systemd[1]: Reloading A lightweight DHCP and caching 
 DNS server.
 July 09 20:53:20 host dnsmasq[1529]: read /etc/dnsmasq-home.hosts - 2 
 addresses
 July 09 20:53:20 host dnsmasq[1529]: exiting on receipt of SIGTERM
 July 09 20:53:20 host systemd[1]: Reloaded A lightweight DHCP and caching DNS 
 server.
 
 Somewhere along the way dnsmasq recieves SIGTERM
 It happens only if configuration is changed. Reloading daemon with unchagned 
 config does not stop it.
 


I tried making a trivial change to /etc/dnsmasq.conf as a way to
change the configuration, but I can't reproduce this problem. Could you
give a bit more detail on how you're changing the configuration.

Note that sending SIGHUP to dnsmasq (which is what systemctl reload
does) Will NOT make it re-read it's configuration, except for a small
number of specific items. To use a new configuration, you need to
restart dnsmasq, via systemctl restart.

Cheers,

Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748795: dnsmasq: tftp server corrupts larger files

[Simon Kelley]

On 20/05/14 21:20, l3iggs wrote:
 Package: dnsmasq Version: 2.71-1 Severity: normal Tags: upstream
 
 Dear Maintainer,
 
 I've been trying to use the built in tftp server.
 
 It works fine when I use it to serve up smaller (25byte) files.
 However, when serving up larger (~320k) binary files the files
 recieved are too short (327347 vs 327516 bytes) and the contents are
 corrputed.
 
 My testing shows that this corruption begins at byte 0x161 and
 continues through the rest of the file.
 
 This corruption occurs reguardless of the tftp-no-blocksize setting.
 
 I see it when transferring files using tftp clinets on other machines
 and when using the tftp command to localhost on this machine.

A hunch: most tftp clients default to ascii mode transfer, which would
produce symptoms similar to what you are seeming. Are you setting
binary mode in the client before doing the transfer?


Cheers,

Simon.


 
 -- System Information: Debian Release: jessie/sid APT prefers
 unstable APT policy: (500, 'unstable') Architecture: armhf (armv7l)
 
 Kernel: Linux 3.14.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
 
 Versions of packages dnsmasq depends on: ii  dnsmasq-base
 2.71-1 ii  init-system-helpers  1.18 ii  netbase  5.2
 
 dnsmasq recommends no packages.
 
 Versions of packages dnsmasq suggests: ii  resolvconf  1.75
 
 -- no debconf information
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748497: hosts on local network not recognized

[Simon Kelley]

On 17/05/14 20:09, Harald Dunkel wrote:
 Package: dnsmasq
 Version: 2.70-3
 
 Since 2.70-3 dnsmasq doesn't recognize the hosts in the local network
 anymore. The log file shows
 
 May 17 20:23:23 sylvester systemd[1]: Starting A lightweight DHCP and caching 
 DNS server...
 May 17 20:23:23 sylvester dnsmasq[4152]: dnsmasq: syntax check OK.
 May 17 20:23:23 sylvester dnsmasq[4155]: started, version 2.70 cachesize 150
 May 17 20:23:23 sylvester dnsmasq[4155]: compile time options: IPv6 
 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
 May 17 20:23:23 sylvester dnsmasq[4155]: DBus support enabled: connected to 
 system bus
   ^
 May 17 20:23:23 sylvester dnsmasq[4155]: DNS service limited to local subnets
   ^
 May 17 20:23:23 sylvester dnsmasq-dhcp[4155]: DHCP, IP range 10.10.100.128 -- 
 10.10.100.254, lease time 12h
 May 17 20:23:23 sylvester dnsmasq[4155]: using local addresses only for 
 domain example.de
 May 17 20:23:23 sylvester dnsmasq[4155]: using nameserver 10.10.100.1#53
 May 17 20:23:23 sylvester dnsmasq[4155]: no servers found in 
 /var/run/dnsmasq/resolv.conf, will retry
 May 17 20:23:23 sylvester dnsmasq[4155]: read /etc/hosts - 12 addresses
 May 17 20:23:24 sylvester dnsmasq[4155]: Ignoring query from non-local network
   ^
 
 Moving back to 2.70-1 (and pre-systemd) fixes the problem, using the
 same dnsmasq.d/local config file:
 
 server=10.10.100.1
 local=/example.de/
 dhcp-range=10.10.100.128,10.10.100.254,12h
 dhcp-option=option:router,10.10.100.1
 dhcp-host=E0:69:95:80:80:80,sylvester.example.de
 
 /etc/dnsmasq.conf hasn't been touched.

In the 2.70-1 working case, do you see any of the the log lines I've
underlined above?

This looks like the new anti-open-DNS server facility, but that's in
2.70-1 too.

Cheers,


Simon.

 
 
 Regards
 Harri
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724602: dnsmasq: Please enable systemd unit on install and fix it

[Simon Kelley]

On 11/05/14 15:11, Andreas Metzler wrote:
 On 2014-05-11 Michael Biebl bi...@debian.org wrote:
 Am 11.05.2014 10:13, schrieb Andreas Metzler:
 On 2013-09-25 Julian Andres Klode j...@debian.org wrote:
 [...]
 dnsmasq currently does not enable its systemd unit in postinst. It should
 probably use dh-systemd.
 [...]
 
 Isn't this severity serious? I have just gone from sysv to systemd
 
 Agreed, I bumped the severity accordingly.
 
 (using apt-get --purge install systemd-sysv), and was switched from
 dnsmasq enabled before the upgrade to dnsmasq disabled, completely
 breaking DNS resolution.
 
 Simon, first of all, thanks for shipping a native .service file for
 systemd. If you need help getting the service enabled (using
 dh-systemd), please let us know. We are happy to assist you with this or
 provide a patch.
 
 Hello,
 
 dnsmasq is packaged without debhelper, making this a little bit more
 work. However I have simply checked what dh_systemd /would/ do and
 have manually applied the changes to maintainerscripts and
 dependencies to come up with the the attached patch. Could you please
 doublecheck?
 
 Thanks, cu Andreas
 

This looks fine to me, and I'm happy to apply the patch, but I have no
way to definitively test it. (I'm working on a laptop with a
two-year-old Ubuntu installation and a sid chroot for package building.
My net connection is flaky 3G which won't allow me to pull enough stuff
to build a sid VM.)

I propose to upload a new version, if someone can test it ASAP and file
a new serious bug if I've botched it.

Cheers,


Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743218: RM: dhcpcd -- ROM; This package contains the very old dhcpcd version 3.

[Simon Kelley]

Package: ftp.debian.org
Severity: normal

This package contains the very old dhcpcd version 3. It's long ago
unmaintained upstream and replaced with dhcpcd version 5. Dhcpcd version
5 is not directly comptatible with dhcpcd version 3, so it was good to
have one stable release with both versions available, this is Wheezy,
which has dhcpcd and dhcpcd5packages. For the next release, dhcpcd
should be removed, leaving only dhcpcd5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732610: dnsmasq: listen only to loopback device by default

[Simon Kelley]

On 19/12/13 10:51, Michael Prokop wrote:

Package: dnsmasq
Version: 2.68-1
Severity: normal


I've been involved in two situations already where a default dnsmasq
installation was misused for DDoS nameserver attacks, because
dnsmasq is listening on all network devices without any real
limitations by default.

Something like:

% cat /etc/dnsmasq.d/loopback.conf
interface=lo
no-dhcp-interface=
bind-interfaces
listen-address=127.0.0.1

mitigates this problem for systems where dnsmasq is used e.g. only
for chroots on the local system. I'm not sure if listening on
loopback-only is what users of dnsmasq would expect though. But
maybe there could be an according notice about the possible risks
and how to bind it to loopback-only in README.Debian or so if
dnsmasq continues to listen on all interfaces by default?



I'm very tempted to do something like this (though just interface=lo 
should be more than sufficient). The problem is that it will 
gratuitously break _lots_ of existing installations on upgrade.


Hmm, can I find anough packaging-foo to arrange for this on _new_ 
installations, but not on upgrades?


Whatever, I'll add a warning to the docs.


Cheers,

Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730553: dnsmasq: Dnsmasq stops resolving cnames when using libvirt

[Simon Kelley]

Great, thanks for getting back to me. I'll close the bug when 2.68 gets 
done.




Cheers,

Simon.

On 03/12/13 11:06, Alex Corcoles wrote:

Hi,

I've been running:

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

for a week and I've had no failures whatsoever, so I think it's safe to
close this bug if 2.68 is uploaded.

Many thanks,

Álex


On Tue, Nov 26, 2013 at 4:38 PM, Simon Kelleysi...@thekelleys.org.ukwrote:


On 26/11/13 15:38, Alex Corcoles wrote:


Hi Simon,

I've built the package successfully and I'm running it now. I will notify
if there are problems or in a week if there's no incident.

  Brilliant. Many thanks.



Simon.


  Cheers,


Álex

ps.: love dnsmasq! good work


On Tue, Nov 26, 2013 at 3:45 PM, Simon Kelleysi...@thekelleys.org.uk

wrote:


  On 26/11/13 14:16, Alex Corcoles wrote:


  Package: dnsmasq

Version: 2.67-1
Severity: normal

Hi,

After setting up libvirt, my dnsmasq occasionally stops resolving cnames
specified in its configuration file. My dnsmasq is configured with:

interface=br0 # for kvm
bind-interfaces # for kvm

, to prevent interference with libvirt's dnsmasq.

When this happens, if I kill libvirt's dnsmasq, the problem persists.
However, if I restart dnsmasq, it goes away.

Kind regards,

Alex


  I'm fairly confident that this is a new manifestation of a known bug

that's fixed in the forthcoming 2.68 release, but it would be good to be
sure. Would it be possible for you to test 2.68rc4?

The source is available here and it includes the Debian build directory.

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

Alternatively I can supply you i386 binary packages.


Cheers,

Simon.














--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730553: dnsmasq: Dnsmasq stops resolving cnames when using libvirt

[Simon Kelley]

On 26/11/13 14:16, Alex Corcoles wrote:

Package: dnsmasq
Version: 2.67-1
Severity: normal

Hi,

After setting up libvirt, my dnsmasq occasionally stops resolving cnames
specified in its configuration file. My dnsmasq is configured with:

interface=br0 # for kvm
bind-interfaces # for kvm

, to prevent interference with libvirt's dnsmasq.

When this happens, if I kill libvirt's dnsmasq, the problem persists.
However, if I restart dnsmasq, it goes away.

Kind regards,

Alex



I'm fairly confident that this is a new manifestation of a known bug 
that's fixed in the forthcoming 2.68 release, but it would be good to be 
sure. Would it be possible for you to test 2.68rc4?


The source is available here and it includes the Debian build directory.

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

Alternatively I can supply you i386 binary packages.


Cheers,

Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#723287: dnsmasq link with -L/usr/lib

[Simon Kelley]

On 17/09/13 11:32, YunQiang Su wrote:

Package: dnsmasq
Version: 2.66-4
X-Debbugs-CC: wzss...@gmail.com

This package has one or more -L/usr/lib in its build system,
which will make it ftbfs if there is libraries under /usr/lib,
while is not the default architecture, mips* for example.

On mips* systems, /usr/lib is defined as place to hold O32
libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.

Beside the way, on the multiarch system like Debian, user may install
libraries under /usr/lib by hand.

Please use the default search path if you can, and please consider fix
this.

I will try to fix this bug, while if you can help to fix it,
It will be very appreciative.

The attachement is the buildlog of this package on mips64el platform.


I can't see anywhere that hardcodes /usr/lib in the package: the build 
log you include seems to have failed for a different reason:


 dpkg-checkbuilddeps: Unmet build dependencies: libnetfilter-conntrack-dev
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; 
aborting



Please advise.

Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#709179: Please automagically forward to dnscrypt-proxy if available

[Simon Kelley]

On 21/05/13 12:43, Thomas Hood wrote:

Package: dnsmasq
Version: 2.66-2
Severity: wishlist

OpenDNS's DNSCrypt client for Linux (called 'dnscrypt-proxy')[0] is not yet
packaged for Debian but some people are already installing it from source
and it is of course possible that it will eventually be packaged. This is a
request that the dnsmasq package be enhanced to make it easy to use dnsmasq
along with dnscrypt-proxy and resolvconf.

Dnscrypt-proxy doesn't cache. So it makes sense to run dnsmasq with caching
turned on and configured to forward queries to dnscrypt-proxy at a loopback
address. The request is that this happen automagically when resolvconf is
also installed. Getting it to happen automagically on a resolvconfful
system just requires tweaking dnsmasq's resolvconf hook script.

Currently dnsmasq's resolvconf hook script gathers all nameserver addresses
from the resolvconf database, excludes dnsmasq's own listen address and
writes the remaining addresses to /var/run/dnsmasq/resolv.conf.

When dnscrypt-proxy is running only dnscrypt-proxy's address should be used.

Let's decide here and now that the name of dnscrypt-proxy's resolvconf
record will be lo.dnscrypt. (Thus dnscrypt-proxy or its initscript will
do something like echo 127.0.0.2 | resolvconf -a lo.dnscrypt.)

Dnsmasq's resolvconf hook script should thus be changed such that if
lo.dnscrypt is present, only the address from lo.dnscrypt will be written
to /var/run/dnsmasq/resolv.conf.

Once there is agreement I will submit a patch.

[0]https://github.com/opendns/dnscrypt-proxy



Sounds fine to me. Will apply the patch when I receive it.


Cheers,

Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#568164: A possible light at the end of the tunnel

[Simon Kelley]

On 12/01/13 22:04, Chris Carr wrote:

Happy new year Simon. I have finally discovered bug#681961, which looks
as if someone else is having the same problem that I am. If the offered
patch is applied and solves the problem I will happily close this bug!

CC




Hmm, it would be nice if that was the solution, but I can't see it. 
#568164 is a problem during package upgrade, but #681961  seems to be 
during boot-up. Not the same situation, surely?



Cheers,

Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#690075: unblock: dnsmasq/2.63-4

[Simon Kelley]

On 10/11/12 15:10, intrigeri wrote:

tags 690075 + moreinfo
thanks

Hi Moritz,

Moritz Muehlenhoff wrote (09 Oct 2012 17:51:26 GMT) :

Please unblock package dnsmasq
It fixes CVE-2012-3411
unblock dnsmasq/2.63-4


The new upstream version includes quite a few changes that are
unrelated to the security fix, which probably partly explains why
nobody reviewed the proposed changes yet.

However, determining which exact set of patches should be backported
from upstream to fix this issue is not trivial, and I guess that's why
Moritz asks for the whole think to be unblocked:

54dd393 (Add --bind-dynamic) is obvious, but a few follow-up commits
come to fix the problems brought by the initial implementation; at
least these two ones seem needed:

  * 2b5bae9 -- Fall back from --bind-dynamic to --bind-interfaces in
BSD, rather than quitting
  * 5f11b3e -- Cope with --listen-address for not yet existent addr in
bind-dynamic mode

... and I would not bet that's enough.

Simon, are you interested in listing the commits that are needed,
on top of 2.62-3, to fix CVE-2012-3411 without breaking anything?




I'd strongly suggest moving to 2.63-4, rather than backporting. The 
changes for the security fix are not trivial, and probablity of 
introducing a bug backporting is much larger that the probablity that 
there's an un-found bug in 2.63 which is not in 2.62. There are no 
intended backwards incompatibilities between 2.63 and 2.62, and no 
un-intended ones have been found in the three months since 2.63 was 
released.



Cheers,

Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683372: CVE-2012-3411

[Simon Kelley]

On 05/09/12 16:57, Moritz Muehlenhoff wrote:
 On Wed, Aug 01, 2012 at 05:30:47PM +0100, Simon Kelley wrote:
 On 31/07/12 09:35, Moritz Muehlenhoff wrote:
 Package: dnsmasq
 Severity: important
 Tags: security

 Hi,
 I know you're aware of this bug since you commented it already, but I'm
 filing a Debian bug to keep track of this for Wheezy:
 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3411

 Cheers,
  Moritz


 OK. I think what's needed to fix this is

 1) dnsmasq 2.63 release and into Wheezy.
 2) Alter libvirt to pass the new --bind-dynamic flag instead of  
 --bind-interfaces
 
 This bug can be closed with 2.63-1? Or is there anything missing?
 
 Cheers,
 Moritz
 

We're up to 2.63-3 now, due to various irritating packaging regressions.
That needs to be forced into wheezy, and then the torch needs to be
passed to libvirt.


Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#686484: chowning pid directory and writing there as root may lead to security issue

[Simon Kelley]

On 02/09/12 08:44, Michael Tokarev wrote:

Package: dnsmasq
Version: 2.55-2
Severity: serious
Tags: security

The initscript (and postinst script) of dnsmasq creates /var/run/dnsmasq
directory and chowns it to dnsmasq:nogroup.  However, dnsmasq daemon writes
the pidfile (which apparently is the only file there) as root user.  Here's
the code which does this (in src/dnsmasq.c):

   FILE *pidfile;

   /* only complain if started as root */
   if ((pidfile = fopen(daemon-runfile, w)))
 {
   fprintf(pidfile, %d\n, (int) getpid());
   fclose(pidfile);
 }

So there's no checking for this file to exist, being a symlink etc.

This way, we effectively making dnsmasq user equal to root: dnsmasq
user can (sym)link /var/run/dnsmasq/dnsmasq.pid to, say, /etc/shadow,
and it will be overwitten the next time dnsmasq (re)starts.  This is
obviously wrong.

The only good side of this is that dnsmasq writes only controlled data
to this file (its pid, as per above), so the damage is minimal, ie,
only a denial of service, not gain of service (hence Severity is only
serious).

Besides, documentation says the pid file is /var/run/dnsmasq.pid, not
/var/run/dnsmasq/dnsmasq.pid - it is the initscript which sets the option
behind the scenes.  Also, there's no mentions in the changelog about
WHY pid file is in this location.  And more, it one can change the user
dnsmasq runs as.

It looks like this pidfile stuff needs to be removed entirely (moving
it to a subdir silently and chowning that subdir to dnsmasq user).

Thanks,

/mjt



The explanation for the current state of affairs is here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508560

/var/run/dnsmasq is owned by user dnsmasq so that dnsmasq can unlink the 
pid file when it shuts down, even though at that point it is running as 
user dnsmasq, not as user root.


I can see a couple of ways of fixing this, without just removing the 
whole edifice, but neither are perfect.


1) stat the pid file and check for symlinks, etc (or just unlink it) 
just before creating the new one. There's a race between the unlink and 
the creation though - an attacker could create the symlink then.


2) Create the pid file after changing user. That works fine in this 
case, but not in the default case when dnsmasq writes to 
/var/run/dnsmasq.pid and then changes to user nobody. The behaviour 
would therefore need to be enabled by a special config option or risk 
breaking nearly every dnsmasq installation other than Debian/Ubunutu.



Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#686484: chowning pid directory and writing there as root may lead to security issue

[Simon Kelley]

On 02/09/12 08:44, Michael Tokarev wrote:

Package: dnsmasq
Version: 2.55-2
Severity: serious
Tags: security


Ignore my previous question: currently educating myself about O_EXCL


Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685204: dnsmasq: trying to overwrite config files in dnsmasq-base

[Simon Kelley]

On Sat, 18 Aug 2012 09:54:26 +0100, Neil Williams codeh...@debian.org
wrote:
 Package: dnsmasq
 Version: 2.63-1
 Severity: serious
 Justification: Fails to install
 
 Upgrading dnsmasq to 2.63-1 fails:
 
 E: /var/cache/apt/archives/dnsmasq-base_2.63-1_amd64.deb: trying to
 overwrite '/etc/dbus-1/system.d/dnsmasq.conf', which is also in package
 dnsmasq 2.62-3
 
 Looks like a missing Replaces or an accidental move of the
 config file?
 

Hmm, the intention was to move that conffile from dnsmasq to dnsmasq-base.
I thought I had the correct Replaces: and it worked for me.

I'm away for the next week, will look at this on my return.

Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684965: dnsmasq does not query all dns servers

[Simon Kelley]

On 16/08/12 08:59, Ritesh Raj Sarraf wrote:
 On Wednesday 15 August 2012 02:16 PM, Simon Kelley wrote:
 If your 192.168.2.1 is local nameserver only handling certain domains,
 you can configure dnsmasq to use it as such with the

 server=/example.com/192.168.2.1

 style configuration on /etc/dnsmasq.conf.
 
 If I have 2 name servers, should I be repeating the above example with
 both the IP addresses?
 

Yes, exactly so.


Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684965: dnsmasq does not query all dns servers

[Simon Kelley]

On 15/08/12 09:17, Ritesh Raj Sarraf wrote:
 Package: dnsmasq
 Version: 2.62-3
 Severity: important
 
 Simon,
 
 Looks like, since your last fix of dnsmasq's integration with systemd,
 something has broken. I am not sure where is the problem (could be
 resolvconf too), but as far as I can remember this problem seems to have
 begun since your last update.
 
 
 rrs@champaran:~$ cat /var/run/dnsmasq/resolv.conf 
 nameserver 10.73.158.106
 nameserver 10.73.158.107
 nameserver 192.168.2.1
 
 rrs@champaran:~$ host smtp.corp.corpdomain.com
 Host smtp.corp.corpdomain.com not found: 3(NXDOMAIN)
 
 rrs@champaran:~$ dig @10.73.158.106 smtp.corp.corpdomain.com
 
 ;  DiG 9.8.1-P1  @10.73.158.106 smtp.corp.corpdomain.com
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 18951
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;smtp.corp.corpdomain.com.  IN  A
 
 ;; ANSWER SECTION:
 smtp.corp.corpdomain.com.   3475IN  A   10.57.159.114
 
 ;; Query time: 31 msec
 ;; SERVER: 10.73.158.106#53(10.73.158.106)
 ;; WHEN: Wed Aug 15 13:39:48 2012
 ;; MSG SIZE  rcvd: 54
 
 rrs@champaran:~$ dig smtp.corp.corpdomain.com
 
 ;  DiG 9.8.1-P1  smtp.corp.corpdomain.com
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 24603
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;smtp.corp.corpdomain.com.  IN  A
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Wed Aug 15 13:40:04 2012
 ;; MSG SIZE  rcvd: 38
 
 
 
 As you can see, direct query to the nameserver works. Only if asking the
 local dnsmasq server, incorrect result is shown.
 
 
 
 My setup involves my regular wifi network which provides the 192.x.x.x
 dns nameserver ip and my vpn connection which provides me the 10.x.x.x
 nameserver.
 
 The vpn connection drops at times, so I do have a loop to check every 5
 minutes, and re-establish the connection if unavailable. 
 

What does dig @192.168.2.1 smtp.corp.corpdomain.com return?

Assuming it's NXDOMAIN, that's your problem, and it's not a new one, but
the way dnsmasq has always worked. Dnsmasq is written on the strong
assumption that all the upstream nameservers are equal, and it can
forward a query to any of them. An NXDOMAIN answer is as good as any
other, and will be returned to the original requestor: it explicitly
doesn't trigger an attempt to send the query to another nameserver, and
the order of the nameservers is not significant.

If your 192.168.2.1 is local nameserver only handling certain domains,
you can configure dnsmasq to use it as such with the

server=/example.com/192.168.2.1

style configuration on /etc/dnsmasq.conf.


Cheers,

Simon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683372: CVE-2012-3411

[Simon Kelley]

On 31/07/12 09:35, Moritz Muehlenhoff wrote:

Package: dnsmasq
Severity: important
Tags: security

Hi,
I know you're aware of this bug since you commented it already, but I'm
filing a Debian bug to keep track of this for Wheezy:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3411

Cheers,
 Moritz



OK. I think what's needed to fix this is

1) dnsmasq 2.63 release and into Wheezy.
2) Alter libvirt to pass the new --bind-dynamic flag instead of 
--bind-interfaces


Cheers,

Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675854: dnsmasq: resolvconf overwrites entries in resolv.conf

[Simon Kelley]

On 08/06/12 14:47, Ritesh Raj Sarraf wrote:
 On Friday 08 June 2012 01:05 PM, Tollef Fog Heen wrote:
 ]] Ritesh Raj Sarraf 

 Do you want this bug re-assigned to dnsmasq? I think it fits in on
 systemd. systemd should be a drop-in replacement.  But then, systemd
 doesn't claim to be a drop-in replacement. It states that applications
 need to be modified (systemd-ized) and adapt to systemd.
 Given dnsmasq ships a .service file, it's dnsmasq's responsibility to
 ensure it has the same behaviour with both service definitions.  So,
 this bugs belongs in dnsmasq.

 Tollef: The bug has a good amount of detail. I think there are use cases
 that systemd does not cover. In this case, it is reading the variables
 from the /etc/default/dnsmasq file. The bug has the details. Please
 correct if things have changed otherwise.
 
 

The real problem here is not /etc/default/dnsmasq, it's the code in
/etc/init.d/dnsmasq which links dnsmasq and resolvconf. What is required is:

1) Pass an extra command-line argument to dnsmasq iff /sbin/resolvconf
exists.

2) Run echo nameserver 127.0.0.1 | /sbin/resolvconf -a lo.dnsmasq
after dnsmasq has started succesfully  (ExecStartPost should do that)
but again, only if /sbin/resolvconf exists.

3) run /sbin/resolvconf -d lo.dnsmasq after dnsmasq has stopped.
(ExecStopPost)

The difficult part of this seems to be that different actions are needed
depending of if resolvconf is installed or not.

Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675854: dnsmasq: resolvconf overwrites entries in resolv.conf

[Simon Kelley]

On 07/06/12 15:41, Ritesh Raj Sarraf wrote:
 reopen 675854
 retitle 675854 systemd breaks dnsmasq
 reassign 675854 systemd
 thanks
 
 
 Just verified it back with sysvinit. If the expectation is that every
 package maintainer has to adapt systemd, then this bug can be
 closed/reassigned. Otherwise, if systemd is expected to run sysv
 initscripts in compat mode without breaking them, then this is a bug.
 
 
 I see that systemd provides a dnsmasq service.  In the sysv init method,
 it sources /etc/default/dnsmasq for a couple of settings, one of which
 matters this use case. Looking at the systemd service file for dnsmasq,
 I do not see the equivalent.
 
 How do we do that in systemd? This will be a common problem for many of
 my packages too which do a lot of shell work to bring sanity.
 


We've been here before.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640095

is relevant, I think.


Simon.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673388: Home folder not writeable by dnsmasq user

[Simon Kelley]

On 18/05/12 10:09, Jörg Herzinger wrote:
 Package: dnsmasq Version: 2.55-2 Severity: important
 
 Hi,
 
 The default location for lease files (/var/lib/misc), which is also
 the home folder of the user dnsmasq, is not writeable for the user
 itself which is why the daemon won't function without specially
 setting everything in the config file. 

This is incorrect. Dnsmasq is started as root and opens the leases file
before dropping root privileges, so the status of the leases file for
writing by user dnsmasq is irrelevant. It does not require any config
file entries for dnsmasq to run with leases file in the default location.

 I'd suggest introducing
 /var/lib/dnsmasq which should be owned by dnsmasq and adding that
 folder as default location for leases and such. The current setting
 is just not sane at all... This bug is also described here
 https://bugzilla.redhat.com/show_bug.cgi?id=407901

No, that's a different issue to do with SELinux.
 

Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666517: dnsmasq: TXT record problems found by berkeley's netalyzr

[Simon Kelley]

On 31/03/12 12:55, FLD wrote:
 Package: dnsmasq
 Version: 2.55-2
 Severity: normal
 
 Did the berkeley's ICSI Netalyzr test on a Win XP (Java 7) machine 
 behind my Debian gateway running Squeeze, got following results:
 
 Direct probing of DNS resolvers (?) –
 Your system is configured to use 1 DNS resolver(s).
 The resolver at 192.168.0.1 (phys-dns51) could not process the following 
 tested types:
 
 * Medium (~1300B) TXT records
 * Large (~3000B) TXT records
 

This turns out to be a problem with Netalyzr. It's fixed now.
Doing the test here, I still get complaints about ~3000B TXT records,
that turns out to be a problem with my ISPs DNS servers.

Either way, I'm sure there's not a dnsmasq problem

Thanks for the feedback: you didn't improve dnsmasq, but you did improve
netalayzr. I'll close this bug now.


Cheers,

Simon.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666517: dnsmasq: TXT record problems found by berkeley's netalyzr

[Simon Kelley]

On 31/03/12 12:55, FLD wrote:

Package: dnsmasq
Version: 2.55-2
Severity: normal

Did the berkeley's ICSI Netalyzr test on a Win XP (Java 7) machine
behind my Debian gateway running Squeeze, got following results:

Direct probing of DNS resolvers (?) –
Your system is configured to use 1 DNS resolver(s).
The resolver at 192.168.0.1 (phys-dns51) could not process the following tested 
types:

 * Medium (~1300B) TXT records
 * Large (~3000B) TXT records

It validates DNSSEC. It does not wildcard NXDOMAIN errors. The resolver reports 
a number of additional properties. Hide them.

 * Hostname: phys-dns51
 * Version: dnsmasq-2.55
 * Authors: Simon Kelley
 * Copyright: Copyright (c) 2000-2010 Simon Kelley



Most likely, either your gateway is blocking connections to TCP port 53, 
or your ISP/upstream nameservers won't accept TCP connections.


Try something like

dig +vc somedomain

to test this.

Simon.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#665008: keeps segfaulting

[Simon Kelley]

On 22/03/12 10:32, Stéphane Glondu wrote:

Package: dnsmasq
Version: 2.60-1
Severity: grave

Hello,

I cannot start a (squeeze) netboot install (on an eee pc 701) using
dnsmasq on the server. In the past, I have already installed
(successfuly) computers this way. Today, dnsmasq keeps segfaulting
after downloading the kernel image. It also seems to segfault randomly
when there is DHCP traffic that should be ignored on the network.


Cheers,



OK, this is not a known bug. Could you build a version of dnsmasq with 
debugging symbols and either run it in in the foreground with


cd /tmp
ulimit -c unlimited
/usr/sbin/dnsmasq -d


When it crashes, send me the core file from /tmp and the binary 
/usr/sbin/dnsmasq



To build the package, get the source and then run

fakeroot debian/rules DEB_BUILD_OPTIONS=nostrip noopt binary

if you're not familiar with building packages from source, let me know, 
and I'll send you  a pre-built package.



Thanks for your help.


Simon.





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#659983: dhcpcd: Fix for CVE-2011-0996

[Simon Kelley]

On 15/02/12 14:30, Marc Deslauriers wrote:

Package: dhcpcd
Version: 1:3.2.3-9
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch



*** /tmp/tmpYPCJL7/bug_body
In Ubuntu, the attached patch was applied to achieve the following:


 * SECURITY UPDATE: dhcpcd before 5.2.12 allows remote attackers to
   execute arbitrary commands via shell metacharacters in a hostname
   obtained from a DHCP message. (LP: #931036)
   - 
https://build.opensuse.org/package/view_file?file=dhcpcd-3.2.3-option-checks.diffpackage=dhcpcdproject=network%3Adhcprev=52442e5c1d803d7c1818a920a0bae7f1
   - above linked patch(without the additional support for NETBIOS type
 messages) has been added.
   - CVE-2011-0996


Thanks for considering the patch.


-- System Information:
Debian Release: wheezy/sid
   APT prefers precise-updates
   APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise-proposed'), (500, 'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-15-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


I plan to keep this very old dhcpcd version around for wheezy, to give a 
one-release overlap with the current, but incompatible, dhcpcd5.
These changes should probably go into wheezy, but I'm inclined to think 
that this isn't a security issue for squeeze


The dhcpcd.sh script that's included in the Debian package doesn't 
(AFAIK) make any unsafe use of the variables which may have unsafe 
characters, and it contains a very explicit warning for anyone who is 
modifying it.


# This script sources /var/lib/dhcpc/dhcpcd-interface.info which defines
# a set of variables.
# NOTE THAT THE DATA IN SOME OF THESE VARIABLES COME FROM
# UNTRUSTED SOURCES AND ARE UNCHECKED.
# The variables in question are HOSTNAME, DOMAIN, NISDOMAIN,
# ROOTPATH DNSSEARCH and DHCPSNAME. Enough quoting is done to ensure that
# execution of this script is safe, but beware if you pass the value of 
any of

# these variables to another shell or perl script - there is nothing to
# stop an attacker putting dangerous characters in these variables.
#
# This is important: if noglob not set a filename expansion metachar may be
# included in one of the variables set in the info file and executed
# if that variable is used.
# Try this to see the effect:
# TEST='*'; echo $TEST
set -o noglob

Comments from  Debian security people?



Cheers,

Simon.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#659983: dhcpcd: Fix for CVE-2011-0996

[Simon Kelley]

On 16/02/12 19:09, Florian Weimer wrote:

* Simon Kelley:


I plan to keep this very old dhcpcd version around for wheezy, to give
a one-release overlap with the current, but incompatible, dhcpcd5.


Uhm, what's the source package name?  I assumed that ISC DHCP 3.x had
already been dropped in squeeze.



http://packages.debian.org/squeeze/dhcpcd

Not ISC: another DHCP client.

Simon.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#647726: dnsmasq does not stop at reboot and halt

[Simon Kelley]

On 13/11/11 17:06, Andreas Stempfhuber wrote:
 Hi Simon,

 Regarding bug #506734, I have concerns because it creates an unexpected 
 shutdown behavior. It assumes that the shutdown order doesn't matter. But why 
 is there a Required-Stop option defined by LSB and why does dnsmasq use it to 
 define shutdown dependencies, if they don't matter? It seems to me that this 
 has not been considered by the discussion.

That's a very good question: the Required-Stop: dependencies have been
the same since the dnsmasq script was LSB-ised five years ago.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374650

has the gory details from back then. I actually don't think that the set
of dependencies was thought through very much: $network is probably not
needed for stopping, and lack of $syslog just loses the final
Exiting message with current code, as we've discovered. I'm
worried about $remote_fs though; why could /usr be needed and would it
have gone away by sendsigs time?

http://wiki.debian.org/LSBInitScripts says:

 $remote_fs

all filesystems are mounted. In some LSB run-time environments,
filesystems such as /usr may be remote. If the script need a mounted
/usr/, it needs to depend on $remote_fs. Scripts depending on $remote_fs
do not need to depend on $local_fs. During shutdown, scripts that need
to run before sendsigs kills all processes should depend on $remote_fs.


As the dnsmasq binary is /usr/sbin/dnsmasq, I can't see that /usr would
be unmounted before the process dies.



 
 The reason for bug #50673 was a faster shutdown by stopping the daemons in 
 parallel by sendsigs instead of running each shutdown script in serial. In 
 the 
 meantime Debian changed the init system and is executing the shutdown scripts 
 in parallel, one script can no longer simply delay all others. The reason for 
 bug #50673 (faster shutdown) does IMHO no longer exist.

The meta-reason for 50673 is that this change unified the Debian and
Ubuntu packages for dnsmasq. Given that Ubuntu has changed its init
system since then, it may be possible make the change back to stopping
at levels 0 1 and 6 without causing Ubuntu problems.

 
 Independent of my opinion regarding bug #506734, dnsmasq is a great tool. It 
 is since years my first choice when I need a DNS and/or DHCP server. Many 
 thanks for this great software!

Glad you like it!


Cheers,

Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#647726: dnsmasq does not stop at reboot and halt

[Simon Kelley]

On 07/11/11 22:30, Andreas Stempfhuber wrote:


Maybe it's related to a change between dnsmasq 2.55 in Squeeze and 2.59 in
SID?


Indeed: from the 2.56 changelog:

Ensure that dnsmasq terminates cleanly when using
--syslog-async even if it cannot make a connection to the
syslogd.

I only write this stuff, I can't be expected to remember it too :-)

The patch changes

  if (!entries)
{
  close(log_fd);
  break;
}   


to

  if (!entries || !connection_good)
{
  close(log_fd);
  break;
}

in flush_log()

I think that's probably a better fix for the problem you're seeing than 
the runlevel change.


Cheers,

Simon.









--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#647726: dnsmasq does not stop at reboot and halt

[Simon Kelley]

On 05/11/11 17:21, Andreas Stempfhuber wrote:

Package: dnsmasq
Version: 2.55-2
Severity: normal

Hi,

I assume dnsmasq should be stopped at runlevel 0, 1 and 6 and not just
at runlevel 1 as currently.

Dnsmasq is currently listed as a process which fails to stop at
/etc/init.d/sendsigs each time I reboot or hald the PC. It unnecessarily
delays the shutdown. This is no longer the case after replacing

# Default-Stop:   1

with

# Default-Stop:   0 1 6

at /etc/init.d/dnsmasq and calling insserv -d dnsmasq.

Thanks,

Andi



Your patch reverses a change that was made in response to 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506734 with the 
intention that it would speed up shutdown by relying on sendsigs to stop 
dnsmasq.


I wonder why sendsigs is failing to stop dnsmasq in a timely manner?

Simon.





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#647726: dnsmasq does not stop at reboot and halt

[Simon Kelley]

On 07/11/11 20:22, Andreas Stempfhuber wrote:

 I wonder why sendsigs is failing to stop dnsmasq in a timely manner?
 
 Because dnsmasq requires syslog which is not available during sendsigs.
 
 The LSB header of the dnsmasq initscript contains Required-Stop:  $network 
 $remote_fs $syslog to make sure that the network, remote filesystem and 
 syslog is still available during shutdown. This requirements are no longer 
 fulfilled (or assured) when dnsmasq is stopped via sendsigs.
 
 I was able to replicate the issue by manually stopping the syslog daemon and 
 then manually stopping dnsmasq. In this sequence dnsmasq takes a long time 
 (longer than 10 seconds) to stop.
 

That's good information, thanks. It explains a lot. The relevant dnsmasq
code is flush_log() in src/log.c - but that's supposed to exit without
waiting if the connection to the syslog daemon is lost. Looks like
that's not working: I'll see if I can reproduce.


Cheers,

Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#647726: dnsmasq does not stop at reboot and halt

[Simon Kelley]

On 07/11/11 20:22, Andreas Stempfhuber wrote:

 I was able to replicate the issue by manually stopping the syslog daemon and 
 then manually stopping dnsmasq. In this sequence dnsmasq takes a long time 
 (longer than 10 seconds) to stop.
 

I can't replicate this behaviour: I tried datagram and stream /dev/log,
and asynchronous logging in dnsmasq enabled/disabled and in all cases
dnsmasq notices that the log connection has gone and doesn't loop
waiting to flush the log.

Any clues as to why your system should be different? Could you let me
have a copy of your syslog and dnsmasq configs?

Cheers,

Simon.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#644345: dnsmasq: Not starting due to 'failed to create listening socket' for ipv6 link-local address

[Simon Kelley]

On 05/10/11 01:47, Brielle Bruns wrote:
 dnsmasq works properly in 2.57-1 on the same system,
 so this is probably either an upstream bug, or one introduced in a debian
 specific patch.
 

Can I ask you to recheck this? I suspect that the change which
precipitated the problem is actually a kernel upgrade which probably
happened around the same time. If that's the case, I understand the
problem, but if the latest kernel does indeed work with 2.57-1, then
there's something else happening.

Cheers,

Simon.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#644345: dnsmasq: Not starting due to 'failed to create listening socket' for ipv6 link-local address

[Simon Kelley]

On 05/10/11 20:44, Brielle Bruns wrote:

 Hi Simon!
 
 Thanks for contacting me.
 
 I'm using 2.57-1 on linux-image-3.1.0-rc4-amd64 at the moment.
 
 Do you want me to try this on linux-image-3.1.0-rc7-amd64?
 
 I have confirmed it does suffer from the same issues on
 linux-image-3.0.0-1-amd64 and linux-image-2.6.32-5-amd64 previously.
 

Hmm, looks like your problem is not the one described in
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2011q3/005247.html
then, but something new. Please could you send me a copy of
/etc/dnsmasq.conf, and the results of

strace /usr/sbin/dnsmasq -d

for both 2.57-1 and 2.58-3

(you will need to stop the system daemon with /etc/init.d/dnsmasq stop
before running the above tests.)

Cheers,

Simon.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#640095: systemd configuration fails to start dnsmasq

[Simon Kelley]

 Yep, I did that already (did you see the updated service file?).

Not when I wrote my last message, but I have now. It's much better,
thank you.
 
 1) Make dnsmasq capable of getting the DNS domain name on its own. It’s not 
 too
much code, I’ve ripped out the appropriate parts of 'hostname', it’s less
than one page of code, see http://p.nnev.de/2017. Not sure if it becomes
even less code when using functions which are in your code-base already.

Advantages: You could make that lookup asynchronuous, thus starting 
 dnsmasq
faster (it does not have to wait blockingly on resolving the hostname but
can immediately show up on DBus). Also, we don’t have to use shell in the
boot process just for expanding the parameter.

 2) Start /bin/sh -c 'dnsmasq …' in the service file.

Advantages: No code changes to dnsmasq.

 I do prefer the first option. What do you think?

 I think this approaches the problem from the wrong end. Consider this
 scenario: user installs dnsmasq and configures it by editing
 /etc/dnsmasq.conf, /etc/default/dnsmasq, dropping files in
 /etc/dnsmasq.d. Now user installs systemd and expects dnsmasq to be
 started by systemd instead of the sysV initscript. The systemd-started
 dnsmasq should behave in the same way as before and not arbitrarily
 ignore some of the configuration which previously worked. The
 dnsdomainname line (and the others) have been in /etc/default/dnsmasq
 for a long time, backwards compatibility says it should continue to work
 and if it doesn't, the package maintainer (ie, me) will rightly get grief.
 Well, if we go for option 1, we could deprecate the DOMAIN_SUFFIX variable and
 have a way that works for sysvinit *and* systemd.
 
 Apart from that, I don’t really see a way to still support the DOMAIN_SUFFIX
 variable without shipping a Debian-specific script that generates a temporary
 config file. I consider that really ugly, though, for multiple reasons: It’s a
 shell-script and in the systemd world we like to avoid those. Furthermore, 
 it’s
 Debian-specific, so other distributions still have the problem of setting the
 domain suffix. I’ve asked in #systemd and Fedora uses a service file where the
 user has to manually configure the domain suffix in /etc/sysconfig/dnsmasq. On
 Arch Linux, the user is supposed to configure it in /etc/dnsmasq.conf.

I would be inclined to just state that the whole of /etc/default/dnsmasq
is not used when systemd is in use except that we haven't yet addressed
resolvconf. It seems to me that the wrapper script is the only way to
solve that problem, too, so maybe it's worth biting the bullet and doing
it. Yes, it's a bit nasty, but it makes it very easy to retain complete
backwards compatibility in the Debian package. That really is valuable -
it's one of Debian's USPs  that upgrades Just Work. I'm happy to
distribute a service file without the Debian elaborations too, in fact I
already do: /contrib/systemd/dnsmasq.service v. debian/systemd.service

resolvconf is an issue. Not supporting it will break far more systems
than DOMAIN_SUFFIX.


 
 Unrelated to that issue, I’ve learnt that the handling of /etc/default/locale
 to have LANG is completely unnecessary in systemd. systemd will read
 /etc/locale.conf and fall back (on Debian) to /etc/default/locale anyways, so
 all services have correct environment without doing anything specific. I’ve
 updated the service file accordingly and attached the most recent version.

That's good.

I'll think about how to do a wrapper and get back to you.

Cheers,

Simon.

 
 Best regards,
 Michael




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#640095: systemd configuration fails to start dnsmasq

[Simon Kelley]

Michael Stapelberg wrote:

 So, I reflected about this, and we cannot use User=dnsmasq in the service file
 because dnsmasq needs to bind to port 53 as root.

Dnsmasq needs to be started as root, but it needs the command-line
argument --user=dnsmasq, to tell it to change to user dnsmasq _after
binding port 53, etc etc.

The reason for this is security: dnsmasq is handling untrusted network
data and is theoretically vulnerable to compromise by buffer overflow
etc. If it happens, much better that an attacker has control of a
process _not_ running as root. nobody is used in the source because
that's a non-root, non-real-person user that's available everywhere and
will therefore work for source installs. For Debian, we make a user just
for this, since a user that has no writable files, no shell, no home dir
and is not used for anything else is more secure again. It would be
possible to patch the source s/nobody/dnsmasq/ but it's easier to do
this in the startup script than maintain the patch.

 
 But aside from that, I wonder why we (as in: Debian) need to use the dnsmasq
 user while the default is the 'nobody' user, which we also have in Debian. The
 only difference I can spot so far is that the dnsmasq user has /var/lib/misc 
 as
 homedir and dnsmasq stores a file called dnsmasq.leases there. I’m not sure
 what the intentions are, but my first question is: why is that file not in
 /var/run (and therefore on tmpfs)?

/var/lib/misc/dnsmasq.leases is the persistent DHCP lease database, it
has to survive over reboot. It's also opened whilst dnsmasq is still
root, so isn't owned by user dnsmasq.

The only file that's owned by dnsmasq is the directory /var/run/dnsmasq.
That's done so that the PID file /var/run/dnsmasq/dnsmasq.pid can be
deleted by dnsmasq as it exits, even though dnsmasq isn't running as
root then. That location for the PID file isn't the standard one either,
so gets overridden on the command line.

The options which are needed on the command line for debian are therefore
-x /var/run/dnsmasq/dnsmasq.pid
-u dnsmasq
-7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new

(the last one activates the /etc/dnsmasq.d drop-dir for config fragments.)

Possibly the solution is something like

ExecStart=/usr/sbin/dnsmasq -k -x /var/run/dnsmasq/dnsmasq.pid \
-u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new

but somehow maintaing the ability to override the config-dir in
/etc/default/dnsmasq
 
  • LANG gets set if it is defined in /etc/default/locale. I’m not sure 
 what the
effects of that are (I don’t set LANG on my system, I prefer the LC_*
settings). Does it somehow affect the behaviour of dnsmasq when 
 resolving?
If so, how?
 It affects the charset used when reading internationalised domain names
 from configuration files and the translation used for messages. It's needed.
 OK. I think this could be done with EnvironmentFile=-/etc/default/locale. I
 will test it and add it (including a comment on why it is necessary).
 I am still not quite sure about why we need it and what the effects really 
 are.
 Of course, log messages appear in a different language after setting LANG.
 But what exactly is the behaviour when resolving? Why does the LANG setting of
 my *server* define which answers my clients get?

It doesn't, it tells dnsmasq what character encoding to expect for
internationalised domain name strings which appear in configuration
files on the _server_. By the time they get over the network they've
been transformed into a network-neutral representation.


 
 The problem I see with using LANG is that /etc/default/locale is
 Debian-specific and we want to have the same systemd service file for all
 distributions (ideally).

Same service file for all distros is unlikely to be possible, I think,
given the above.

 
 1) set the domain to the system value
 An important setting, but should be done via /etc/dnsmasq.conf when using
 systemd.

It can't be set to the current system domain name that way

DOMAIN_SUFFIX=`dnsdomainname`


 2) use a different configuration file.
 I don’t really see a good reason for that right now, but people who want to do
 that should just copy /lib/systemd/system/dnsmasq.service to
 /etc/systemd/system/dnsmasq.service and change it appropriately.
 
 3) set a couple of options which are needed by the Debian installation,
 without requiring the  user to have them in the configuration file.
 These are the dnsmasq user, and the CONFIG_DIR value.
 So, this is a Debian-specific option which we really need :-/. I guess we have
 no other option than shipping two files with dnsmasq or keeping a
 Debian-specific one in the Debian packaging (the latter sounds better).
 

See above, I'm answering this one point at a time :-)

If possible, I'd like to maintain the functionality of /etc/default
/dnsmasq for the options documented in there, with the possible
expection of the resolvconf one: I guess we still have to fight the
resolvconf battles.


Cheers,

Simon.



-- 
To 

Bug#640095: systemd configuration fails to start dnsmasq

[Simon Kelley]

Michael Stapelberg wrote:
 Hi Simon,
 
 Thanks for your explanations :). My answers follow, a new service file is
 attached.
 
 Excerpts from Simon Kelley's message of 2011-09-05 14:39:42 +0200:
 Dnsmasq needs to be started as root, but it needs the command-line
 argument --user=dnsmasq, to tell it to change to user dnsmasq _after
 binding port 53, etc etc.
 Yep.
 
 The reason for this is security: dnsmasq is handling untrusted network
 data and is theoretically vulnerable to compromise by buffer overflow
 etc. If it happens, much better that an attacker has control of a
 process _not_ running as root. nobody is used in the source because
 that's a non-root, non-real-person user that's available everywhere and
 will therefore work for source installs. For Debian, we make a user just
 for this, since a user that has no writable files, no shell, no home dir
 and is not used for anything else is more secure again. It would be
 possible to patch the source s/nobody/dnsmasq/ but it's easier to do
 this in the startup script than maintain the patch.
 You are partly right, partly wrong. Partly wrong because:
 
 1) nobody has no files at all (find / -uid 65534 brings no results on my
system, also see for example bug #618474 where creation of files owned by
nobody is a serious policy violation)
 2) nobody has no homedir (while 'dnsmasq' has one!)
 
 But partly right because:
 
 3) Indeed, nobody has a shell.
 4) With is not used for anything else I guess you mean that nobody
potentially runs/controls processes.

The bug which originally prompted the dnsmasq user is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338353
which may shed more light.

 
 Therefore, I have added an appropriate comment to the systemd service file and
 added the --user dnsmasq option :).
 
 /var/lib/misc/dnsmasq.leases is the persistent DHCP lease database, it
 has to survive over reboot. It's also opened whilst dnsmasq is still
 root, so isn't owned by user dnsmasq.
 Ah, you are right, it’s owned by root, my mistake.
 
 The only file that's owned by dnsmasq is the directory /var/run/dnsmasq.
 That's done so that the PID file /var/run/dnsmasq/dnsmasq.pid can be
 deleted by dnsmasq as it exits, even though dnsmasq isn't running as
 root then. That location for the PID file isn't the standard one either,
 so gets overridden on the command line.
 Well, we don’t need a PID file when using systemd. In sysvinit it’s mainly 
 used
 for locking and sending signals. systemd supports $MAINPID in the ExecReload=
 command, so we don’t need it for sending signals. Since systemd also knows 
 best
 if a service still lives or not, we don’t need it for that purpose either.
 If a program *really* needs to get the PID, it can easily do that using:
 
 systemctl show -p MainPID dnsmasq.service

My feeling is that the .pid file is there for the use of the systemV
init system, so having no PID file may be an option if dnsmasq is being
controlled by systemd instead. Note that dnsmasq will by default write a
PID file at /var/run/dnsmasq.pid, so this needs to be actively disabled
with --pid-file in this  case.
 
 I am still not quite sure about why we need it and what the effects really 
 are.
 Of course, log messages appear in a different language after setting LANG.
 But what exactly is the behaviour when resolving? Why does the LANG setting 
 of
 my *server* define which answers my clients get?
 It doesn't, it tells dnsmasq what character encoding to expect for
 internationalised domain name strings which appear in configuration
 files on the _server_. By the time they get over the network they've
 been transformed into a network-neutral representation.
 I see. I’ve added an appropriate comment and now read /etc/default/locale in
 the service file.
 
 Same service file for all distros is unlikely to be possible, I think,
 given the above.
 Yeah :-(. Too bad, but well, maybe it works for other services.
 
 It can't be set to the current system domain name that way

 DOMAIN_SUFFIX=`dnsdomainname`
 Hrm, that’s correct. Is that really relevant? For systems where the domain
 often changes, dnsmasq is probably started by NetworkManager anyways. On other
 systems, it’s not too much effort to put the domain name in /etc/dnsmasq.conf.
 
 If you insist, we have two possibilities:
 
 1) Make dnsmasq capable of getting the DNS domain name on its own. It’s not 
 too
much code, I’ve ripped out the appropriate parts of 'hostname', it’s less
than one page of code, see http://p.nnev.de/2017. Not sure if it becomes
even less code when using functions which are in your code-base already.
 
Advantages: You could make that lookup asynchronuous, thus starting dnsmasq
faster (it does not have to wait blockingly on resolving the hostname but
can immediately show up on DBus). Also, we don’t have to use shell in the
boot process just for expanding the parameter.
 
 2) Start /bin/sh -c 'dnsmasq …' in the service file.
 
Advantages: No 

Bug#635383: Does dnsmasq 2.58-2 really fix #635383?

[Simon Kelley]

On 03/09/11 10:16, Jörg Sommer wrote:
 Hello Simon,
 
 I can't see in which way #635383 is related to changes in the resolvconf
 script. Is this bug report number correct? Or should it have been
 #627789?
 
 dnsmasq (2.58-2) unstable; urgency=low
 
* Fix resolvconf script. (closes: #635383)

The bug number is wrong, as you surmise, I was having a bad day. I've
reopened 635383 and reassigned it to virtualbox. The bug that should
have been closed is 639963, and I've closed that by hand. I've fixed the
changelog for the next upload.

 
 Why not set no-poll and send SIGHUP to tell dnsmasq about changes?

The only reason not to is that writes to /etc/resolv.conf other than
from resolvconf would no longer be picked up in a timely manner.

Cheers,

Simon.

 
 Bye, Jörg.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#640095: systemd configuration fails to start dnsmasq

[Simon Kelley]

Michael Stapelberg wrote:
 Hi Sjoerd,
 
 When using systemd starting dnsmasq just hangs and times out.. Also the sysv
 init script seems to have a reasonable amount of functionality that the
 systemd
 one does not have, so i'm not sure if switching now is the right thing.
 Which version of systemd do you use? I tested the service file with systemd 29
 and it works just fine:
 
 michael ~ $ sudo systemctl start dnsmasq.service 
 michael ~ $ systemctl status dnsmasq.service
 dnsmasq.service - A lightweight DHCP and caching DNS server
 Loaded: loaded (/lib/systemd/system/dnsmasq.service)
 Active: active (running) since Fri, 02 Sep 2011 16:25:45 +0200; 700ms 
 ago
Process: 28971 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
 status=0/SUCCESS)
   Main PID: 28973 (dnsmasq)
 CGroup: name=systemd:/system/dnsmasq.service
 └ 28973 /usr/sbin/dnsmasq -k
 
 Can you please do the following?
 
 1) Run strace -o /tmp/strace.log -fF -tt -s2048 -p 1
 2) Run systemctl start dnsmasq.service
 3) Attach the (bzip2'ed) contents of /tmp/strace.log
 
 That will allow us to better see what’s going on.
 
 As for the functionality:
 
  • The init script provides support for the ENABLED flag in
/etc/default/dnsmasq, which you don’t need when using systemd -- systemd
supports enable/disable: systemctl disable dnsmasq.service
 
  • It runs dnsmasq as user 'dnsmasq' - I missed this one and we can easily add
it to the service file (User=dnsmasq in the [Service] section).
Simon, what do you think? Is running dnsmasq as user dnsmasq by default a
sensible decision?

Yes, it is.

 
  • The resolvconf stuff I regard as obsolete when using NetworkManager or some
other configuration tool.

Hmm, I'm not going to argue that one ;-)

 
  • LANG gets set if it is defined in /etc/default/locale. I’m not sure what 
 the
effects of that are (I don’t set LANG on my system, I prefer the LC_*
settings). Does it somehow affect the behaviour of dnsmasq when resolving?
If so, how?

It affects the charset used when reading internationalised domain names
from configuration files and the translation used for messages. It's needed.

 
  • As for configuration via flags (all these environment variables): In
general, the systemd way is to configure programs in their own 
 configuration
files, so /etc/dnsmasq.conf is the place where all this should be 
 configured.
 
Simon: Are there any options which are *only* available via command line 
 and
*not* in /etc/dnsmasq.conf that are reasonable for users to change? If so,
which ones?

There are none which can't be changed from the configuration file, and
most of the environment variables are indeed obsolete: The non-obsolete
ones are documented in the /etc/default/dnsmasq file.

1) set the domain to the system value
2) use a different configuration file.
3) set a couple of options which are needed by the Debian installation,
without requiring the  user to have them in the configuration file.
These are the dnsmasq user, and the CONFIG_DIR value.

4) ENABLED and IGNORE_REOLVCONF, which would seem to be not relevant in
a systemd world.
 
 Did I miss any functionality?


The initscript sleeps for a couple of seconds between stopping and then
starting the daemon on a restart. That is necessary.

Cheers,

Simon.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639963: dnsmasq: invalid format character when using vpnc

[Simon Kelley]

This is fixed in 2.58-2, just uploaded, but the changelog closes a
different bug by mistake, I'm not having a good day.

Closing this bug manually.

Cheers,

Simon.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#635383: dnsmasq no longer replies to DHCP requests

[Simon Kelley]

Paul Millar wrote:

 If possible, could you reassign this ticket?
 

Reassigned to virtualbox, after a small false start where it got
accidentally closed.


Cheers,

Simon.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#635383: dnsmasq no longer replies to DHCP requests

[Simon Kelley]

I'm not aware of this bug having been manifest anywhere except here and
I can't progress it without further information from the submitter.
Since the package is working fine for almost everyone, I'm downgrading
this to normal. It's certainly not release critical.

Cheers,

Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#638136: Add utility programs dhcp_release and dhcp_lease_time from contrib/wrt

[Simon Kelley]

Monty Taylor wrote:
 Package: dnsmasq
 Version: 2.57-1
 
 Hi! We'd love to get dhcp_release and dhcp_lease_time added to the
 dnsmasq package so that we can use them in some supporting scripts
 around OpenStack.

Seems reasonable.

 I've attached a debdiff that does this. Is there
 anything else you'd like to see to be ok with this?

My first thought is that they probably should be renamed as
dnsmasq_release and dnsmasq_lease_time to avoid namespace pollution, but
actually, both scripts should work with any DHCP server, so maybe not.
In fact, I wonder if they should go in their own binary package as
they're actually useful without dnsmasq. Comments?

The usage instructions contained in comments in the source file should
really be converted into minimal man pages.


Cheers

Simon.

 
 Thanks!
 Monty
 




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#635383: dnsmasq no longer replies to DHCP requests

[Simon Kelley]

Paul Millar wrote:

 As a shot-in-the-dark, I've checked for dnsmasq reply packets on the other
 interfaces (lo, eth0, br1).  There's no sign of the reply packets.
 
 This used to work, so it looks like a bug introduced with a recent upgrade of
 the dnsmasq package.
 

There have been no recent changes to the code-paths involved that I can
point a finger to, and this sort of setup depends on so much setup
external to dnsmasq that I'm inclined to look elsewhere first. Can you
downgrade dnsmasq and point me to a version which works _now_? Also, the
output of strace in the dnsmasq process during the attempted lease
aquisition would be useful.

Cheers,

Simon.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630688: Openresolv doesn't work with dnsmasq

[Simon Kelley]

On 17/06/11 07:34, Roy Marples wrote:

On Fri, 2011-06-17 at 00:02 +0200, Juliusz Chroboczek wrote:

The point I'm making is that replacing dhcpd with dhcpcd5 broke
a working system by replacing resolvconf with openresolv.  I'd like to
clarify whose bug that is:


...


No, it worked out of the box.


Well, that is interesting because as far as I can tell, resolvconf does
NOT ship with support for dnsmasq and dnsmasq does NOT ship with support
for resolvconf.

Can you tell me which package owns a file in /etc/resolvconf/update.d
which updates dnsmasq?



It's the dnsmasq package.

Simon.


Thanks

Roy







--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken

[Simon Kelley]

Robert Edmonds wrote:
 Simon Kelley wrote:
 Some implementations of gethostbyname, given the name com or
 mycomputer will attempt to look it up in the DNS with just such a
 query, thus wasting upstream bandwidth and leaking internal network
 information.
 
 hm, so?  a heuristic based solely on the number of labels in the qname
 is a rather blunt tool here.  far better to fix the misconfigured client
 than to guess at what the stub resolver might have meant.

No argument, but sometimes easier to implement the fix in the DNS
forwarder than to alter many clients which may be heterogeneous and/or
not under the admin's control. Pragmatism. Dnsmasq supplies a tool which
 is useful, but not perfect.
 
 It's sometimes useful to pre-empt that, so there's a configuration
 option. It's not the default behaviour.  NXDOMAIN is wrong here,
 NODATA would be better, but historically dnsmasq was fielding queries
 from stub resolvers, so nobody every noticed the difference.
 
 i disagree.  the existence of an option that pre-empts queries for
 one-label qnames (and the comment at the top of the example config file
 encouraging one to turn it on) harms interoperability.

There should be a warning, certainly. What do you think about moving to
returning NODATA? I really don't want stuff existing downstream caching
the idea that the whole .com domain doesn't exist.

 
 i'd recommend deprecating and removing the domain-needed option
 altogether but if you're not going to do that i'd at least make the
 filtering logic conditional.  from looking at the source it appears
 qtype=NS is exempted from the filter, maybe you could invert the logic
 and make it apply only to qtype=A and perhaps qtype=.
 
I'm tempted by the A/ only solution, the alternative is to add DS to
the list of RRtypes exempted. Any others I've not thought of?

Cheers,

Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken

[Simon Kelley]

Robert Edmonds wrote:

Robert Edmonds wrote:

so unbound forwarding to 4.2.2.1 works, but unbound forwarding to
dnsmasq which forwards to 4.2.2.1 does not work.  so dnsmasq is not
fully transparent when forwarding between a validating forwarder and a
validating recursive nameserver.


ugh, i meant DNSSEC-conformant recursive nameserver here, not
validating recursive nameserver.  the level3 open recursives (4.2.2.X)
don't perform validation.



A quick query on the dnsmasq configuration in use here: is the 
--domain-needed flag set in /etc/dnsmasq.conf? I think that's causing 
the problem because the DS query for .com hits the filter. There are 
already exceptions on this filter for SOA and NS queries, the DNSSEC era 
 requires that DS queries are added to that list.


Assuming I've diagnosed this right, removing --domain-needed is a quick 
and simple workaround.




Cheers,

Simon.








--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken

[Simon Kelley]

Robert Edmonds wrote:

Simon Kelley wrote:

Robert Edmonds wrote:

Robert Edmonds wrote:

so unbound forwarding to 4.2.2.1 works, but unbound forwarding to
dnsmasq which forwards to 4.2.2.1 does not work.  so dnsmasq is not
fully transparent when forwarding between a validating forwarder and a
validating recursive nameserver.

ugh, i meant DNSSEC-conformant recursive nameserver here, not
validating recursive nameserver.  the level3 open recursives (4.2.2.X)
don't perform validation.


A quick query on the dnsmasq configuration in use here: is the
--domain-needed flag set in /etc/dnsmasq.conf? I think that's
causing the problem because the DS query for .com hits the filter.
There are already exceptions on this filter for SOA and NS queries,
the DNSSEC era  requires that DS queries are added to that list.

Assuming I've diagnosed this right, removing --domain-needed is a
quick and simple workaround.


from the man page:

   -D, --domain-needed
  Tells dnsmasq to never forward queries for plain names,
  without dots or domain parts, to upstream nameservers. If
  the name is not known from /etc/hosts or DHCP then a not
  found answer is returned.

um, i think i know what a plain name, without dots or domain parts is,
but dnsmasq is a DNS server and deals with wire-format domain names,
right?  does dnsmasq seriously respond with NXDOMAIN to queries for the
wire-format name \x03com\x00 (presentation format: com.) because it
has only a single label?  that is beyond broken.



Some implementations of gethostbyname, given the name com or 
mycomputer will attempt to look it up in the DNS with just such a 
query, thus wasting upstream bandwidth and leaking internal network 
information. It's sometimes useful to pre-empt that, so there's a 
configuration option. It's not the default behaviour.  NXDOMAIN is wrong 
here, NODATA would be better, but historically dnsmasq was fielding 
queries  from stub resolvers, so nobody every noticed the difference.


Cheers,

Simon.






--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken

[Simon Kelley]

Robert Edmonds wrote:


ok, now that i look in the dnsmasq debian changelog i see this option
started defaulting to disabled in 2006.  still...



Probably best not to look at filterwin2k then. Not the finest hour.


Simon.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#628003: Improved yet again

[Simon Kelley]

Thomas Hood wrote:
 I now remember that we aren't supposed to assume that invoke-rc.d
 is present.  Here's a new version of the script.  // Thomas
 
 #!/bin/sh
 # Resolvconf packaging event hook script for the dnsmasq package
 
 restart_dnsmasq() {
 if which invoke-rc.d /dev/null 21 ; then
 invoke-rc.d dnsmasq restart
 elif [ -x /etc/init.d/dnsmasq ] ; then
 /etc/init.d/dnsmasq restart
 fi
 }
 
 case $1 in
   install) restart_dnsmasq ;;
 esac
 
 
 

ACK. I'm surprised that invoke-rc.d isn't universal now, but if the
rules is there, we must obey.


Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#628003: Improved script

[Simon Kelley]

Thomas Hood wrote:
 Sorry to bother you about this again, but it occurs to me now
 that this would be even better:
 
 
 #!/bin/sh
 # Resolvconf packaging event hook script for the dnsmasq package
 case $1 in
   install) invoke-rc.d dnsmasq restart ;;
 esac
 
 
 That is, instead of restarting dnsmasq on removal of resolvconf,
 do nothing.
 
 When resolvconf is removed it leaves the contents of both
 /etc/resolv.conf and /var/run/dnsmasq/resolv.conf unchanged.
 
 If dnsmasq isn't restarted then it will carry on happily
 resolving names using the nameserver addresses provided to it
 by resolvconf in the past.  When dnsmasq is restarted, however,
 it notices that resolvconf is gone and no longer reads
 /var/run/dnsmasq/resolv.conf.  /etc/resolv.conf contains only
 127.0.0.1 so name service is kaput from that point on.
 
 I see no reason to hasten the arrival of this unhappy fate,
 do you?
 
 (It is precisely because of this problem that resolvconf 1.55
 puts up a debconf note on removal, advising the admin to reboot
 the machine.
 
 A theoretically more correct solution to this problem is
 for suppliers of nameserver information to add their info
 back into /etc/resolv.conf when resolvonf is removed.  But
 we know that this will never happen.)

Hmmm. Do we just detonate the bomb, or leave it around to explode later?

I think, given the debconf note telling the admin about the bomb, later
is probably better. Change made.


Cheers,

Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#628003: Please add resolvconf packaging-event hook script

[Simon Kelley]

Thomas Hood wrote:
 should /etc/resolvconf/packaging-event.d/dnsmasq be a conffile?
 
 Good question!
 
 I am a bit embarrassed to have to admit that I didn't really
 consider this issue.  I just assumed that the hook scripts
 should be conffiles (as the update scripts are) and located
 in /etc/.  Whereas I now (thinking about it) realize that they
 should probably be non-conffiles and located in /usr/lib/,
 since they are bits of packaging plumbing which get used once
 or twice in the life of an installation and most probably don't
 need to be customized by the admin.
 
 The same could be said of many scripts currently in /etc, starting
 with initscripts.  But that doesn't mean we should do the same.
 
 I will change the infrastructure in the upcoming resolvconf 1.55
 so that the directory /usr/lib/resolvconf/dpkg-event.d is used
 instead of the /etc location mentioned previously.
 
 Please consider my wish revised accordingly.  I.e., please include
 the script as /usr/lib/resolvconf/dpkg-event.d/dnsmasq.
 

Good answer!

It's done for dnsmasq_2.58


Cheers,

Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#627986: dnsmasq: does not restart with configuration syntax check due to bad hex constant

[Simon Kelley]

Vincent van Leeuwen wrote:
 Package: dnsmasq
 Version: 2.57-1
 Severity: important
 
 
 Lines like the following in /etc/dnsmasq.conf cause dnsmasq 2.57 to fail to
 restart:
 
 dhcp-host=00:11:d8:a8:58:21,10.32.1.3,tag:lan,tijger
^^^

There's an error in that line, it should probably be

dhcp-host=00:11:d8:a8:58:21,10.32.1.3,set:lan,tijger


dhcp-host can set tags, but not test them: from the man page

--dhcp-host=[hwaddr][,id:client_id|*][,set:tag][,ipaddr][,hostname][,lease_time][,ignore]


 /var/log/daemon.log reports:
 
 May 26 10:28:14 ur-quan dnsmasq[30846]: bad hex constant at line 228 of 
 /etc/dnsmasq.conf
 May 26 10:28:14 ur-quan dnsmasq[30846]: FAILED to start up
 
 Downgrading to 2.55 (from squeeze) resolves the issue. Commenting the line
 above causes dnsmasq 2.57 to fail on other similar lines.
 


So, 2.55 - 2.57 has gone from not reporting an error, to reporting a
misleading error. That's progress, of a sort. I'll try and make the
message less misleading in the next release.


Cheers,

Simon.






-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#628003: Please add resolvconf packaging-event hook script

[Simon Kelley]

Thomas Hood wrote:
 Package: dnsmasq
 Severity: wishlist
 
 Please add the hook script /etc/resolvconf/packaging-event.d/dnsmasq.
 
 The purpose this script is to cause dnsmasq to take notice of
 the installation or removal of the resolvconf package.  If resolvconf
 has been installed, for example, then dnsmasq should register its
 IP address with resolvconf.
 
 See below for an except from resolvconf's README file giving
 general information about resolvconf packaging-event hook scripts.
 
 For dnsmasq the following script should suffice.
 
 #!/bin/sh
 # Resolvconf packaging event hook script for the dnsmasq package
 case $1 in
   install|remove) invoke-rc.d foo restart ;;
 esac
 

should /etc/resolvconf/packaging-event.d/dnsmasq be a conffile?
/etc/resolvconf/update.d/dnsmasq is.

Simon.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#627789: Postscript

[Simon Kelley]

Thomas Hood wrote:
 P.S.
 
 The patched script updates the mtime by doing:
 
 echo   $TMP_FILE
 
 This is less than idea, since it adds a useless CR
 to the end of the file.  I tried:
 
 :  $TMP_FILE
 
 which doesn't add anything to the file, but this failed
 to change the mtime.
 
 Perhaps you can think of something better.

cp file file.new
mv file.new file

has the desired effect and atomically changes the mtime without a race
window where the contents of file may be invalid.

Simon.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org