Bug 1008247

Summary: name address resolution problem if 2nd ethernet card is enabled
Product: [Fedora] Fedora Reporter: floyd smith <floydsmith>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 19CC: dcbw, jklimes, johannbg, lnykryn, mschmidt, msekleta, plautrba, systemd-maint, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 17:12:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
WHEN_OK
none
WHEN_NOT_OK
none
IPOUT FOR F20 WHEN OK
none
IPOUT FOR F20 WHEN NOT OK none

Description floyd smith 2013-09-15 23:09:59 UTC 
Description of problem:
Version-Release number of selected component (if applicable):
systemd-204-8 and 204-11

How reproducible:
Everytime

Steps to Reproduce:
My machine has two ethernet cards - the first is used exclusively for internet access - the 2ND only for a pointopoint connection to a nfs server.
To demonstrate the problem I after a fresh install of pristine fedorda 19 (using kernel 3.9.5-301 and systemd-204-8) I logged into Gnome desktop and did the following steps:
1) With the 2ND ethernet cable unplugged and left that way (this is NOT necessary - it is done here only to show that problem has nothing to do with any traffic on that card) I test that the 1st card can reach the internet using any method that needs name address resolution - example use of yum download or simply load a page using a browser such as firefox or google-chrome. At this point the page is reached OK.
2) (Now, the 2ND ethernet card can NOT be enabled using the upper right side ethernet enable button enabler button with the it unplugged.) But it can by clicking the Network Setting and doing the following:
	A) Set it to ON
	B) Click Add Profile:
	C) Select IPv6 
	D) Use:
		I) addresses - Manual 
		II) address: 169.254.0.2 for nfs client address (again NO traffic will go across for the demonstration but these steps are MANDATORY to demonstrate)
		III) Netmask: 255.255.255.0
		IV) Gateway: 169.254.0.1
		V) set DNS to OFF.
	E) Click ADD
At this point again check that some address can be reached using an URL - load a page for example - everything will work OK with 1st card reaching the internet.
3) Now reboot the machine. Upon entering Gnome (or a tty terminal) try to reach a page. If using yum it will endlessly loop trying to reach a repository server. If using firefox it will say Server Not Found. If using google-chrome it will say The web page is not available but will show ERR_NAME_RESOLUTION_FAILED. Now, rebooting AND DOING NOTHING ELSE the problem will go away (temporarily); that is, domain name resolution will work for all cases. But the problem will occur again on the next boot (AGAIN. WITHOUT DOING ANYTHING) but only to disappear on the next boot and so on.
Now, neither the contents nor the ls -lZ properties of file /etc/resolv.conf change in any way during all of this.
There are two ways to return to a state where the problem does not occur - first, remove the 2ND card, second remove the profile (rm /etc/sysconfig/network-scripts/ifcfg-Profile_1 in my case)
This problem does not occur at all in fedora 18 with systemd-201.
The problem also does occur in f19 systemd-204-11 (the latest).

1.
2.
3.

Actual results:

name resolution fails
Expected results:
should not do this

Additional info:
Comment 1 Michal Schmidt 2013-09-16 11:19:06 UTC 
This is not likely to be related to systemd. You seem to be using NetworkManager for configuring your network interfaces, so let's start there. [Reassigning]

I guess you could attach the outputs of the commands "ip link", "ip addr", "ip route" in both the working and the broken case to help the NM developers see what's going on.
Comment 2 floyd smith 2013-09-16 20:31:15 UTC 
Created attachment 798421 [details]
WHEN_OK
Comment 3 floyd smith 2013-09-16 20:32:21 UTC 
Created attachment 798422 [details]
WHEN_NOT_OK
Comment 4 Jirka Klimes 2014-02-11 13:51:55 UTC 
Sorry for the late response. But if you still have a problems, can you post the following info when both cards are connected:
$ can you ping 8.8.8.8
$ cat /etc/resolv.conf
$ nmcli device status

Anyway, the problem seems to be in that in non-working case you use a link-local address 169.254.0.2
2: p6p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether bc:ae:c5:65:58:2b brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.2/24 brd 169.254.0.255 scope global p6p1

as opposed to

2: p6p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether bc:ae:c5:65:58:2b brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global p6p1

Check you profiles e.g. in nm-connection-editor.
Comment 5 floyd smith 2014-02-11 23:53:12 UTC 
Created attachment 862054 [details]
IPOUT FOR F20 WHEN OK
Comment 6 floyd smith 2014-02-11 23:54:57 UTC 
Created attachment 862055 [details]
IPOUT FOR F20 WHEN NOT OK
Comment 7 floyd smith 2014-06-22 00:51:33 UTC 
 The attachments I left on 2014-02-11 show that the problem not only exists in f19 but f20 but as I explained earlier NOT in f18.
 Again, as the attachments for for both the f19 and f20 case show that the DNS address for the primary card gets changed from its correct gets from my gateway/modem which I have it connected to when I install the OS to the incorrect address which is for my added second interface card thus preventing the first from being able to access the internet.
 Now, you seem think that my problem is that I am changing the profile for the primary card at some time and that it is a USER error.
 I AM NOT!!!
 AGAIN AS ORIGINALLY EXPLAINED THE 1ST CARD HAS THE CORRECT DNS ADDRESS AFTER AN INSTALL AN BEFORE THE 2ND CARD IS ADDED WHICH HAS A STATIC ADDRESS BECAUSE IT IS A POINTTOPOINT CONNECTION TO A NFS SEVER.
 Again, here are the steps to verify the problem.
 Install a fresh copy of either f19 or 20.
 VERIFY THAT THE CARD CONNECTED TO THE GATEWAY/MODEM CAN REACH THE INTERNET - THAT PROVES THAT IT HAS THE CORRECT DNS ADDRESS.
 AT THIS POINT AGAIN VERIFY THAT BOTH BEFORE AND AFTER ANY REBOOT THAT THE 1ST CARD CAN STILL REACH THE INTERNET.
 Now, at this point create a profile for the 2nd card added and give it a static address - I use 169.254.0.2 - but any will do.
 Again, verify that the 1st card still connects to the internet.
 NOW TO DEMONSTRATE THE PROBLEM DO JUST ONE THING - JUST REBOOT - THATS IT!!!
 The DNS code in f19 and 20 (BUT NOT BEFORE THAT) changes its DNS address to that of the static address of the added 2nd card.
 THAT IS ABSURD.
 Now, somebody added code beginning in f19 that does that. 
 Now, if some customer insisted that this be done then there MUST be a check box in the add profile procedure that says:
 CHECK THIS BOX IF YOU WANT TO LOOSE YOUR INTERNET CONNECTION BY HAVING THE DNS ADDRESS IT NORMALLY GETS CHANGED TO STATIC ONE YOU ARE ADDING HERE FOR YOUR 2ND CARD.

 Floyd,
Comment 8 floyd smith 2014-06-22 10:55:07 UTC 
Addendum to the above.
I forgot to mention that it is NOT the DNS (resolve) address that gets changed here but the DHCP address (for the 1st card - the 2nd uses static address so no DHCP is involved). But when the DHCP address gets replaced on the reboot after the profile create for the 2nd then the error message when accessing the internet is that it can't find the DNS server. This is because if it can't reach the gateway/modem by loss of the DHCP address then it most certainly can't reach the DNS server. Also you may wonder how I am positive that I am not changing the address for the 1st card. It is simple. Since I have the 2nd card directly connected (no internet involved) to a NFS server - it starts working only after I create a profile for it which causes the problem for the 1st. Also the profile I create has a name based on its PNP PCI card slot number.

Floyd,
Comment 9 Fedora End Of Life 2015-01-09 19:51:22 UTC 
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.
Comment 10 Fedora End Of Life 2015-02-17 17:12:07 UTC 
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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