> Date: Tue, 19 Nov 1996 18:37:24 -0800 (PST)
> From: Al Longyear <longyear@netcom.com>
> To: Zoltan Hidvegi <hzoli@cs.elte.hu>
> Cc: linux-net@vger.rutgers.edu
> Subject: Re: Bug related to bridge & PPP
>
>
> Zoltan Hidvegi wrote:
>
> > I recently tried the linux ethernet bridge code. It worked perfectly but I
> > encountered one problem. The machine which I used as a bidge was a normal
> > server, with two modems for PPP dial-in. But when the bridge code was
> > enabled, the ppp client and the server was unable to communicate with each
> > other. But surprisingly the machine correctly forwared each IP packet so
> > every other site was usable from the client exept the ppp server itself.
> > As soon as brcfg -dis command was issued the server started seeing the
> > client but and other brcfg -ena broke the connection again (but forwarding
> > still worked).
>
> > It was not even necessary to have to ethernet car or a real bridge. After
> > ifconfig eth1 down and ifconfig eth0 -promisc the same happened.
>
> I do not know much about the specifics of the bridging code in
> Linux. However, in general, a bridge goes through a process called
> 'learning' whereby they listen but do not forward frames on each side
> of the link. The idea is to know what systems are on which side of the
> network.
Er, actually, I beleive the correct behaviour in "learn" mode is to
forward _all_ packets, saving the source MAC address for each packet, and
the next time a packet comes from some other MAC address, via that same
interface, with a destination MAC address that the bridge has receved
transmitted traffic from, it knows the two devices are on the same of it,
and doesnt forward the packet..
>
> This is done with the adapters in promiscous mode so that they can
> pick up on each frame sent on each side of the network.
>
> At the end of the learning period, they switch to the 'forwarding'
> mode. They have built the tables for the IP addresses on each side of
> the network. So, they stay in promiscous mode and listen for frames
> destined for the other side of the network. They then forward the
> frame according to the other side.
>
> After a while of doing this, they go back to the learn mode and pick
> up new systems or detect that systems have been moved.
>
> This whole process is repeated over and over and over while the bridge
> is in operation.
>
> Ok. This leads to two problems with attempting to bridge across a PPP
> link with the standard bridging logic of Linux.
>
> 1. The PPP interface is unable to go into promiscous mode for the same
> reason that a broadcast frame does not go through the link; a point to
> point link is defined to be a direct link between two computers. There
> is no need to define a 'broadcast to many' or 'listen for any other
> senders' on the link.
>
> 2. There is no method by which the frames will be inherently forwarded
> to the link. You must send them directly to the system with the PPP
> device and have that system know that the frames to be sent to the
> other side of the link.
>
> So, how can you do bridging with a PPP (or SLIP or PLIP or any other
> point-to-point link)?
>
> You do this by making a variation of the IP routing function. You
> include host specific routes for each host on the other side of the
> link with the ppp device as the target. You then use proxyarp on that
> system so that it recognizes the IP address of the systems on the
> other side of the link.
>
> This is not dynamic as a true ethernet bridge would be, but it will
> work.
>
> --
> Al Longyear longyear@netcom.com Finger for PGP key
> Design is about changing your mind until you get it correct.
>