Hi Rishsi,
Do you want me to file the man page CR?
I'll ask them to remove "wireless links," from
the second sentence of the following paragraph
in the description of the add-bridge subcommand:
The links assigned to a bridge must
not also be VLANs, VNICs, or tunnels.
Only physical Ethernet datalinks,
aggregation datalinks, wireless links,
and Ethernet stubs are permitted to
be assigned to a bridge.
Let me know if this is okay and whether you
want other changes to the man page, as
well.
Cathleen.
On 05/21/10 07:42, James Carlson wrote:
Rishi Srivatsavai wrote:
Thanks David. I will see if there is a RFE filed on this already,
if not I will file one. The RFE should provide a way to determine
whether the driver (and device) supported emitting frames
with a source address different from device MAC address.
If such a method was available we don't have to limit bridging
support by media type.
I don't think that's true. There are at least two issues here: are the
MAC headers (and addresses contained within) and frame formats directly
compatible, and can the driver transmit packets unmolested?
The potential 802.11 issue is with the latter part of that. But even if
that were solved with some kind of new predicate, the former part would
still be a problem. You wouldn't want to bridge Ethernet onto FDDI.
(Well, if you were a customer you might want to do so, but you'd just be
wrong. ;-})
So, I don't think the existing MAC-type test goes away.
For now perhaps it is best to update the dladm manpage and
remove mention of wireless links as supported link type in
add-bridge subcommand.
Yep; I'd agree with that.
_______________________________________________
rbridges-dev mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/rbridges-dev
