** Summary changed:
- Precise resolvconf+dnsmasq setup breaks login in some wireless networks
+ Precise can't connect to a network guarded by an authentication webserver
whose address can only be looked up with one of the nameservers whose address
is provided by DHCP
--
You received this bug
*** This bug is a duplicate of bug 1003842 ***
https://bugs.launchpad.net/bugs/1003842
** This bug has been marked a duplicate of bug 1003842
Upgrading to Precise NM with dns=dnsmasq breaks systems with
non-equivalent upstream nameservers
--
You received this bug notification because
PArnal: The dnsmasq package is not installed but the dnsmasq-base
package is installed. The latter contains the executable which is
controlled by NM.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
Same as #1004775?
--
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/bugs/1004949
Title:
dnsmasq killed and restarted every 2 minutes
To manage notifications about this bug go to:
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 the following.
If the nameserver address
I have marked this issue as affecting dnsmasq since we may want to
implement a solution there along the lines of #28 or similar.
I have marked this issue as affecting resolvconf since we may want to
implement a fix there along the lines of #29 or similar. (In the
absence of NM and in the
I have marked this issue as affecting resolvconf
since we may want to implement a fix there along
the lines of #29 or similar. (In the absence of NM
and in the presence of dnsmasq, resolvconf also
feeds a nameserver list to dnsmasq.)
Just remembered that the resolvconf hook script that does
** Changed in: dnsmasq (Ubuntu)
Status: New = Fix Released
--
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/bugs/875950
Title:
/var/run/dnsmasq/resolv.conf empty on boot
To manage
Lieven Van Acker: Can you investigate this further to figure out why
dnsmasq isn't being asked to look up 'host2.domain2.local'?
** Changed in: dnsmasq (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Jim Tarvid: We are waiting for more information from you concerning
Launchpad bug #991073 which you filed against the Ubuntu dnsmasq
package. Please submit the information described in comment #1.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Summary changed:
- dnsmasq exits using --interface if the interface does not exist yet
+ dnsmasq with --interface exits immediately if the interface does not exist yet
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in
Wolf: Please post the FULL contents of your /etc/resolv.conf file as it
is when the reported problem occurs.
--
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/bugs/998712
Title:
dnsmasq
Wolf: In #3 you post some output but I don't know how to interpret it.
You start with a ping s4 which yields unknown host. You end with
ping s4 which successfully pings. What happened in the meantime to
change the results? Did you edit something?
--
You received this bug notification because
** Summary changed:
- lucid: dnsmasq isn't available on the server cd
+ The dnsmasq package isn't available on the server ISO
--
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/bugs/661599
** Changed in: dnsmasq (Ubuntu)
Status: Incomplete = Invalid
--
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/bugs/991073
Title:
dnsmasq failed to resolve most fqdn
To manage
Wolf: You list problems with dnsmasq. In this report (#998712) let's
continue to discuss the name resolution failure that you originally
reported. One of the other problems you listed is being discussed in
#1003842. For the remaining problems you listed, please submit your
information to bug
** Summary changed:
- Don't start local resolver if a DNS server is installed
+ Standalone dnsmasq is not compatible out of the box with NM+dnsmasq
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
Emmet in #14 So, my plan is as follows:
Should #959037 be taken into consideration here?
--
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/bugs/231060
Title:
packages dnsmasq and
** Changed in: dnsmasq (Ubuntu)
Status: In Progress = Confirmed
** Changed in: libvirt (Ubuntu)
Status: In Progress = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
Please understand that I don't have the time
OK, marking this as invalid.
** Changed in: dnsmasq (Ubuntu)
Status: Incomplete = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
I'd just like to note here before leaving this issue that the submitter
originally said that he was running bind. If bind was set up to listen
on 127.0.0.1#53 but was not correctly set up to provide name service
then I imagine that this could have interfered with the NM-controlled
dnsmasq.
In the absence of interest on the submitter's part in pursuing the
matter, and since there seems to be no problem in either resolvconf or
dnsmasq, marking Invalid.
** Changed in: dnsmasq (Ubuntu)
Status: Incomplete = Invalid
--
You received this bug notification because you are a member
Hi and thanks for the report.
In the title, Install resolvconf listener for dnsmasq into
/etc/resolvconf/update-libc.d, not update.d, you suggest a
configuration change, but this is for several reasons not a good idea.
What is this change supposed to achieve? What exactly is the problem
you are
** Changed in: dnsmasq (Ubuntu)
Status: Invalid = Incomplete
--
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/bugs/998712
Title:
dnsmasq integration into name resolution broken
To
On the affected system when it is manifesting the problem you reported
(can't resolve names), is named running locally? (In your original
submission you said that bind was running.) What role does this named
play in your network? How is it configured? What happens if you stop
this named? And
** Changed in: dnsmasq (Ubuntu)
Status: Invalid = Incomplete
--
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/bugs/781557
Title:
multiple search domains not honoured
To manage
The hypothesis was that named started before dnsmasq, preventing dnsmasq
from binding port 53 on 127.0.0.1. But the hypothesis is false, since
you are not running named after all.
Returning to your dig output, it can be summarized as follows.
dig s4 - FAILURE
dig @10.1.0.4 s4 - FAILURE
dig
*** This bug is a duplicate of bug 998712 ***
https://bugs.launchpad.net/bugs/998712
Marking as duplicate since it's similar.
** This bug has been marked a duplicate of bug 998712
domain name completion broken when dnsmasq is used
--
You received this bug notification because you are a
Wolf: I forgot to mention earlier that the reason I have to keep asking
questions is that I am unable to reproduce the problem here. On my
system, domain name completion works as expected with
NetworkManager+dnsmasq.
I just tried installing nscd to see if that made any difference, but it
did not
#991347 describes a case where there's a nameserver in the list that
always replies very quickly with no data. Dnsmasq currently selects
this nameserver because it's quick, the result being that all names fail
to be resolved. Ungood.
The measures proposed above would also improve handling of
@Alkis: Your title Dont... is not a description of a problem.
--
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/bugs/959037
Title:
Don't start local resolver if a DNS server is installed
I just re-read the whole discussion and thought it would be useful (for
me, at least) to summarize it.
The original bug report was that NM+dnsmasq and standalone dnsmasq are
incompatible because they have overlapping network socket address
ranges, 0.0.0.0:53 and 127.0.0.1:53.
One solution is for
Alkis: Why do you need the dnsmasq package at all? You want NM and
dnsmasq. Why not just use the NM-enslaved dnsmasq?
If the latter doesn't meet your needs, could it be adapted somehow to
meet your needs?
Assuming that there are good reasons for using NM and standalone
dnsmasq, I'd be inclined
Hmm, I wasn't very clear. What I meant in my questions above (#34) was
this. If NM+dnsmasq is the best solution for name service for the local
host, isn't it also a better solution than NM-together-with-standalone-
dnsmasq for remote hosts? If so then another solution approach is to
enhance NM
What lies behind the problem being discussed here is the simple fact
that there exists no single adequate network configuration utility for
GNU/Linux. I am most familiar with Debian. From Debian we inherit
ifupdown which was designed for static configuration. Debian developers
have known for
* Some thinking about[0][1], if not much coding of[2], a successor to
ifupdown was done in the netconf project[3] led by Debian Developer
martin krafft[4][5].
[0]http://people.debian.org/~madduck/talks/netconf_fosdem_2007.02.25/slides.s5.html
Having just re-read the discussion, I realize that I may have
misunderstood the problem. I'll try to summarize it.
Wolf, are you saying that when using the NM-enslaved dnsmasq, fully
qualified domain names can always be resolved using the resolver(3) but
short domain names cannot be resolved
Based on comment #28, marked as affecting djbdns.
** Summary changed:
- Local resolver prohibits DNS servers from running
+ NM-controlled dnsmasq prevents other DNS servers from running
** Also affects: djbdns (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug
Reggie: First of all, thanks for providing information about the
malfunction on your system. We will get to the bottom of this!
To get very clear on what's happening I will summarize. Let me know if
any of the following is wrong.
With the following resolv.conf (omitting comments)
Reggie, I wrote:
First I'd like to rule out the possibility of side-effects of #1003842.
Please eliminate the lines
server=24.177.176.38
server=97.81.22.195
from /run/nm-dns-dnsmasq.conf
Just thought of a hitch.
After removing these lines dnsmasq has to be restarted or it won't
notice
Daniel, can you please provide some more information? Why do you think
that dnsmasq's hook script should be moved? What is this supposed to
achive? What exactly is the problem you are reporting?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Summary changed:
- NM-controlled dnsmasq prevents other DNS servers from running
+ NM-controlled dnsmasq prevents other DNS servers from running, yet
network-manager doesn't Conflict with their packages
--
You received this bug notification because you are a member of Ubuntu
Server Team,
But enough dreaming. Given the world as it is, the immediate challenge
is to make NM+dnsmasq compatible with standalone nameservers.
(Otherwise network-manager should Conflict with those nameservers'
packages.)
Solutions mentioned earlier:
* Tell the administrator to comment out dns=dnsmasq in
Daniel, if you base your suggestion that dnsmasq be triggered from
update-libc.d/ and not from update.d/ on what you read in the manpage,
then you have misunderstood. The hook scripts in update-libc.d are run
only after /etc/resolv.conf has been updated. Dnsmasq's hook script
needs to run when
Wolf, dnsmasq is not going to be taken out of the distribution.
Probably you meant that NM-driven dnsmasq shouldn't be enabled by
default. If so then please file another report against network-manager
with the title Please don't enable dnsmasq by default so long as it's
so buggy. But that
I meantioned Wicd and Netconf above. While investigating another
problem I stumbled across Connman
http://connman.net
which appears to be another alternative to NetworkManager worth
watching.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Public bug reported:
Arises from #1010724.
dig(1) says: If no server argument is provided, dig consults
/etc/resolv.conf and queries the name servers listed there.
However, if /etc/resolv.conf contains nameserver 127.0.0.1 and the
command is dig -6 google.com then, as seen in wireshark,
Another idea:
* Change NM such that it causes its slave dnsmasq to listen on ::1
instead of 127.0.0.1
But I guess the problem will just arise again if the standalone dnsmasq
is changed to listen on the wildcard IPv6 address.
--
You received this bug notification because you are a member of
Alkis wrote:
I wouldn't want it as my default resolver.
But some people might. It's better to eliminate the behavioral
conflict, if we can, than to formalize that conflict as a packaging
dependency.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Yes, I also have no objection to the behavior. I think the man page
could be tweaked to be a little. Something like the following.
- If no server argument is provided, dig consults /etc/resolv.conf and
queries the name servers listed there.
+ If no server argument is provided, dig consults
Alkis wrote:
If nm + resolvconf managed to properly chain the 2 dnsmasq instances so that
the NM-spawned dnsmasq was contacted first
I think that this configuration should be supported, whether or not it's
the best solution to the present problem (#959037).
Resolvconf can handle this with a
Thanks for the update, Reggie.
Wolf, can you please put me in touch with one or more of the dozens of
people you mentioned above (#21) who have this (#998712) problem?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
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 correctly: Do you mean here that --bind-
so dropping a file there containing bind-interfaces
and doing the relevant restart in postinst should
make this automatic in most cases.
I notice that libvirt has just used this mechanism to solve a comparable
problem (see ##928524). Libvirt includes the file /etc/dnsmasq.d/libvirt-bin
It just occurred to me that if we are going to change someone's listen
address then it might be better to give 127.0.0.1 to nm-dnsmasq and
127.0.1.1 to the standalone nameserver.
Consider the case where nm-dnsmasq is running on a machine, nemo, that
happens to run the nameserver for the LAN.
Alkis: Suppose your host, foo, has external IP address 10.1.2.3 and runs
a standalone nameserver which listens on eth0. Configure things such
that nm-dnsmasq on foo uses 10.1.2.3 as its upstream nameserver;
configure the standalone nameserver on foo not to listen on lo. If it's
dnsmasq, start it
Aha, you have to use except-interface=lo together with bind-
interfaces. Sorry for all the messages!
--
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/bugs/959037
Title:
NM-controlled
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.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
** Changed in: dnsmasq (Ubuntu)
Status: Confirmed = Fix Released
--
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/bugs/231060
Title:
packages dnsmasq and libvirt-bin conflict with
Oops, I changed the status to fix released but then realized that
#231060 wasn't addressed by 0.9.12-0ubuntu3. The latter included
bind-interfaces
except-interface=virbr0
whereas to fix #231060 the following would be needed.
bind-interfaces
except-interface=vnet0
I don't have
Alkis wrote in #51:
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.
Multiple except-interface options are accepted by dnsmasq 2.62-2.
--
You received this bug notification because you are a
Public bug reported:
In the start_resolvconf() function the initscript correctly refrains
from registering the loopback IP address with resolvconf if lo is in
DNSMASQ_EXCEPT.
start_resolvconf()
{
# If interface lo is explicitly disabled in /etc/default/dnsmasq
# Then dnsmasq
(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 advantages of non-bind-interfaces
mode
I filed this because I thought that even if we don't decide to deal with
#959037 by means of except-interface=lo, this is a change that would
be good to make anyway.
But on second thought, this would just be one hack on top of another.
Dnsmasq has several options governing which interfaces and
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 bind-interfaces mode and move
nm-dnsmasq's
@Serge: I was just going by what I read in comment #1 where vnet0 was
named.
You are right. Adding --bind-interfaces and --exclude-interface=virbr0
allows both the general dnsmasq and the libvirt-bin dnsmasq to start.
Without --bind-interfaces and --exclude-interface=virbr0:
Simon:
If you can make #2 happen without breaking things, that would seem to be
worth doing
Indeed, primum non nocere. Standalone dnsmasq works fine in the absence
of NM+dnsmasq and vice versa and this must continue to be the case when
we are done. :)
I guess the main problem is that you
** Summary changed:
- NM-controlled dnsmasq prevents other DNS servers from running, yet
network-manager doesn't Conflict with their packages
+ NM-controlled dnsmasq prevents other DNS servers from starting
--
You received this bug notification because you are a member of Ubuntu
Server Team,
With the latest dnsmasq code the two dnsmasq instances appear to work
correctly in all combinations. I just tested as follows.
* With both dnsmasqs running, nm-dnsmasq forwards to the upstream nameservers
and listens on 127.0.0.2; standalone dnsmasq forwards to 127.0.0.2 and listens
on
@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.
IIUC the only way to avoid this is to run
Regarding #3, I've filed a wish in upstream's bugzilla:
http://sourceware.org/bugzilla/show_bug.cgi?id=14242
#2 is easy to implement and does solve the problem of standalone dnsmasq
not starting on installation in the presence of NM+dnsmasq. What I am
now wondering is how useful the resulting
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.
And this is also one answer to my question in #72. The dnsmasq
cascade may
--conf-file not needed
Well, this is used to make nm-dnsmasq read the configuration file that
has been dynamically generated by NM. Without this you will have to do
something like the following.
ln -s /var/run/nm-dns-dnsmasq.conf /etc/dnsmasq.d/nm-dns-
dnsmasq.conf
NM kills and starts a
$ 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.
No doubt dnsmasq could be enhanced to poll its configuration files. But
it
Here's some background information I stumbled across.
Once upon a time NM started dnsmasq in strict-order mode but this was
changed.
https://bugs.launchpad.net/ubuntu/+source/network-
manager/+bug/903854
This bug was mentioned in the discussion about domain name service
changes for Precise.
Dnsmasq cascade (#72) has maintenance advantages. For example it
makes it easy for the distromaestros to switch to other software to
perform the same limited task as nm-dnsmasq now performs, without any
chance of disturbing admins' standalone dnsmasq setups.
Does dnsmasq-cascade have drawbacks
-- Solvable by moving nm-dnsmasq to another port:
http://sourceware.org/bugzilla/show_bug.cgi?id=14242
BTW, the required enhancement to glibc shouldn't be difficult to
implement. I expect that all we'd have to do is change the following
code (around line 313 in resolv/res_init.c) so that it
Applications that don't use the libc resolver?
Hmm, yes. There are several alternative resolver libraries (adns,
firedns, djbdns, ...) and even if we fixed them all so that they could
read the extended resolv.conf syntax then statically linked third party
binaries would still break.
So having
I now agree (see Mathieu's comment #30) that the most expedient thing to
do is
* update dnsmasq to a new release based on the latest code in Simon's git repo;
* patch the two lines in the n-m code such that (1) nm-dnsmasq listens on
127.0.0.2 instead of 127.0.0.1 and (2) NM registers 127.0.0.2
From the SRU justification:
Regression potential: There should be none, since we are
simply telling the system-wide dnsmasq (if any) not to bind
to the virbr0 which our own dnsmasq instance will bind to.
There is more risk of trouble than that. With this change to libvirt-
bin, after
From the SRU justification:
Regression potential: There should be none, since we
are simply telling the system-wide dnsmasq (if any) not
to bind to the lxcbr0 which our own dnsmasq instance
will bind to.
There is more risk of trouble than that. With this change, after lxc is
installed,
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 because the cases of dnsmasq being forced into bind-
Relevant to my question above:
What would be the best way to implement this, Simon?
is what Simon wrote in #928524 comment #12:
--- BEGIN QUOTATION ---
I'm wondering about adding a _third_ mode, which is has a desirable
mixture of the properties of the current two (--bind-interfaces and NOT
@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?
(Moving nm-dnsmasq listening to another port than 53 is at best a veeery
long-term solution since it requires first getting glibc enhanced, then
getting all other
I can imagine that it will take a lot of care to avoid introducing races
inside dnsmasq. Have I mentioned yet that Simon is a hero?
Do we have to worry about races outside of dnsmasq? Suppose someone was
running dnsmasq in unbound mode and has now switched to the new improved
dnsmasq in
Meanwhile my laptop has been working fine with two dnsmasq instances
running in cascade. I'll try to subject this arrangement to more severe
tests in the coming weeks.
# netstat -nl46p | grep :53
tcp0 0 127.0.0.2:530.0.0.0:* LISTEN
7928/dnsmasq
Just checked pdnsd. I thought it would be affected since it also starts
in server_ip=any mode by default; however the Debian package which is
also in Universe includes server_ip=127.0.0.1 in /etc/pdnsd.conf. It
therefore starts alongside nm-dnsmasq modified to listen on 127.0.0.2.
So nothing
@Bert: Can you provide more information about the conflict with djbdns?
The dnscache-run package, one of the binary packages built from djbdns
source, is marked as Conflicting with resolvconf because it messes
directly with /etc/resolv.conf --- see Debian bug report #582755. Its
maintainers
Next checked PowerDNS Recursor. The Debian package pdns-recursor is
also available in Universe. Its default configuration is to listen only
on 127.0.0.1:53 so it will also no longer conflict with nm-dnsmasq if
the latter is moved to 127.0.0.2.
/etc/powerdns/recursor.conf:
Simon, do you think that dnsmasq could misbehave as described here?
** Also affects: dnsmasq (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
Hmm, not exactly #1003842, since you don't have the problem that some
nameservers are screening off others with NXDOMAIN.
The worst we can say about dnsmasq in this context is that it could
behave better in the case where several listed upstream nameservers are
unreachable.
** Also affects:
** Summary changed:
- DNS unresponsive/slow when different DNS are provided by wifi and wired
connected to different networks
+ (1) NM fails to configure routing correctly when connect to two LANs; (2)
dnsmasq initially slow when some upstream nameservers can't be reached
--
You received this
Does the standalone dnsmasq behave the same way?
To find out, disable nm-dnsmasq by commenting out the line dns=dnsmasq
in /etc/NetworkManager/NetworkManager.com. Restart network-manager.
Then install the dnsmasq package.
If standalone dnsmasq also misbehaves then turn on log-queries mode: add
In bug #979067 there is a similar description of apparent dnsmasq
misbehavior.
There Guillaume Melquiond writes:
It takes a lot of failures before all the unreachable servers
have been exhausted, which makes for a poor user experience.
--
You received this bug notification because you are a
The second part of this bug report, concerning dnsmasq's poor behavior
when some upstream nameservers are unreachable, has also been reported
in #991308. Let's continue discussing that problem over there and
reserve this bug report (#979067) for the problem that routing is not
configured
** Package changed: network-manager (Ubuntu) = openvpn (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openvpn in Ubuntu.
https://bugs.launchpad.net/bugs/997927
Title:
NM reports VPN service 'openvpn' disappeared
To manage
** Also affects: dnsmasq (Ubuntu)
Importance: Undecided
Status: New
--
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/bugs/994963
Title:
DNS stops working after some time
To
Is this bug still present in Precise?
--
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/bugs/105251
Title:
NetworkManager wrongly releases DHCP IP
To manage notifications about this bug
@Kemko: If you have no connectivity at all then your problem is another
one than the one being discussed here, which is just that DNS stops
working after a few hours, not all connectivity.
** Changed in: dnsmasq (Ubuntu)
Status: New = Incomplete
** Changed in: network-manager (Ubuntu)
** Changed in: network-manager (Ubuntu Precise)
Status: New = Invalid
** Changed in: network-manager (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
101 - 200 of 351 matches
Mail list logo
