A: You don't have bridging capability in your kernel.
Get a 2.0 or greater kernel,
and recompile with the BRIDGING option enabled.
A:
Did you enable bridging using brcfg -ena? (brcfg should say bridging is ENABLED)Did you put the interfaces into promiscuous mode?
(issue the ifconfig command.
The PROMISC flag should be on for
both interfaces.)If using multiple-media interface adapters,
make sure that the correct one is enabled.
You may need to use the config/setup program that
came with the network interface card.A: This is because there is no IP address bound to any of bridge
interfaces. A bridge is to be a transparent part of a network.
A: Nothing!
All routing intelligence is handled by
the bridging code in the kernel.
To see the ethernet addresses as they are learned by the bridge,
use the brcfg program in debug mode:
A: Due to the nature of a bridge, a traceroute should NOT show the bridge as a part of the path. A bridge is to be a transparent component of the network.
A: No. The bridging code in the kernel takes care of the packet
transport.
IP_FORWARD is for a gateway that has IP addresses
bound to its interfaces.
A: No. Every port on a bridge intentionally is assigned the same
physical ethernet address by the bridging code.
A: During the kernel config, answer "Y" to the question, Prompt for
development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?].
A: A bridge resets the 3/4/5 hubs rule. A bridge does not deal with
packets the way a hub does, and is therefore not a contributor to
timing problems on a network.
A: Yes, a bridge can tie together a 10Mb segment with a 100Mb segment.
As long as the network card on the fast network is 100Mb capable,
TCP takes care of the rest. While it's true that the
packets from a host in the 100Mb network communicating to a host
in the 10Mb network are moving at only 10Mb/s, the rest of the
traffic on the fast ethernet is not slowed down.
Take our 
