Bug 474332 - NetworkManager affects configuration of interfaces which are not to be managed [NEEDINFO]
NetworkManager affects configuration of interfaces which are not to be managed
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-03 06:22 EST by Marek Greško
Modified: 2009-12-18 02:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:07:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dcbw: needinfo? (gresko)


Attachments (Terms of Use)

  None (edit)
Description Marek Greško 2008-12-03 06:22:37 EST
Description of problem:
NetworkManager destroys configuration of my network interfaces which I do not want to be controlled by NetworkManager (they have NM_CONTROLLED=no). Their IP configuration is lost after running NetworkManager. I want NetworkManager only to control my UMTS modem.

Version-Release number of selected component (if applicable):
NetworkManager-0.7.0-0.12.svn4326.fc10

How reproducible:
Always.

Steps to Reproduce:
1. Setup network interfaces with NM_CONTROLLED=no.
2. Run NetworkManager.
3. IP addresses of network interfaces are lost.
  
Actual results:
NetworkManager destroys network configuration of interfaces not controlled by it.

Expected results:
NetworkManager does not touch interfaces marked as NM_CONTROLLED=no

Additional info:
Also I have PEER_DNS=no in the configuration for my UMTS modem and NetworkManager ignores this option. It always rewrites my resolv.conf. I think it should not.
Comment 1 Marek Greško 2008-12-16 15:20:45 EST
If I make NetworkManager start after haldaemon, it works. I do not know whether it is better to move NetworkManager to S99NetworkManager or to move haldaemon to start prior to NetworkManager. But the problem with overwriting resolv.conf I am not able to workaround.
Comment 2 Dan Williams 2008-12-17 12:09:05 EST
(In reply to comment #1)
> If I make NetworkManager start after haldaemon, it works. I do not know whether

NetworkManager requires hal to detect devices.  NM should already be starting after haldaemon has started.

> it is better to move NetworkManager to S99NetworkManager or to move haldaemon
> to start prior to NetworkManager. But the problem with overwriting resolv.conf
> I am not able to workaround.

NM cannot start at position 99 because other stuff requirs that it be started earlier, you should keep it at the position it's installed into: 27.

How long does HAL startup take on your machine?
Comment 3 Marek Greško 2008-12-17 12:49:05 EST
I had S98haldaemon on my machine. Probably residuum of upgrade from previous version. Fixed.
Comment 4 Dan Williams 2008-12-17 13:55:10 EST
(In reply to comment #3)
> I had S98haldaemon on my machine. Probably residuum of upgrade from previous
> version. Fixed.

Ah; I believe all of hal, dbus, and nm should try to reset their priorities automatically on update.  However, to force-reset them, try (as root):

/sbin/chkconfig messagebus resetpriorities
/sbin/chkconfig haldaemon resetpriorities
/sbin/chkconfig NetworkManager resetpriorities

and you should end up with NM at 27.
Comment 5 Marek Greško 2009-02-13 13:35:12 EST
The devices are controlled as appropriate when priorities of services are restarted. But I am still not able to disable changing of resolv.conf.
Comment 6 Dan Williams 2009-02-13 13:47:26 EST
NetworkManager is intended to update resolv.conf when it acquires a connection or renews a lease.  If the device isn't managed by NetworkManager, then *of course* NM won't know about the device, because you've explicitly made NM ignore it.

You can, however, add DNS servers to the primary connection that NM does control and thus probably get things to work.  DNS isn't interface configuration; it's *machine* configuration and not tied to specific interfaces.  Thus it's not something that's ignored when you set NM_CONTROLLED=no.
Comment 7 Dan Williams 2009-02-14 07:24:17 EST
Let me know if adding your custom DNS servers to the connection's IP4 config works for you; you can set DNS1, DNS2, DNS3 in the ifcfg file for the connection that NM *does* control, and if you want to ignore DHCP-provided nameservers, PEERDNS=no will do that for you.
Comment 8 Marek Greško 2009-02-16 12:39:44 EST
Just read my first report. I have PEERDNS=no set up. But it is ignored.
Comment 9 Dan Williams 2009-02-17 06:49:08 EST
Your original report said "PEER_DNS=no", but the actual key is "PEERDNS=no".

Note that PEERDNS only affects *that connection*, ie PEERDNS=no should ignore the nameservers for the UMTS connection.  It won't make NetworkManager stop rewriting resolv.conf for the devices under its control.

Is it the case that you want to use one set of DNS servers all the time, no matter what's connected and what's not connected?  Are you using NetworkManager to manage the UMTS connection as well?
Comment 10 Niels Haase 2009-04-10 16:31:37 EDT
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 11 Marek Greško 2009-04-11 13:55:37 EDT
I have UMTS connection. I have PEERDNS=no in my setup for UMTS connection and NetworkManager sets DNS like UMTS provider suggests what is not what I want. I want to have DNS setup the same no matter whether the UMTS connection is up or not.
Comment 12 Marek Greško 2009-08-18 10:25:50 EDT
Current state is: I am able to configure DNS manually for UMTS modem setting PPP with addresses, but when disconnecting, my /etc/resolv.conf becomes destroyed. I just want /etc/resolv.conf not to be touched by NetworkManager. The PEERDNS is completely ignored (or probably anything except NM_CONTROLLED).
Comment 13 Dan Williams 2009-10-15 00:13:43 EDT
(In reply to comment #12)
> Current state is: I am able to configure DNS manually for UMTS modem setting
> PPP with addresses, but when disconnecting, my /etc/resolv.conf becomes
> destroyed. I just want /etc/resolv.conf not to be touched by NetworkManager.
> The PEERDNS is completely ignored (or probably anything except NM_CONTROLLED).  

Are you using NM to control the UMTS device?  NM is meant to manage the default internet connection, and as such, /etc/resolv.conf too, because /etc/resolv.conf is an integral part of the default internet connection.  If NM can't manage your default internet connection, then either I'd like to update NM to support that, or NM may not be the most appropriate solution for you.

PEERDNS should be honored by NetworkManager; are you using PPP manually with ifup/ifdown and your UMTS connection?  If so, would you mind attaching your ifcfg file so I can ensure that NM works with that configuration?
Comment 14 Marek Greško 2009-10-16 13:14:55 EDT
Yes I am using NM to control UMTS device. It is my default connection. I have PEERDNS=no set and it is not honored. If I use ifup/ifdown manually everything works as expected. Ifcfg file follows:



IPV6INIT=no
ONBOOT=no
USERCTL=yes
PEERDNS=no
TYPE=Modem
DEVICE=ppp0
BOOTPROTO=dialup
LINESPEED=921600
MODEMPORT=/dev/ttyUSB0
IDLETIMEOUT=0
PROVIDER=orange
DEFROUTE=yes
PERSIST=yes
WVDIALSECT=myprov
MODEMNAME=myprov
DEMAND=no
AC=off
BSDCOMP=off
VJCCOMP=off
CCP=off
PC=off
VJ=off
NM_CONTROLLED=yes
PAPNAME=any
PPPOPTIONS=
DNS1=192.168.1.254
DOMAIN="secret.lan"
Comment 15 Dan Williams 2009-10-16 14:09:26 EDT
Ok, this could be because the ifcfg-rh plugin does not support 3G connections yet, while the keyfile plugin does.  But your config is an ifcfg file of course.

This is somewhat difficult, because the ifcfg files list ppp0, which is *not* actually the interface of the 3G card.  Plus there's wvdial, so the required configuration is spread between 3 different places.

NM needs to figure this out better too; we don't support unmanaged 3G devices yet.

So for the moment, either this needs to be reconfigured as a user connection, or it needs to be a keyfile system connection.  Do you need this connection before login?  If not, I'd suggest going through the mobile broadband wizard to set up the connection in nm-applet, then using it that way.  Otherwise, let me know and we can make it a system connection too.
Comment 16 Bug Zapper 2009-11-18 05:17:55 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Hicham HAOUARI 2009-12-03 19:13:32 EST
NetworkManager should detect interfaces not managed and just display that there is connection, just like Mandriva's drak-network
Comment 18 Bug Zapper 2009-12-18 02:07:09 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.