Problem is simple they need to do it like LUCENT. Make it selectable in ab for use its own mac to shadow the rest show the computers mac address like it used to, or even mask the mac address with a designated one :)
-----Original Message-----
From: Lars Gaarden [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 19, 2003 11:10 AM
To: [EMAIL PROTECTED]
Eje Gustafsson wrote:
> No just frustrated at sB. But as I said glad you guys finally come to
> wits and understand that there is something with standards.. Makes
> life so much easier when things follow standards.. How about fixing
> the bridging mode to a RFC compliant mode for the aB's ?
As in transparent bridging? sB made a decision to make the aB as
compatible as possible with any AP out there. You absolutely
need "address 4" support on the AP for true transparent bridging,
but it is unfortunately optional in the 802.11* spec.
The current multimac aB is a trade-off between the way that the
RFCs expect the IP and Ethernet layers to behave and how an
AP that does not support "address 4" behaves.
In an ideal world, the aB would also include support for client
bridge. You could then choose which mode is best for your network.
To summarize:
- Old aB mode (0.09.10):
- Transparent bridging for a single MAC address.
- No remote admin.
- Works with any AP.
- Current aB multimac mode (0.01.07):
- MAC translation bridging that supports IP/ARP, PPPoE and DHCP.
- Remote admin.
- Works with any AP.
- aP client bridge mode:
- True transparent bridge.
- Remote admin.
- AP must support "address 4".
--
LarsG
The PART-15.ORG smartBridges Discussion List
To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname>
To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges)
Archives: http://archives.part-15.org
