Project

General

Profile

Actions
Copy link

Bug #4312

closed
DD CB

Bridge advanced settings not always applied after interface is added to bridge

Bug #4312: Bridge advanced settings not always applied after interface is added to bridge

Added by dominique dupont over 11 years ago. Updated over 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Chris Buechler
Category:
Interfaces
Target version:
2.3
Start date:
01/27/2015
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

Description

on 2.2 release
after reboot, the option PRIVATE PORTS (ovpns6 and ovpnc4 for my example) of BRIDGE not work (brigde of VPN mode TAP):

bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:cc:1b:1f:6a:00
nd6 options=1<PERFORMNUD>
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: ovpnc4 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 12 priority 128 path cost 2000000
member: ovpns6 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 10 priority 128 path cost 2000000
member: ovpns2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 2000000
member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 20000

you must resave the configuration of bridge to make it work

after resave :
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:cc:1b:1f:6a:00
nd6 options=1<PERFORMNUD>
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: ovpns6 flags=943<LEARNING,DISCOVER,*PRIVATE*,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 10 priority 128 path cost 2000000
member: ovpns2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 2000000
member: ovpnc4 flags=943<LEARNING,DISCOVER,*PRIVATE*,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 12 priority 128 path cost 2000000
member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 20000

CB Updated by Chris Buechler over 11 years ago Actions
Copy link
 #1

  • Subject changed from BRIDGE option PRIVATE PORTS not work after reboot to bridge private ports problem with tap members
  • Status changed from New to Confirmed
  • Target version changed from 2.2.1 to 2.2.2

it works in general. seems specific to tap interfaces, probably at least partially because they come up/are changed later in the boot process.

CB Updated by Chris Buechler over 11 years ago Actions
Copy link
 #2

  • Target version changed from 2.2.2 to 2.2.3

CB Updated by Chris Buechler over 11 years ago Actions
Copy link
 #3

  • Target version changed from 2.2.3 to 2.3

JT Updated by Jim Thompson almost 11 years ago Actions
Copy link
 #4

  • Assignee set to Chris Buechler

assigned to cmb for re-eval against 2.3

CB Updated by Chris Buechler over 10 years ago Actions
Copy link
 #5

  • Status changed from Confirmed to Resolved
  • Affected Version changed from 2.2 to All

Same problem was still in 2.3.

When interfaces_bridge_configure runs during boot, the tap interfaces don't yet exist. rc.newwanip is what ends up adding tap interfaces to the bridge, which was using interface_bridge_add_member(). interface_bridge_add_member skips applying the private setting as well as a slew of other settings which may apply. Calling interface_bridge_configure() on the appropriate bridge instead ensures private and all other settings are correctly applied to interfaces that didn't exist at the time of bridge creation.

fixed

CB Updated by Chris Buechler over 10 years ago Actions
Copy link
 #6

  • Subject changed from bridge private ports problem with tap members to Bridge advanced settings not always applied after interface is added to bridge
  • Status changed from Resolved to Confirmed

that change lead to issue #5888, so this was reverted. different fix coming.

CB Updated by Chris Buechler over 10 years ago Actions
Copy link
 #7

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

Applied in changeset commit:9af087de91a2612e27023a4856a186215e350d9d.

CB Updated by Chris Buechler over 10 years ago Actions
Copy link
 #8

  • Status changed from Feedback to Confirmed

CB Updated by Chris Buechler over 10 years ago Actions
Copy link
 #9

  • Status changed from Confirmed to Feedback

CB Updated by Chris Buechler over 10 years ago Actions
Copy link
 #10

  • Status changed from Feedback to Resolved

works

Actions
Copy link

Also available in: Atom