Hi Dan,
Sorry for replying late and thanks for taking care of this.
Dan Williams d...@redhat.com writes:
So I'll propose a different solution: check the last patch in the
dcbw/dns-iface git branch, and let me know if that works for you?
On Wed, 2013-02-13 at 21:11 +0100, Michael Stapelberg wrote:
Hi Dan,
Sorry for replying late and thanks for taking care of this.
Dan Williams d...@redhat.com writes:
So I'll propose a different solution: check the last patch in the
dcbw/dns-iface git branch, and let me know if that
Hi Dan,
Dan Williams d...@redhat.com writes:
cat /var/run/NetworkManager/dnsmasq.conf
server=192.168.1.1
server=fe80::4e60:deff:fed8:d7c5@eth0
server=192.168.1.1
server=fe80::4e60:deff:fed8:d7c5@wlan0
I suppose it doesn’t really hurt, at least not in my case, but wouldn’t
it be cleaner
...@stapelberg.de
Date: Tue, 5 Feb 2013 19:02:12 +0100
Subject: [PATCH] dns: store priv-last_iface even when no actual updates are
performed
Otherwise, with DNS batch updating (commit f76aa4f), we might end up in
the situation where priv-last_iface is NULL when adding a link-local
IPv6 DNS server (e.g
On Tue, 2013-02-05 at 19:12 +0100, Michael Stapelberg wrote:
Hi,
the attached patch fixes a segmentation fault with n-m = 0.9.6.4 (I
upgraded from 0.9.4.0, so it might be introduced earlier).
Here is the commit message:
dns: store priv-last_iface even when no actual updates are
Hi Dan,
Dan Williams d...@redhat.com writes:
Sending the interface name is a hack anyway just to make netconfig and
resolvconf happy, even though prioritizing DNS information based on
interface name is bogus. NM merges and prioritizes the DNS
configuration before sending to
On Tue, 2013-02-05 at 23:00 +0100, Michael Stapelberg wrote:
Hi Dan,
Dan Williams d...@redhat.com writes:
Sending the interface name is a hack anyway just to make netconfig and
resolvconf happy, even though prioritizing DNS information based on
interface name is bogus. NM merges and
