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)
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.
parenthesis There is a close analogy between the problem here (bug
#1003842)
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 the same
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 Desktop
Packages, which is subscribed to network-manager in
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 D-Bus?
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. :-)
(Put
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 workaround, since
12.10 relies on DBus to populate the
nameservers
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 is
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:
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 possible to
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 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 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 into
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 into
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 you
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 have
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 enjoy the
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-dnsmasq
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 understand
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
Simon, your suggestion (call it #18) differs from the suggestion in #17 in
two ways. First, #18 sends the first-received reply back
to the client without waiting for the results of comparison with other
results whereas #17 does wait. Second, #18 switches to
strict-order mode when *any*
Simon Kelley might have written dnsmaskq with the assumption that all
DNS servers upstream have the same view about the namespace. However,
this is not how RFC sees it nor how it is set up in a majority of
installations.
Can you provide an authoritative reference for that?
As far as I can see
To be frank, when changing the default system resolver, expected
behavior should be the default. It's all well and good saying that
non-equivalent resolvers are 'bad' - and in the case of dnsmasq, that
might be true - but that's a value judgement that shouldn't have a place
in this scenario,
Thomas in #17
A heuristic for this is difficult, because you have to prove a negative.
If we can assume the first nameserver has local addresses, we can never
return a reply from any other nameserver until we have the reply from
the first one, in case the first one has different data. Once we see
26 matches
Mail list logo
