Yar,
> > 2. In the case where 802.3ad trunking is implemented, the same Ethernet
> > address may be used by multiple physical interfaces.
> >
> > 3. As Eygene explained well: there are a number of consumers of
> > Ethernet frames in the stack. As if_bridge may potentially be passed
> > mbuf chains containing packets for these consumers first, it must
> > examine the destination address to determine if it should claim the
> > packet or not.
> >
> > Finally, because of the above points, the Ethernet destination address
> > cannot be regarded as a unique key in the bridge code, or indeed the
> > general Ethernet path, for where packets should be relayed in the stack
> > as a whole.
>
> But why are we relying solely on the Ethernet destination address?
Probably because if_bridge is written for Ethernet, 802.11 and
may be some other 802 interfaces:
-----
DESCRIPTION
The if_bridge driver creates a logical link between two or more IEEE 802
networks that use the same (or ``similar enough'') framing format. For
example, it is possible to bridge Ethernet and 802.11 networks together,
but it is not possible to bridge Ethernet and Token Ring together.
-----
> Each frame was received via a particular interface, which is recorded
> in mbuf's recvif. As the frame moves between levels of abstraction,
> such as a physical interface, vlan, bridge, recvif can change, but
> at each level the pointer to an entity in the previous level should
> be enough, shouldn't it?
Excuse me, but are we talking about the problem that is cured by
our patch, or about some general points? If about the former, then
this problem shows up only for the packet that is destined for the
local interface at the L2. And the pfil gots the wrong interface name
due to the bug.
> E.g., if several vlan interfaces are
> bridged, if_bridge shouldn't need to know which physical interfaces
> are used by the vlans. OTOH, it can know which particular vlan the
> frame came through, although vlan MACs can be the same.
And who is saying that if_bridge should need to know about the
underlying (parent) interface for the VLAN? The word 'physical' that
we use here denotes the VLAN interface in which the packet showed up
at ether_input. And the word 'logical' means the interface that
the L2 packet is destined for. Perhaps it is the source of confusion?
--
Eygene
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
