Olaf van der Spek wrote:
Users that install dnsmasq directly probably like it to be started by
default, so just disabling it by default isn't a solution.
Could you elaborate? The /etc/default/dnsmasq file installed by the
package enables dnsmasq by default.
Simon.
--
To UNSUBSCRIBE,
Stanisław Pitucha wrote:
> Package: dnsmasq
> Version: 2.52-1
> Severity: important
> Tags: squeeze
>
> I tried to set up dnsmasq to handle cache queries. The only changes to
> the default config are: cache-size (1000), neg-ttl (120), interface=lo,
> bind-interfaces, all-servers.
>
> The SRV quer
Marc Pignat wrote:
Package: dnsmasq
Version: 2.52-1
Severity: normal
*** Please type your report below this line ***
Hi all!
I have 2 nameservers and dnsmasq query the 2 nameservers. I think it should
only query one.
Configuration files and tcpdump of the problem attached.
Best regards
Marc
Marc Pignat wrote:
> Hi Simon!
>
> Thanks you for the explanation!
>
> I have re-done the test, and it runs almost as you said.
> The request is also done in parallel on every server when the ttl is gone
> (before the 30 seconds).
> My ISP has set a 10 seconds ttl to their hosts...
If the TTL h
Eric Cooper wrote:
> Package: dnsmasq
> Version: 2.52-1
> Severity: normal
>
> I have a second IP address associated with eth0 (the "virtual address" used
> by the ucarp daemon):
>
> # ip addr show dev eth0
> 3: eth0: mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 1000
> link/eth
Eric Cooper wrote:
>> The current development version of dnsmasq adds an option which
>> tells dnsmasq to assume a named secondary interface instead, which
>> should fix this. Are you in a position to build from source and test
>> this?
>
> I built dnsmasq-2.53test22 in a lenny chroot and tried it
Eric Cooper wrote:
>> you need is to add
>>
>> bridge-interface=eth0:ucarp, eth0
>>
>> to /etc/dnsmasq.conf. Which should treat any DHCP packets arriving on
>> the eth0/eth0:ucarp physical interface as arriving at eth0:ucarp.
>
> OK, the DHCP service is working on that interface, but it still puts
Chris Carr wrote:
> On Tue, 2010-02-02 at 22:45 +0000, Simon Kelley wrote:
>> Chris Carr wrote:
>>> On Tue, 2010-02-02 at 21:40 +, Simon Kelley wrote:
>>>> My guess that this is something like vpn provides network and depends on
>>>> $named
>&g
Chris Carr wrote:
> On 22/03/2010 20:37, Simon Kelley wrote:
>> Chris Carr wrote:
>>> On Tue, 2010-02-02 at 22:45 +, Simon Kelley wrote:
>>>> Chris Carr wrote:
>>>>> On Tue, 2010-02-02 at 21:40 +, Simon Kelley wrote:
>>>>>>
Chris Carr wrote:
>
> Ironically the problem was the opposite: the Provides: line in
> /etc/init.d/openvpn said openvpn, but I had added a dependency on "vpn" to
> the Required-Start line in /etc/init.d/dnsmasq. Once I changed this to
> "openvpn", it worked.
>
> But my main concern is: should the
Roy Marples wrote:
I have the dhcpcd5 package installed and running. It seems to be
behaving itself and looks like a good start.
Some observations of things that should be looked at.
. The source package should be dhcpcd5, not dhcpcd, since the existing
source package is dhcpcd
. The initscript
Gianluigi Tiesi wrote:
> Package: dnsmasq
> Version: 2.55-1
> Severity: normal
> Tags: sid
>
> Often when the package is upgraded I get
>
> CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
>
> in /etc/default/dnsmasq
>
> it's not really problematic since /etc/dnsmasq.d is picked anyway
Roy Marples wrote:
> On 15/06/2010 21:13, Simon Kelley wrote:
>> I have the dhcpcd5 package installed and running. It seems to be
>> behaving itself and looks like a good start.
>>
>> Some observations of things that should be looked at.
>>
>> . The sourc
Gianluigi Tiesi wrote:
> a bit esotic as option but anyway you can close the bug as invalid
>
>
Not as wierd as the bugs that would ensue if it wasn't there! Note that
this comes from /etc/default/dnsmasq and it's explained in comments there.
Will close the bug. Thanks for your help.
cheers
martin f krafft wrote:
also sprach Debian Bug Tracking System [2009.02.01.1636
+0100]:
Closing this since it's behaving as-designed.
It's designed to leave stray PID files around?
It's designed to drop root access, and as a side-effect of that it can't
unlink files in /var/run.
Cheers,
martin f krafft wrote:
reopen 508560
thanks
also sprach Simon Kelley [2009.02.01.1921 +0100]:
It's designed to drop root access, and as a side-effect of that it can't
unlink files in /var/run.
Then the files in /var/run should be owned by the user to which the
daemon switches.
Max Kirillov wrote:
Package: dnsmasq
Version: 2.45-1
Severity: important
If setcap() call at startup fail (for example, under
OpenVZ), dnsmasq reports an error and do not start:
# /etc/init.d/dnsmasq start
Starting DNS forwarder and DHCP server: dnsmasq
dnsmasq: setting capabilities failed: Op
Soren Hansen wrote:
Package: dnsmasq
Version: 2.41-2
Severity: normal
Tags: patch
User: [EMAIL PROTECTED]
Usertags: origin-ubuntu hardy ubuntu-patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In Ubuntu, we've applied the attached patch to make the init script lsb
compliant.
We thought you m
Jeremy Laine wrote:
Package: dnsmasq
Version: 2.41-2
Severity: normal
Tags: patch
When dnsmasq replies to DHCP requests containing a Relay Agent Information
option, it should include the Relay Agent Information in the reply.
Unfortunately, this is not the case because dnsmasq does the following
Jeremy Lainé wrote:
> I have just picked up and tried your test release, and it works fine for
> me, both for a DHCPOFFER and a DHCPACK.
>
> Mar 31 11:46:44 blini dnsmasq[9536]: sent size: 6 option: 82:agent-id
> 01:04:00:00:00:03
Great!
>
> Any idea how can I trigger a DHCPNAK to test that c
Bas Wijnen wrote:
Package: dnsmasq
Version: 2.41-2
When installing dnsmasq and resolvconf, the nameserver is set to
127.0.0.1, and dnsmasq tries to use that. This obviously doesn't work.
/etc/dnsmasq.conf should therefore by default set
resolv-file=/var/run/dnsmasq/resolv.conf
if resolvconf is
Russ Allbery wrote:
> I think it is a bug in dnsmasq, although it may be a rather hard one to
> fix. I looked at the init script and it just starts the daemon via the
> normal way, so apparently the daemon startup completes before the service
> is entirely ready (which is not atypical for daemons
Brent S. Elmer Ph.D. wrote:
> On Thu, 2010-12-23 at 09:38 +0000, Simon Kelley wrote:
>
>> It's not as simple as it seems (is it ever?). Dnsmasq _doesn't_ return
>> before the service is ready: by the time the initial process exits, the
>> long-lived server p
Brian Vanderburg II wrote:
> Package: dnsmasq
> Version: 2.45-1+lenny1
> Severity: important
>
>
> When running dnsmasq command with command line arguments, specifying a
> custom pid file does not work if one types '--pid-file /path/to/pid'.
> It does work if one types '-x /path/to/pid'. It also
Timo van Roermund wrote:
> Package: dnsmasq Version: 2.55-1 Severity: wishlist
>
>
> Recently, there is a lot of fuzz around DNS rebinding attacks. I
> think it is a good idea to add the 'stop-dns-rebind' option to the
> default configuration file for Debian in order to prevent such
> attacks.
>
Matthias Wolle wrote:
Package: dnsmasq
Version: 2.45-1+lenny1
Severity: normal
namerserver from resolvconf are not updated
dnsmasq update script for resolvconf uses /lib/resolvconf/list-records.
list-records needs /etc/resolvconf/resolv.conf.d as current directory.
list-records:
# Print, one p
David Paleino wrote:
block 563974 by 551034
thanks
Hello,
On Saturday 17 October 2009 11:26:49, Dennis Schridde wrote:
Version 5.1.2 was released.
I just saw 5.1.4 is available on the website.
Simon, I'm packaging dhcpcd-dbus (ITP #563974), and it needs at least 4.99.14
to work. What are y
Tollef Fog Heen wrote:
Package: dnsmasq
Version: 2.47-3
Severity: normal
dnsmasq incorrectly mangles 10.1.2. into 10.1.0.2:
dig +short 10.1.2. @10.63.22.1
10.1.0.2
(10.63.22.1 is a dnsmasq server)
Compare with a bind server:
dig 10.1.2. @localhost
[...]
This occurs because dnsmasq is
Tollef Fog Heen wrote:
]] Simon Kelley
| The name (10.1.2.) gets fed to inet_addr, which (possibly
| surprisingly) considers it be a valid representation of 10.1.0.2 .
Oh, that's not particularly surprising. I'd rather have it be 10.1.2.0,
but POSIX doesn't allow that.
| Th
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
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
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.or
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
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 bo
Thomas Hood wrote:
> On 25/05/11 14:46, Simon Kelley wrote:
>> 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.
>
>
> The current cod
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 erro
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
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
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 res
Thomas Hood wrote:
> $ for F in 1 2 3 ; do :>$F ; done
> $ ls -l --full-time
> total 0
> -rw-r--r-- 1 jdthood jdthood 0 2011-05-24 17:32:19.04195 +0200 1
> -rw-r--r-- 1 jdthood jdthood 0 2011-05-24 17:32:19.04195 +0200 2
> -rw-r--r-- 1 jdthood jdthood 0 2011-05-24 17:32:19.04195 +0200 3
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 chang
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 re
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
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 diff
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 Mai
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 yo
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
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
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 I
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
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.
l
> 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
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
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
back 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 add
g --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 o
equesting 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 y
201 - 257 of 257 matches
Mail list logo
