*** This bug is a duplicate of bug 1042275 ***
https://bugs.launchpad.net/bugs/1042275
On 06/10/15 11:08, Alkis Georgopoulos wrote:
> Hi Robie,
>
> while this also happens in Debian, the use case is more common in Ubuntu,
> because NetworkManager is patched to use a spawned dnsmasq instance
I'm sympathetic to aim, but this solution is rather fragile, there are
plenty of ways to get dnsmasq to read configuration from places other
than /etc/dnsmasq.conf and /etc/dnsmasq.d/*, for instance adding
conf-file=/path/to/more/configuration
to the existing config files.
It's also possible to
What configuration was in use to get that exact error message. If
dnsmasq is binding the wildcard address (0.0.0.0), I'd expect to see a
message like
dnsmasq: failed to create listening socket for port 53
Whilst if dnsmasq is configured to bind the hosts addresses, I'd expect
to see something li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The underlying problem is that 2.73 accidentally change the meaning of
dnsmasq --conf-file
from "don't read any conf-file" to "read the default conf-file".
This is a bug, not a feature, and I've just committed a fix to git.
Cheers,
Simon.
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thomas, this is fixed upstream. I'll add (LP: #1416895) to the
changelog.
Cheers,
Simon.
On 01/02/15 21:04, Thomas Hood wrote:
> Confirmed that the bug affects 2.72-2.
>
> $ cat /etc/dnsmasq.conf | tail -n 2 # Include all files in a
> directory
I think the following, much simpler, patch should solve the problem.
Simon.
diff --git a/src/dbus.c b/src/dbus.c
index 93c597c..4696442 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -156,13 +156,16 @@ static void dbus_read_servers(DBusMessage *message)
dbus_message_iter_get_basic(&it
On 08/05/14 22:18, James Hunt wrote:
> A bit of debugging shows that the culprit is blockdata_expand() which is
> being called via blockdata_init(). The issue seems to be that
> blockdata_expand() is passed a parameter of zero. That function then
> mallocs zero bytes (successfully seemingly), the p
Annoyingly, I still can't reproduce this on the systems I have
available. On a system where the problem occurs, can it be reproduced
when dnsmasq is started standalone with the same command-line
parameters? The idea situation would be to get the bug to show up in a
dnsmasq instance running under gd
On 02/05/14 12:00, Adam Smith wrote:
> LSOF output below. I tried to put a strace in init.d but failed
> miserably
>
> lsof | grep dnsmasq
>
> dnsmasq 1430 dnsmasq cwd unknown
>/proc/1430/cwd (readlink: Permission denied)
> dnsmasq 1430
On 01/05/14 07:45, Colin King wrote:
> I'm seeing this too, strace show it spinning on:
>
> select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0])
> recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket)
> accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket)
> select(8
On 27/04/14 18:53, Dave Gilbert wrote:
> Hi Simon,
> 1) Apparently so - I just rebooted the vm to see if I could repeat it, and
> it was already stuck at 100% and non-responsive.
> (and blueskaj who confirmed it was seeing the same problem on irc)
> 2) /usr/sbin/dnsmasq --no-resolv --kee
On 27/04/14 18:53, Dave Gilbert wrote:
> Hi Simon,
> 1) Apparently so - I just rebooted the vm to see if I could repeat it, and
> it was already stuck at 100% and non-responsive.
> (and blueskaj who confirmed it was seeing the same problem on irc)
> 2) /usr/sbin/dnsmasq --no-resolv --kee
This is useful, thanks. A couple of questions:
1) Is this easily reproducible?
2) Could you tell me exactly what command-line flags dnsmasq is being
started with?
Cheers,
Simon.
On 27/04/14 18:02, Dave Gilbert wrote:
> Public bug reported:
>
> I hit a case where dnsmasq was running at 100%
On 12/03/14 13:24, fish wrote:
> Public bug reported:
>
> Hi,
>
> I'm running dnsmasq in a (docker) container. If I tried to start dnsmasq
> without arguments and it failed with:
>
> dnsmasq: setting capabilities failed: Operation not permitted
>
> Guess this is expected because the contain
On 09/11/13 19:07, Philip Potter wrote:
> I agree that the postinst is a better place than the init script to run
> "resolvconf -u".
>
> I'm not sure that it should be conditional on IGNORE_RESOLVCONF though -
> given that the update script will be run next time anything touches
> resolvconf, what'
On 27/09/13 10:37, Franck wrote:
> Public bug reported:
>
> Since I upgraded to Saucy, my local dnsmasq instance seems to lose its
> primary dns server and fallback to secondary dns.
> Since the primary dns is a dnsmasq instance that knows of local servers, and
> the secondary one is external, my
Fixed in developement version.
thttp://hekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=edf0bde0c6837b010560c40e6b74d2f67b64da09
Simon.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bug
On 24/07/13 20:33, Thomas Hood wrote:
> Hi Simon,
>
> I think we've established that the submitter is having a problem with
> dnsmasq server, not with NetworkManager-controlled dnsmasq. So it would
> be interesting to know if clear-on-reload fixes the submitter's problem.
> (He already said that no
> Whatever is going on, it's more complex. Maybe the problem is that
> dnsmasq gets a negative answer from some upstream server, and then
> gets a new upstream server which has the correct information? The
> solution then is --clear-on-reload but I think NM sets that?
but --clear-on-reload
On 08/07/13 15:02, Thomas Hood wrote:
> What do you think, Simon?
>
> ** Changed in: dnsmasq (Ubuntu)
> Status: Incomplete => New
>
I'm confused: dnsmasq won't cache a negative answer if it has no
upstream servers. To cache a negative answer it has to _receive_ a
negative answer (and th
On 15/02/13 19:52, Marc Deslauriers wrote:
> I was waiting for 2.66 to come out.
>
> Simon, is a 2.66 release planned soon?
>
Probably not soon. There are no current showstopper issues, but there's
a lot of new code over 2.65, so it will need a reasonably long
release-candidate period to get it
On 15/02/13 18:52, Steve Langasek wrote:
> On Fri, Feb 15, 2013 at 06:35:40PM -0000, Simon Kelley wrote:
>> On 15/02/13 18:00, Steve Langasek wrote:
>>> Public bug reported:
>
>>> On a raring system, the dnsmasq instance spawned by libvirt is not
>>>
On 15/02/13 18:00, Steve Langasek wrote:
> Public bug reported:
>
> On a raring system, the dnsmasq instance spawned by libvirt is not
> forwarding DNS requests to the upstream resolver. dnsmasq is run as:
> /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
>
Steve, what version
On 06/02/13 09:18, Thomas Hood wrote:
> [...cont'd after "in order to fix"...] bug #1072899, dnsmasq will
> have to be enhanced such that proposition #1 is true. But we can
> discuss the details of that in bug #1072899.
>
> There is a close analogy between the problem here (bug
> #1003842) and a
On 06/02/13 08:59, Thomas Hood wrote:
> Hi Simon.
>
> Before I forget to ask: can you please update dnsmasq(8) to include
> under "--strict-order" a description of what happens when nameserver
> addresses are passed in via D-Bus instead of via a file?
>
> You wrote,
>> you can very easily provide
Belay my previous comment about 1072899, it looks like network manager
is losing the second server before it ever gets to dnsmasq. Not a
dnsmasq problem.
Simon.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
http
On 04/02/13 22:05, Thomas Hood wrote:
> Simon in #49:
>> It doesn't work [...] the order of servers given to the DBus
>> interface isn't preserved internally
>
> Aha, so the answer to my question
>
>> Will switching on strict-order have the same effect
>> now that nameserver addresses are sent over
On 04/02/13 15:36, Sergio Callegari wrote:
> On 04/02/2013 15:40, Simon Kelley wrote:
>> On 03/02/13 07:48, Thomas Hood wrote:
>>>> there's still the unresolved question
>>>> of whether re-enabling --strict-order
>>>> will suffice as a workaroun
On 03/02/13 07:48, Thomas Hood wrote:
>> there's still the unresolved question
>> of whether re-enabling --strict-order
>> will suffice as a workaround, since
>> 12.10 relies on DBus to populate the
>> nameservers. Is there any extra
>> information on this?
>
> Please try it and report back. :-)
On 29/10/12 21:50, Glenn Coombs wrote:
> The nm-dns-dnsmasq.conf file only shows information relating to the 1st
> server - it seems to have totally ignored the 2nd server:
>
> $ cat /var/run/nm-dns-dnsmasq.conf
> server=/kl.imgtec.org/192.168.15.221
> server=/79.168.192.in-addr.arpa/192.168.15.221
On 17/08/12 19:26, Mathieu Trudel-Lapierre wrote:
> Any news about this?
>
> There's actually multiple issues here; one of them being that loopback
> probably isn't ready yet, which is something we fixed in NetworkManager
> (which had the same issue) by depending on it through upstart before
> star
On 27/07/12 16:10, Launchpad Bug Tracker wrote:
> This bug was fixed in the package dnsmasq - 2.62-3ubuntu1
>
> ---
> dnsmasq (2.62-3ubuntu1) quantal; urgency=low
>
>* debian/rules: install the dnsmasq dbus configuration in dnsmasq-base,
> since
> users of the standalone binar
>Simon, do you think that dnsmasq could misbehave as described here?
The only way I can see for this to occur is if a DNS server is return wrong (ie
NXDOMAIN or NODATA) answers, no answer shouldn't be a problem.
I suggest adding --log-queries to the dnsmasq configuration to try and
get a handle
On 20/06/12 10:56, Thomas Hood wrote:
> I can imagine that it will take a lot of care to avoid introducing races
> inside dnsmasq.
It's OK: notification of new interfaces comes via netlink, so it gets
synchronised via the select() call just like everything else.
Have I mentioned yet that Simon i
On 19/06/12 10:10, Chris Halse Rogers wrote:
> Additionally, I'd like to know what the likely impact of adding bind-
> interfaces to dnsmasq is on users. What (if anything) will break on
> users' systems?
>
Three things change.
1) Dnsmasq loses the ability to provide service on dynamically crea
On 18/06/12 21:08, Thomas Hood wrote:
> @Simon: This is pretty much what I had in mind (comment #88) as a long-
> term solution. How difficult do you think that this would be?
Don't know. I'm working on it now: seems to be behaving:
dnsmasq: new IPv4: 192.168.3.1
dnsmasq: new IPv6: fe80::f0f6:48
On 18/06/12 18:11, Thomas Hood wrote:
> Hi Stéphane,
>
> Changing the default of dnsmasq to bind-interfaces wouldn't have been a
> very good solution because some people run dnsmasq without installing
> those other packages and rely upon the "unbound" mode. The implemented
> solution is better be
On 15/06/12 15:01, Thomas Hood wrote:
>> -- Solvable by moving nm-dnsmasq to another port:
> There's one more snippet after this dealing with the IPv6 case. That
> should be it. Any obvious problems I'm overlooking?
>
Applications that don't use the libc resolver? I don't know if such
exist be
On 15/06/12 14:54, Christian Parpart wrote:
> Hey, thanks, and now I also found this one:
>
> https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898
>
> which is exactly what I was talking about (interesting that I didn't
> find earlier).
>
> However, the last commenter says he's pulling
On 15/06/12 08:04, Thomas Hood wrote:
> Alkis: This relies on the assumption that NM's configuration text can be
> dropped in alongside whatever other configuration text is present and
> that dnsmasq will still work properly. This assumption is, er,
> questionable.
There was an attempt, some time
On 15/06/12 10:19, Thomas Hood wrote:
> $ cat /run/nm-dns-dnsmasq.conf
> server=/17.172.in-addr.arpa/172.17.1.2
> server=192.168.1.254
> server=...
>
> The first "server=" line reflects the fact that I am connected to a VPN.
> This can't be expressed in resolv.conf syntax.
FYI only,
It's possib
On 14/06/12 16:06, Thomas Hood wrote:
> @Alkis: IIUC dnsmasq in bind-interfaces mode will not start to listen on
> any addresses assigned to interfaces after dnsmasq has started. So,
> yes, she would have to restart standalone dnsmasq if she wants it to
> listen on those newly assigned addresses.
On 13/06/12 11:07, Thomas Hood wrote:
> OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
> as follows.
>
> 1. Either we accept that nm-dnsmasq is incompatible with every standalone
> nameserver and enforce this in a better way;
> 2. or we force every standalone nameserver i
On 13/06/12 11:07, Thomas Hood wrote:
> OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
> as follows.
>
> 1. Either we accept that nm-dnsmasq is incompatible with every standalone
> nameserver and enforce this in a better way;
> 2. or we force every standalone nameserver i
On 12/06/12 20:31, Thomas Hood wrote:
> (Executive summary of the following: I think we should fix this by
> making nm-dnsmasq listen at ::1.)
>
> Thanks for your much-needed help, Simon.
>
> It is good to know that the "except-interface" avenue is available. We
> want, however, to be able to enjo
On 12/06/12 11:24, Thomas Hood wrote:
> Hmm, just tested this myself. You can't use "except-interface=lo"; it
> seems you have to use "listen-address=10.1.2.3". Perhaps Simon knows a
> better way.
>
If you want to listen on an address which doesn't appear on an interface
(ie 127.0.1.1) then you
On 12/06/12 10:05, Alkis Georgopoulos wrote:
> Note that while bind-interfaces can be specified multiple times,
> defining except-interfaces more than once is a syntax error in my
> dnsmasq 2.59-4.
>
Are you sure? That should be allowed.
Simon.
--
You received this bug notification because yo
On 11/06/12 20:41, Thomas Hood wrote:
> Aha, I had tried this and it didn't work... in version 2.57. But I see
> that quantal already has 2.62.
>
>> Another instance of dnsmasq will run without interfering with that,
> providing only that --bind-interfaces is set.
>
> Just to make sure I understan
On 11/06/12 19:57, Thomas Hood wrote:
> But, second, there is a problem connecting the resolver to the NM-
> controlled dnsmasq such that the latter stays out of the way of the
> general local nameserver which currently wants to listen on the IPv4
> wildcard address. Using address ::1 for nm-dnsm
On 31/05/12 14:57, Scott Moser wrote:
> this looks like something we should pull in.
> Since Ubuntu has unmodified debian package, and debian maintainer is upstream
> maintainer, we should probably let the quantal package get synced from
> debian. Then, we can patch the 12.04 Ubuntu version in a
On 31/05/12 08:47, Thomas Hood wrote:
> In addition to devising an algorithm for dnsmasq to detect all and only
> NNNs, the implementation of which will no doubt take a while, we should
> consider implementing a quick fix too, along the lines suggested by
> Sergio in #19. NM could be changed to do
On 17/05/12 10:19, Wolf Rogner wrote:
> I recreated the situation by restarting the network manager.
>
> resolv.conf contains link to 127.0.0.1
> /run/nm-dns-dnsmasq.conf contained my name server already.
>
> However, even dig does not resolv correctly. Here are the results (my
> network is 10.x.
On 13/05/12 11:00, Wolf Rogner wrote:
> Public bug reported:
>
> dnsmasq does not resolve DNS names correcty.
>
> Applications like Thunderbird or tools like ssh rely on working name
> resolution. However, if there never was a working name resolution,
> dnsmasq never gets to know about the DNS name
On 08/02/12 08:33, Ritesh Raj Sarraf wrote:
> On Wednesday 08 February 2012 03:54 AM, Serge Hallyn wrote:
>> @Ritesh,
>>
>> Unfortunately I don't know that that many people would read the README :)
>> It is worth adding though, thanks for the suggestion.
>>
>> In addition, I will add an LXC section
On 02/01/12 09:44, Thomas Schweikle wrote:
>> That's exactly what happens without --bind-interface, interfaces which
>> are configured in dnsmasq but don't exist at startup generate a warning
>> only, and start to work when they are created.
>
> This seems to be correct.
>
>> Packets from interfa
An addition to my last reply:
If a DHCP request is received via in interface which doesn't have an IP
address, there will be a log message, but the request will be otherwise
ignored.
Cheers,
Simon.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
On 20/12/11 20:55, Thomas Schweikle wrote:
> H. If this is the reason, how to force dnsmasq not to respond on
> some interfaces, while listening on all others, with different
> configurations per interface?
>
> Wouldn't it be better to configure dnsmasq even for interfaces not there
> at start
On 08/12/11 12:57, Thomas Schweikle wrote:
> Yes, that's right, but there are interfaces not started from
> /etc/network/interfaces or Network Manager:
> * VMware Workstation / Player installs interfaces starting VMware daemons
> * VirtualBox installs interfaces
> * KVM may install an additional b
Launchpad Bug Tracker wrote:
> You have been subscribed to a public bug:
>
> Binary package hint: resolvconf
>
> in /etc/resolvconf/resolv.conf.d/base I have
>
> search domain1.local domain2.local
>
> When trying to connect to a host in domain2.local using only the
> hostname, only the first do
To Ubuntu triagers: This is a real bug, but it only affects code which
provides compatibility with very old (pre-Ubuntu) Debian installations
which might have interface configuration in /etc/default/dnsmasq. The
accepted place for such configuration has always been /etc/dnsmasq.conf
during the
On 12/11/10 19:09, Dave Walker wrote:
> Public bug reported:
>
> Binary package hint: dnsmasq
>
> *** glibc detected *** /usr/sbin/dnsmasq: double free or corruption
> (top): 0x08ab60b8 ***
>
> (As initially reported: http://lists.thekelleys.org.uk/pipermail
> /dnsmasq-discuss/2010q3/004369.html)
>
Emmet Hikory wrote:
> Actually, I filed this bug more as a result of the comments in the
> libvirt code, which indicate that at least one user of dnsmasq found it
> unable to accomplish an operation that seemed to make sense based on the
> documentation with a particular corner-case configurati
Something else that's required: we need to stop a libvirt-started
dnsmasq from picking up configuration left around by a removed system
dnsmasq, so the start-dnsmasq pseudo-code in libvirt becomes.
echo dhcp-range=interface:virt0, >/etc/dnsmasq.d/libvirtf
if system dnsmasq is not installed or
Emmet Hikory wrote:
>>From a brief look at the code, it appears that the relevant section is
> in src/dnsmasq.c : 169-189. In this mode, if unable to access an
> interface because it doesn't exist, dnsmasq should poll the interface
> for a configurable timeout to see if it becomes available before
Thierry Carrez wrote:
> @Simon: what are the options from a dnsmasq perspective ?
>
Some background: dnsmasq can run in two modes.
Default mode: dnsmasq binds the wildcard address and does network magic
to determine which interface request packets actually come from, so that
the results can be
Thierry Carrez wrote:
> Simon:
> Good news. Do you plan to push that release to Debian soon ?
>
It went last night, so should be in unstable very soon, if not already.
Cheers,
Simon.
--
DHCP Request Cycle can get caught in infinite loop
https://bugs.launchpad.net/bugs/327703
You received this
2.48 release is now available and includes the fix for this bug.
Cheers,
Simon.
--
DHCP Request Cycle can get caught in infinite loop
https://bugs.launchpad.net/bugs/327703
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in ubunt
A useful bit of information here: ISC dhcpd uses raw sockets to grab
incoming packets before they pass through the IP stack and IP tables, it
therefore doesn't suffer from problems caused by broken firewall rules.
Dnsmasq uses standard IP sockets so that all incoming packets are
filtered by iptable
I think I've deduced what is happening here. The combination of the
dhcp-host line and the /etc/hosts entry generates the equivalent of
dhcp-host=name,192.168.X.X
When you run Ubuntu, the DHCP requests send the name, so dnsmasq find
and uses this line, and all is good.
When the machine was reboo
Simon Kelley here: I'm the principal author of dnsmasq.
I have a couple of questions for FactTech:
1) Was the text message in the DHCPNAK log entry the same as the initial
reporter's ("address reserved")?
2) Is there any other dhcp-host line in the dnsmasq configuration w
70 matches
Mail list logo
