Bug 441109 - NetworkManager overrides DNS received from provider
NetworkManager overrides DNS received from provider
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-06 07:03 EDT by Pavel Rosenboim
Modified: 2008-04-14 10:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-14 10:08:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pavel Rosenboim 2008-04-06 07:03:09 EDT
Description of problem:
NetworkManager overrides DNS setting received from ISP by pppoe and puts some
non-functioning DNS server in resolv.conf. I'm using DSL connection and selected
"Get DNS information from provider" (PEERDNS) option.

Version-Release number of selected component (if applicable):
NetworkManager-0.7.0-0.9.1.svn3521.fc9

How reproducible:
Always

Additional info:

ifcfg script:
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
TYPE=xDSL
DEVICE=ppp0
BOOTPROTO=dialup
ONBOOT=yes
USERCTL=yes
PEERDNS=yes
IPV6INIT=no
NETWORKMANAGER=yes
PIDFILE=/var/run/pppoe-adsl.pid
FIREWALL=NONE
PING=.
PPPOE_TIMEOUT=80
LCP_FAILURE=3
LCP_INTERVAL=20
CLAMPMSS=1412
CONNECT_POLL=6
CONNECT_TIMEOUT=60
PERSIST=no
SYNCHRONOUS=no
DEFROUTE=yes
USER='my user name'
ETH=eth0
PROVIDER=Bezeq
DEMAND=no
NM_CONTROLLED=yes

I tried both selecting and deselecting option "Controlled by NetworkManager",
but there are no differences.
Comment 1 Dan Williams 2008-04-08 13:02:30 EDT
Just to be clear, you don't want NM to control this device because you're using
PPPoE on it, right?

An update to NM later today or tomorrow should make the NM_CONTROLLED=no option
work for you here.  NM doesn't support the xDSL config type specifically yet.
Comment 2 Pavel Rosenboim 2008-04-08 14:42:32 EDT
Ok, I'll test it when it appears.

If excluding device from NM control will help me to keep valid resolv.conf, it
is definitely a solution. 
Comment 3 Dan Williams 2008-04-08 14:59:32 EDT
Well, this connection shouldn't be controlled by NM anyway since NM doesn't know
anything about xDSL devices quite yet.

What DNS server is NM putting in resolv.conf?  When you get into this situation,
can you run /usr/bin/nm-tool and attach the output?
Comment 4 Pavel Rosenboim 2008-04-08 15:12:07 EDT
It changes periodically. Today it put there 160.131.244.9.


Output of nm-tool:

NetworkManager Tool

State: connected

- Device: eth0 ----------------------------------------------------------------
  Type:              Wired
  Driver:            8139too
  Active:            yes
  HW Address:        00:02:44:2C:DC:E1

  Capabilities:
    Supported:       yes
    Carrier Detect:  yes
    Speed:           100 Mb/s

  Wired Settings

  IP Settings:
    IP Address:      10.0.0.1
    Subnet Mask:     255.255.255.0
    Broadcast:       0.0.0.0
    Gateway:         0.0.0.0
    DNS:             160.131.244.9


Comment 5 Dan Williams 2008-04-08 15:22:00 EDT
Can you grab some output from /var/log/messages from when NM connects the wired
device so I can see what the DHCP server is sending back?
Comment 6 Pavel Rosenboim 2008-04-08 15:45:56 EDT
There is no DHCP server. IP address for eth0 is static.

Right now I have NM disabled and network service enabled, as it is an only way
to get working config at boot. When I start NM service later I get following output:

Apr  8 22:04:47 localhost NetworkManager: <info>  starting...
Apr  8 22:04:48 localhost NetworkManager: <WARN> 
nm_system_device_get_system_config(): Network configuration for device 'eth0'
was invalid (non-DHCP configuration, but no gateway specified.  Will use DHCP
instead.
Apr  8 22:04:48 localhost NetworkManager: <info>  eth0: Device is
fully-supported using driver '8139too'.
Apr  8 22:04:48 localhost NetworkManager: <info>  Now managing wired Ethernet
(802.3) device 'eth0'.
Apr  8 22:04:48 localhost NetworkManager: <info>  Bringing down device eth0
Apr  8 22:04:48 localhost NetworkManager: <info>  Bringing up device eth0
Apr  8 22:04:48 localhost NetworkManager: <info>  Deactivating device eth0.
Apr  8 22:04:49 localhost NetworkManager: <info>  (eth0): exported as
/org/freedesktop/Hal/devices/net_00_02_44_2c_dc_e1
Apr  8 22:04:49 localhost NetworkManager: <info>  Trying to start the supplicant...
Apr  8 22:04:49 localhost NetworkManager: <info>  Trying to start the system
settings daemon...
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) starting
connection 'System eth0'
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5
(Device Prepare) scheduled...
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5
(Device Prepare) started...
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5
(Device Configure) scheduled...
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5
(Device Prepare) complete.
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5
(Device Configure) starting...
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5
(Device Configure) successful.
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5
(IP Configure Start) scheduled.
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5
(Device Configure) complete.
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5
(IP Configure Start) started...
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 4 of 5
(IP Configure Get) scheduled...
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5
(IP Configure Start) complete.
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 4 of 5
(IP Configure Get) started...
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 5 of 5
(IP Configure Commit) scheduled...
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 4 of 5
(IP Configure Get) complete.
Apr  8 22:04:51 localhost NetworkManager: <info>  Activation (eth0) Stage 5 of 5
(IP Configure Commit) started...
Apr  8 22:04:53 localhost NetworkManager: <info>  Policy set (eth0) as default
device for routing and DNS.
Apr  8 22:04:53 localhost NetworkManager: <info>  Activation (eth0) successful,
device activated.
Apr  8 22:04:53 localhost NetworkManager: <info>  Activation (eth0) Stage 5 of 5
(IP Configure Commit) complete.

Comment 7 Dan Williams 2008-04-08 16:50:33 EDT
Do you have /etc/sysconfig/network-scripts/ifcfg-eth0 at all?  If you do, NM is
likely picking that up and using that, grabbing the DNS or settings from there
instead.
Comment 8 Pavel Rosenboim 2008-04-09 01:43:11 EDT
Here is ifcfg-eth0:

# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0
BOOTPROTO=none
BROADCAST=10.0.0.255
HWADDR=00:02:44:2c:dc:e1
IPADDR=10.0.0.1
NETMASK=255.255.255.0
NETWORK=10.0.0.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=yes

I tried both NM_CONTROLLED=yes and no, it doesn't make any difference.
Comment 9 Dan Williams 2008-04-10 12:41:02 EDT
Can you try latest NM in rawhide (svn3549) and test if that still adds bogus DNS
information to resolv.conf?  I don't expect it to bring up your PPPoE config,
but it shouldn't be putting DNS servers in resolv.conf that you don't have
listed in ifcfg-eth0.
Comment 10 Pavel Rosenboim 2008-04-13 01:21:33 EDT
Great! It doesn't override the resolv.conf.
Comment 11 Dan Williams 2008-04-14 10:08:01 EDT
Ok; let me know if it breaks again, thanks!

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