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.
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.
(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?
I had S98haldaemon on my machine. Probably residuum of upgrade from previous version. Fixed.
(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.
The devices are controlled as appropriate when priorities of services are restarted. But I am still not able to disable changing of resolv.conf.
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.
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.
Just read my first report. I have PEERDNS=no set up. But it is ignored.
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?
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
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.
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).
(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?
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"
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.
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
NetworkManager should detect interfaces not managed and just display that there is connection, just like Mandriva's drak-network
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.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days