** Summary changed:
- No Wifi after resume from suspend
+ No Wi-Fi after resume from suspend -- Realtek RTL8188CE rtl8192ce
** Summary changed:
- No Wi-Fi after resume from suspend -- Realtek RTL8188CE rtl8192ce
+ No Wi-Fi after resume from suspend; disabling and enabling wireless fixes it
--
** Summary changed:
- UMTS connections require occasional reconfiguring
+ NM fails to make UMTS connection; deleting and recreating the connection
configuration fixes it
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager
** Summary changed:
- No DNS resolution after upgrade from 12.04 to 12.10 beta,
/var/run/nm-dns-dnsmasq.conf empty
+ No DNS resolution after upgrade from 12.04 to 12.10 beta
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
NM no longer uses nm-dns-dnsmasq.conf to tell nm-dnsmasq its forwarding
addresses. NM now uses D-BUS for that purpose. So that's not the
problem.
That you have no domain name service is obviously a problem.
That you could restore service by sticking nameserver addresses into nm-
dns-dnsmasq.conf
** Summary changed:
- DNS entries malformed
+ Nameserver address entered for one connection gets added to resolv.conf for
all connections
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
*** This bug is a duplicate of bug 1042233 ***
https://bugs.launchpad.net/bugs/1042233
** This bug has been marked a duplicate of bug 1042233
NM DSL connection: DNS server addresses not added to resolv.conf
--
You received this bug notification because you are a member of Desktop
Returning to this issue
Consider the log in comment #10. A successful lookup is done.
Jun 22 13:43:09 archon dnsmasq[9635]: query[A] slashdot.org from 127.0.0.1
Jun 22 13:43:09 archon dnsmasq[9635]: forwarded slashdot.org to 75.75.75.75
Jun 22 13:43:09 archon dnsmasq[9635]: reply
** Description changed:
As found at bug 1052664
$ dpkg-query --show network-manager
network-manager 0.9.6.0-0ubuntu7
$ cat /etc/hostname
# xxx by cloud-init
domU-12-31-39-0C-6C-81
This *should* be ok, as per 'man hostname':
--F, --file filename
-
Sounds as if it could be a carrier detect bug in the driver
** Summary changed:
- network-manager tries to onnect to eth0 when cable is unplugged
+ network-manager tries to connect to eth0 when cable is unplugged -- Intel
82577LM e1000e
** Description changed:
Even when the cable is
The problem could be simply that the symbolic link at /etc/resolv.conf
is missing. This should be a symbolic link with value
../run/resolvconf/resolv.conf. Create it by doing
ln -nsf ../run/resolvconf/resolv.conf /etc/resolv.conf
and then rebooting. After rebooting do the following in a
Martin wrote:
So NM needs to be taught where to write DNS servers
for static configurations when resolvconf is installed/enabled.
When resolvconf is installed, as indicated by the presence of
/sbin/resolvconf, NM doesn't write out a file but pipes the content to
the /sbin/resolvconf script
@Jason: From the log you posted it appears that resolvconf is now
configured correctly.
Was /etc/resolv.conf simply non-existent on your system before your
created the symlink?
Do you have any idea *why* /etc/resolv.conf was not there, or not a
symlink to ../run/resolvconf/resolv.conf? Normally
*** This bug is a duplicate of bug 1000244 ***
https://bugs.launchpad.net/bugs/1000244
** This bug has been marked a duplicate of bug 1000244
/etc/resolv.conf symlink does not exist after initial installation of
resolvconf package
--
You received this bug notification because you are a
*** This bug is a duplicate of bug 1000244 ***
https://bugs.launchpad.net/bugs/1000244
Since the disappearance of your /etc/resolv.conf symlink is a mystery I
have merged this report with the other reports of mysterious resolv.conf
disappearance.
Exactly which image did you originally use to
*** This bug is a duplicate of bug 1000244 ***
https://bugs.launchpad.net/bugs/1000244
On the Ubuntu Secure Remix iso
Name: ubuntu-secure-remix-12.04.1-64bits.iso
Source: sourceforge.net
Date: 2012-08-31
Size: 735.9 MB
MD5 sum: f331f796d721d533ee887ac590918265
the file
** Package changed: network-manager (Ubuntu) = xfig (Ubuntu)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1054217
Title:
fonts not recognized in xfig
Status in “xfig”
** Summary changed:
- Wireless connections not available in network manager
+ NM does not see any wireless connections -- Motorola Surfboard sbg6580
** Summary changed:
- NM does not see any wireless connections -- Motorola Surfboard sbg6580
+ NM does not see any wireless networks
--
You
*** This bug is a duplicate of bug 1000244 ***
https://bugs.launchpad.net/bugs/1000244
Thanks.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1051348
Title:
No resolving
Stephan made it clear that he was able to configure his wired interface
in the traditional way using ifup. This of course required an iface
eth0 stanza in /etc/network/interfaces.
Stephan has not yet made it clear whether or not removing all references
to eth0 from /etc/network/interfaces was
Reading the log file that Stephan supplied...
First we see three cases of successful connection.
May 8 14:12:32 d-charms NetworkManager: info (eth0): carrier is OFF
May 8 14:12:32 d-charms NetworkManager: info (eth0): new Ethernet device
(driver: 'r8169')
May 8 14:12:32 d-charms
*** This bug is a duplicate of bug 1055209 ***
https://bugs.launchpad.net/bugs/1055209
** This bug has been marked a duplicate of bug 1055209
service network-manager doesn't start on boot
--
You received this bug notification because you are a member of Desktop
Packages, which is
*** This bug is a duplicate of bug 1055209 ***
https://bugs.launchpad.net/bugs/1055209
** This bug is no longer a duplicate of bug 663735
After upgrade to 12.04 NetworkManager does not start automatically on boot
** This bug has been marked a duplicate of bug 1055209
service
See comment #6
** Package changed: resolvconf (Ubuntu) = network-manager (Ubuntu)
** Summary changed:
- No IPv6 nameservers in Ubuntu 12.04
+ NM fails to start dnsmasq such that it listens on ::1
--
You received this bug notification because you are a member of Desktop
Packages, which is
I have reported the dig bug in #1011307.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1010724
Title:
NM fails to start dnsmasq such that it listens on ::1
Status in
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 Desktop
Packages, which is
** Changed in: network-manager (Ubuntu)
Status: Confirmed = New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1010724
Title:
NM fails to start dnsmasq such that it
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
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
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 Desktop
Packages, which is subscribed to network-manager in Ubuntu.
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 Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
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
(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
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
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 Desktop
Packages,
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
One way to fix this would be to run standalone dnsmasq in addition to
NetworkManager-controlled dnsmasq and have the former forward to the
latter. Unlike NM-controlled dnsmasq, standalone dnsmasq listens on all
interfaces, including ::1.
At present, standalone dnsmasq can't be started when
Instead of letting the user custom-configure NM-controlled dnsmasq, what
if we cascade traditional standalone dnsmasq (which can be custom
configured) to NM-controlled dnsmasq (which can't be) --- the former
forwarding to the latter? Would this address the libvirt-network use
case mentioned in
@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
*** This bug is a duplicate of bug 1003842 ***
https://bugs.launchpad.net/bugs/1003842
Brian: That commenting out dns=dnsmasq did not solve your problem
indicates that the problem is not the same as Jeff Licquia's. His
problem was probably bug #1003842 in dnsmasq.
** This bug has been marked
*** This bug is a duplicate of bug 1003842 ***
https://bugs.launchpad.net/bugs/1003842
Brian: Did you reboot or restart network-manager after editing its
configuration file? If not, please do so and try again.
--
You received this bug notification because you are a member of Desktop
*** This bug is a duplicate of bug 1003842 ***
https://bugs.launchpad.net/bugs/1003842
Brian Marks wrote:
Yes, tried restarting network-manager but used UI 'enable
networking' checkmark to disable and re-enable. Would this be
consistent with using command line to restart service?
Using
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
*** This bug is a duplicate of bug 1003842 ***
https://bugs.launchpad.net/bugs/1003842
Hi Brian
Is what I'm doing helpful?
Yes, very helpful. You describe exactly what you did and what the
result was.
It's especially useful to know what one of the causes of the problem
was. :)
Bind9.
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
** This bug is no longer a duplicate of bug 1003842
dnsmasq sometimes fails to resolve private names in networks with
non-equivalent nameservers
** Summary changed:
- dnsmasq does not update nameserver info after network change
+ n-m registers VPN nameserver information twice
--
You
Hi, Brian. As Jeff Licquia's issue is already covered by #1003842 and
you have posted information here that indicates the existence of another
real bug, I am taking the liberty of retitling this report to address
_your_ bug.
NetworkManager is registering the VPN nameserver addresses under the
Reassigned to resolvconf to reflect the fact that this report is now
about the bug described in comment #14.
** Package changed: network-manager (Ubuntu) = resolvconf (Ubuntu)
** Summary changed:
- n-m registers VPN nameserver information twice
+ /etc/ppp/ip-up.d/000resolvconf should exit 0 if
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
Without the FQHN in /etc/hosts Kerberos and AD integration with
windbind do not work.
I agree with Mathieu and just want to underline that if any application
fails with a static /etc/hosts containing
127.0.0.1 localhost
127.0.1.1 UNIX hostname
then it's the application that needs to
I am going to be so bold as to close this bug report. The original
report (from 2004) and followups reflect the way Ubuntu was installed
and what NetworkManager and other software did a long time ago and the
subsequent discussion is not clearly about any one issue. If there are
still outstanding
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
Public bug reported:
From /var/log/syslog:
Jun 20 10:03:25 tenerife dhclient: DHCPREQUEST of 192.168.2.103 on eth0 to
255.255.255.255 port 67
Jun 20 10:03:25 tenerife dhclient: DHCPOFFER of 192.168.2.103 from 192.168.2.254
Jun 20 10:03:25 tenerife dhclient: DHCPACK of 192.168.2.103 from
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:
ihse (the submitter) wrote:
As for the second issue however, about the valid interface
(a wifi card) not showing, it still seems a valid problem.
Some more digging around turned up that by using nm-tool,
I could still see the wlan0 card. So this is either a problem
solely in nm-applet, or in
Mathieu is right.
To summarize:
* Make sure that the resolvconf package is still installed
* Restore symlink /etc/resolv.conf -- ../run/resolvconf/resolv.conf
* Restore /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
dns=dnsmasq
[ifupdown]
Also possibly relevant: bug #998529.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1009392
Title:
No name service after upgrade from 11.10
Status in “network-manager”
** Summary changed:
- NetworkManager is not running
+ After upgrade to 12.04 NetworkManager does not start automatically on boot
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
This has been fixed in Precise.
** Changed in: network-manager (Ubuntu)
Status: Triaged = Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/324233
Title:
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 Desktop
Packages, which is subscribed to network-manager in Ubuntu.
jedix in #5:
I noticed that my /etc/resolv.conf only has 127.0.0.1 in it. I believe this
is a bug in the new resolvconf package
It's not a bug. It's correct.
Marcus in #6:
after adding nameserver 8.8.8.8 to /etc/resolv.conf
Don't do that. If you must temporarily add static entries to
@sladner84: Do you think your problem is the same as the one reported in
bug #998712?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/989900
Title:
DNS Resolve Problems in
The first problem is with your routing. Address yy.yy.34.35 is
presumably to be reached via yy.yy.72.0/24 but the kernel does not know
this.
Second problem is bug #1003842 again.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
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:
Michael in #52:
As soon as I update my network interfaces file, all hell breaks loose. Wifi
configuration applet sometimes appears, wlan0 seems completely unpredictable
whether it will appear.
Sounds like bug #391040. Please submit the information you have about
that issue to that bug
Are you still having this problem in Precise?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/530284
Title:
wireless adapter gets disabled in network-manager
Status in
Does this problem still occur in Precise?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/489357
Title:
After upgrading to karmic, /e/n/i network config (non NetworkManager)
In Precise, network-manager Depends on isc-dhcp-client, the successor to
dhcp3-client.
** Changed in: network-manager (Ubuntu)
Status: Confirmed = Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in
** Changed in: network-manager (Ubuntu)
Status: Incomplete = Invalid
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/446134
Title:
network-manager does not support dhcp
Is your problem the same as the one reported in bug #391040?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/993547
Title:
Ubuntu 12.04 disable wifi on Lenovo U400 (I havent
** Summary changed:
- network-manager/dnsmasq causes slow dns resolution after changing networks
+ networking slow after changing networks while machine suspended
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in
Do you still have this problem?
Please post your /e/n/i.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/522479
Title:
Upgrade to 9.10 caused wireless network to cease
** Changed in: network-manager (Ubuntu)
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/875668
Title:
wifi network disabled
Status in
Does restarting network-manager always solve the problem?
sudo restart network-manager
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/994963
Title:
DNS stops working
** 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
In Precise, NM no longer clobbers /etc/resolv.conf.
** Changed in: network-manager (Ubuntu)
Status: New = Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
Should be fixed in Precise.
** Changed in: network-manager (Ubuntu)
Status: New = Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/511583
Title:
** Summary changed:
- After upgrading to karmic, /e/n/i network config (non NetworkManager) no
longer works
+ NetworkManager fails to ignore wlan0 which has been configured in /e/n/i
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
*** This bug is a duplicate of bug 391040 ***
https://bugs.launchpad.net/bugs/391040
** This bug has been marked a duplicate of bug 391040
When eth0 is unmanaged, system connections for other NICs aren't displayed
nor used
--
You received this bug notification because you are a member
I think that the behavior is expected, but perhaps I don't understand
what you are describing. eth0 is defined in /e/n/i and NetworkManager
is configured ([ifupdown] managed=false) to ignore interfaces defined
in /e/n/i.
** Changed in: baltix
Status: New = Invalid
** Changed in:
/e/n/i contains:
auto eth0
iface eth0 inet dhcp
so assuming NetworkManager.conf contains
[ifupdown]
managed=false
it's expected that NM doesn't manage eth0.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
In the following part of syslog it appears, though, that NM is managing
eth0 after saying that it's now unmanaged!
May 8 18:36:49 k8u NetworkManager: info (eth0): now unmanaged
[...]
May 8 18:36:51 k8u dhclient: There is already a pid file
/var/run/dhclient.eth0.pid with pid 3094
May 8
*** This bug is a duplicate of bug 1009879 ***
https://bugs.launchpad.net/bugs/1009879
** This bug has been marked a duplicate of bug 1009879
NetworkManager high CPU usage while nm-applet and Transmission run
--
You received this bug notification because you are a member of Desktop
** Summary changed:
- NetworkManager does not use local hosts configuration any more
+ NetworkManager-controlled dnsmasq does not respect /etc/hosts
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
** Summary changed:
- modifying dns servers causes network to disconnect
+ Changing from DHCP to DHCP (addresses only) unnecessarily downups the
interface
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
1 - 100 of 2045 matches
Mail list logo
