>  It wants to send multicast packets to receivers listening on the IP subnet #B, 

After reading it again I realize that makes no sense, of course the receivers are just part of the appropriate multicast
 group. What I wanted to express is that they are physically connected to tsec1. 

Christopher.

On 10-09-24 12:52 PM, Christopher Pohl wrote:
> 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 ?

I believe so.

> 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 ?

They may not be totally transparent since tsec0 and tsec1 have different 
MAC addresses.

> (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 ?

No idea. I find it probable that the IP packet is sent on tsec1 but that 
bridge0 will bridge the packet on the Ethernet layer and send it out 
both Ethernet ports. They are the same broadcast domain after all. I 
don't know what the definition of IP_MULTICAST_IF would say in this 
case, but it makes sense that it acts on the IP layer only, since it's 
got "IP in its name... You'd have to look at the source. Or maybe 
somebody else knows? Or maybe experimentation will immediately give you 
the answer...

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

If it works the way I'm guessing it does (without spending any time 
looking at code or experimenting) then it'll go out both ports. If it 
doesn't and you want it to, then maybe you can send the packet out two 
sockets bound to different 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...