Bug 803752

Summary: ifup-eth and ifdown-eth incorrectly handle bridged devices and unreliably build and tear down tunnels for TAP devices
Product: [Fedora] Fedora Reporter: Steve Willoughby <steve.willoughby>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: iarlyy, initscripts-maint-list, jonathan, lnykryn, notting, plautrba, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 19:33:12 UTC Type: ---
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
sample ifcfg-ethx and ifcfg-tapx files and patch files to correct the problem
none
Some examples of common net config files
none
revised patch file to replace ifup-eth.f16.pat none

Description Steve Willoughby 2012-03-15 15:17:28 UTC
Created attachment 570318 [details]
sample ifcfg-ethx and ifcfg-tapx files and patch files to correct the problem

Description of problem:
ifup-eth builds a bridge device but does not assign addresses or other interface specific properties. Sometimes a second 'service network restart' will get an address assigned. Ifup-eth uses tunctl to build a TAP device tunnel I/F but the way tunctl is used creates tunx or tapx devices other than the intended number when invoked more than once because ifdown-eth does not correctly tear down the tunnel using tunctl. I was also not able to use tunnels created by tunctl with openvpn. Also noted that the bridge and member interfaces were not explicitly set to promiscuous mode. Openvpn reliably creates tap and tun device interfaces, so is preferred over tunctl when available.

Version-Release number of selected component (if applicable):
initscripts-9.34-2.fc16.x86_64

How reproducible:
always

Steps to Reproduce:
1. introduce BRIDGE=br0 into ifcfg-eth files
2. reboot or execute 'service network restart' 
3.
  
Actual results:
bridge will be created, but no IP address will be assigned to the br0 device nor the eth devices. Example ifcfg files attached.

Expected results:
bridge should be created with an IP address specified in one of the ifcfg-ethx files.

Additional info: provided are some ifcfg files used to reproduce the issue. Also provided are patch files to fix the problem: correctly apply interface parameters to the bridge device, apply promiscuous mode to the bridge device and member interfaces, create tun and tap interfaces preferentially using openvpn (if available), then tunctl, correctly tear down tun and tap interfaces, reliably remove members from the bridge and tear down the bridge on last member removal.

The f16.pat files are for Fedora 16 and the cos.pat are for CentOS 6.2. I have filed a separate bug report for CentOS 6.2.

Comment 1 Bill Nottingham 2012-03-15 15:27:53 UTC
The config files look wrong - IP addresses go in the bridge configuration file, not in the underlying device file.

Comment 2 Steve Willoughby 2012-03-26 20:58:08 UTC
Can you provide a set of sample config files or point me to the documentation on how this is supposed to be done - I haven't found anything that really covers this in enough detail to make it work as you seem to indicate.

Comment 3 Bill Nottingham 2012-03-26 21:05:03 UTC
All the IP configuration would go in a ifcfg-br0 file with TYPE=Bridge.

Comment 4 Bill Nottingham 2012-03-26 21:06:34 UTC
I.e., something like this ifcfg-br0:

DEVICE="br0" 
NAME="br0" 
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE=Bridge
BRIDGE="br0"
STP="yes"   
IPV6INIT=no 
BOOTPROTO=none
IPADDR=192.168.2.1
PREFIX=24
#GATEWAY=192.168.2.1
DNS1=192.168.2.10   
DNS2=192.168.2.1    
DNS3=208.67.220.220 
DOMAIN=here.local  
DEFROUTE=no
IPV4_FAILURE_FATAL=yes

The IP configuration would then be removed from ifcfg-eth0, so it just looks like:

DEVICE="eth0"
NAME="eth0"
NM_CONTROLLED="no"
ONBOOT="yes"
HWADDR=00:21:85:44:3f:3C
TYPE=Ethernet
BRIDGE="br0"

Comment 5 Steve Willoughby 2012-04-02 17:20:56 UTC
Created attachment 574565 [details]
Some examples of common net config files

Add aditional documentation to initscripts to provide some samples of common network configurations including use of bridged interfaces and tunnels.

Comment 6 Steve Willoughby 2012-04-02 17:24:35 UTC
Created attachment 574570 [details]
revised patch file to replace ifup-eth.f16.pat

Reverted to account for correct handling of bridge address configuration with correctly formatted ifcfg-br0 file.

Comment 7 Bill Nottingham 2012-04-02 19:42:11 UTC
That still doesn't look right (note: diff -u format preferred) - the bridge settings should not need frobbed from the device config file.

Comment 8 Fedora End Of Life 2013-01-16 16:09:40 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. 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 '16'.

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 16'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 16 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 to click on 
"Clone This Bug" and open it against that version of Fedora.

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 9 Fedora End Of Life 2013-02-13 19:33:16 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.