Project

General

Profile

Actions

Bug #4312

closed

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

Added by dominique dupont almost 10 years ago. Updated almost 9 years ago.

Status:
Resolved
Priority:
Normal
Category:
Interfaces
Target version:
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

Actions #1

Updated by Chris Buechler almost 10 years ago

  • 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.

Actions #2

Updated by Chris Buechler over 9 years ago

  • Target version changed from 2.2.2 to 2.2.3
Actions #3

Updated by Chris Buechler over 9 years ago

  • Target version changed from 2.2.3 to 2.3
Actions #4

Updated by Jim Thompson about 9 years ago

  • Assignee set to Chris Buechler

assigned to cmb for re-eval against 2.3

Actions #5

Updated by Chris Buechler almost 9 years ago

  • 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

Actions #6

Updated by Chris Buechler almost 9 years ago

  • 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.

Actions #7

Updated by Chris Buechler almost 9 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions #8

Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to Confirmed
Actions #9

Updated by Chris Buechler almost 9 years ago

  • Status changed from Confirmed to Feedback
Actions #10

Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to Resolved

works

Actions

Also available in: Atom PDF