Dear all, 

I'm not sure whether we are using the bridge feature as intended, so I'd like to ask if we are using it properly (as 
intended) 

We are bridging two tsec's on an MPC8548 to a single IP interface using QNX 6.5.0. 

Here is how we fire it up: 
    (Start iopkt on tsec0)
    (mount driver for tsec1)
    /sbin/ifconfig tsec0 inet up
    /sbin/ifconfig tsec1 inet up
    /sbin/ifconfig bridge0 create
    /sbin/brconfig bridge0 add tsec0 add tsec1 up

I'm getting an error when trying to IP configure bridge0 : 
# ifconfig bridge0 inet 192.168.112.23
ifconfig: SIOCAIFADDR: Inappropriate I/O control operation

So instead we are configuring port tsec0 with the system's IP address, which works. 
Is that the intended way to configure the bridge ? 

Intuitively I would have thought that our configuration sequence creates a bridge0 virtual port that 'shadows' both 
physical ports tsec0 and tsec1, inherits the MAC address from the first port which was added to the bridge (in this case
 tsec0) and  I would have expected in fact that I could not configure tsec0 and tsec1 with IP addresses anymore, since 
they are shadowed by the  bridge port. I realize from an Ethernet segment point of view it doesn't really matter though 
as everything is bridged together.

Having the bridge created as described above actually allows me to configure tsec0 and tsec1 with different IP addresses
. Are the following configurations then equal from a peer's perspective, no matter to which tsec port it is physically 
connected ? 
(A) tsec0 <- IP#A , tsec1 <- IP#B
(B) tsec0 <- IP#A and aliased IP#B (tsec1 not configured) 

(IP#A and IP#B are on different subnets.)

Here is another thing we are uncertain about in conjunction with IP Multicasts and the bridge: 

We are currently using configuration method (A) since we implicitly know the network topology (in almost any case ; see 
below) and thus which receivers are sitting behind which physical port. One of our applications is going to be a 
multicast sender. It wants to send multicast packets to receivers listening on the IP subnet #B, so it binds an IP 
multicast capable socket on IP#B (tsec1) using the socket option IP_MULTICAST_IF. I assume that this prevents the stack 
from sending the multicast packet out of tsec0 , despite the configured bridge. Is that correct ? 

If yes, is there any way to set things up such that the multicast packet is sent out of both physical ports ? 

To make things more complicated, we are considering enabling STP on the bridge ports to circumvent the case where 
someone created physical loops using external switches. What would be a proper configuration setup such that the system 
maintains full connectivity (including to the multicast receivers) when STP decides to block one of the bridge ports ? 

Thanks for answering my noob questions in advance :) 
Christopher.