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 9 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 9 years ago
- Target version changed from 2.2.2 to 2.2.3
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.3 to 2.3
Updated by Jim Thompson almost 9 years ago
- Assignee set to Chris Buechler
assigned to cmb for re-eval against 2.3
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
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.
Updated by Chris Buechler almost 9 years ago
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Applied in changeset 9af087de91a2612e27023a4856a186215e350d9d.
Updated by Chris Buechler almost 9 years ago
- Status changed from Feedback to Confirmed
Updated by Chris Buechler almost 9 years ago
- Status changed from Confirmed to Feedback