with initscripts-8.11.1-1 When using a wireless card in Master mode if you add BRIDGE=br0 to ifcfg-ath0 (with the appropriate ifcfg-br0, etc setup) the wireless card goes into managed mode. Removing BRIDGE=br0 causes the wireless card to come up in master mode as desired but obviously is not in the bridge. This is due to the order things happen in ifup-eth. I moved the wireless check before the bridging section and modified the bridging section as such: # is the device wireless? If so, configure wireless device specifics is_wireless_device ${DEVICE} && . ./ifup-wireless if [ -n "${BRIDGE}" -a -x /usr/sbin/brctl ]; then if [ ! -n "${MODE}" ]; then /sbin/ip addr flush dev ${DEVICE} 2>/dev/null /sbin/ip link set dev ${DEVICE} up fi /usr/sbin/brctl addif ${BRIDGE} ${DEVICE} # Upon adding a device to a bridge, # it's necessary to make radvd reload its config [ -r /var/run/radvd/radvd.pid ] && kill -HUP `cat /var/run/radvd/radvd.pid` exit 0 fi this seems to fix the problem.
Actually, now that i look at it, i think the only modification necessary is the moving of the wireless check - the extra if within the bridging section fails to bring the interface up now. Sorry!
I believe some clarification is needed here. If a ethernet device is bridged (by having a "BRIDGE=br0" or similar entry in its ifcfg-eth* script), then nothing after line 79 in the ifup-eth script is executed because of the `exit 0` after the radvd reload. This includes, amongst other things, the check by the ifup-eth script to see if the device has wireless extensions and if so, the execution of ifup-wireless. Therefore none of your wireless parameters are actually propergated to the device. As to what the sollution is, I'm not entirely sure just moving the wireless check is sufficient. I have only a limited knowledge in these scripts; can any of the experts please determin if anything after the bridge check is also neccessary to be invoked? If so, either the checks need to be reordered or something needs to be done about the exit 0 on line 79. Kind regards.
*** This bug has been marked as a duplicate of 122801 ***