Bug #4312
closed
Bridge advanced settings not always applied after interface is added to bridge
100%
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
Updated by Chris Buechler over 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.
Updated by Chris Buechler over 10 years ago
- Target version changed from 2.2.2 to 2.2.3
Updated by Chris Buechler over 10 years ago
- Target version changed from 2.2.3 to 2.3
Updated by Jim Thompson almost 10 years ago
- Assignee set to Chris Buechler
assigned to cmb for re-eval against 2.3
Updated by Chris Buechler almost 10 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
Updated by Chris Buechler almost 10 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.
Updated by Chris Buechler almost 10 years ago
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Applied in changeset 9af087de91a2612e27023a4856a186215e350d9d.
Updated by Chris Buechler almost 10 years ago
- Status changed from Feedback to Confirmed
Updated by Chris Buechler almost 10 years ago
- Status changed from Confirmed to Feedback