Eygene Ryabinkin wrote:
I tried to understand this, because Bruce already gave me a patch,
but I am a bit stupid: I do not see how M_PROMISC that is cleared
unconditionally before BRIDGE_INPUT will help us to identify the
right interface. As I see now, the BRIDGE_INPUT is called once from
if_ethersubr.c, once from if_gif.c and once from ng_ether.c:
http://fxr.watson.org/fxr/ident?i=BRIDGE_INPUT
So there is no distinct code paths that can allow BRIDGE_INPUT to
modify its behaviour based on the M_PROMISC flag.
But I feel that I am wrong in some place and missing some discuission
on the M_PROMISC. Can anyone point me to the right place?
In short: M_PROMISC exists to easily identify frames which were received
promiscuously, to prevent infinite recursion, and to simplify code which
needs to re-enter ether_input().
M_PROMISC is a flag introduced by NetBSD into their ethernet input path
to deal with the case where an entity in the network stack needs to
receive frames promiscuously, without necessarily passing those frames
to the upper layers e.g. IPv4. It is not documented; the code is the
documentation in this instance.
It is cleared when an mbuf chain is passed to another entity which may
consume the frame in that mbuf chain, in case the entity re-enters
ether_input() with the same mbuf chain for local delivery (e.g. bridge,
netgraph, vlan).
I do not think M_PROMISC alone is sufficient to solve our architectural
problems at Layer 2.
So all the tangled if()s inside LIST_FOREACH() will be gone completely
from bridge_input().
But we still need to see if we want to consume the packet by the
bridge or it members or to do forwarding. Am I missing something?
Correct. Just because a frame was received promiscuously, does not imply
that the bridge will be the only consumer of that frame.
I'm afraid there is a serious flaw in the very notion of such a
"logical" interface. If it's true, we should start by admitting
that the support for "logical" interfaces should be a side hack for
compatibility, and not something that can live forever on the main
code path.
I agree with you. That is why I patched if_bridge once again to enable
the pfil hooks for the "physical" incoming interface. And there are
two ways to solve the problem:
- to give each VLAN interface the distinct MAC, as Bruce suggested,
I didn't suggest this. :-) I pointed out that the code matches on
destination MAC only at the moment.
vlan(4) is an abstraction of something which exists as part of the
Ethernet framing, and is not a physical interface in its own right, as
was correctly identified above.
- to refuse the "logical" interfaces completely and to support only
"physical" ones. It is what my very first (and very short) patch
did. But this can break some existing firewall rulesets. And that
should be discuissed -- we do not need the total breakage due to
out changes. And you're right: the best way for this alternative is to
leave the current behaviour as the compatibility sysctl that is turned
off by default and move to the filtering on the "physical" interfaces
by default. No problem, but skilled network people that are using
FreeBSD as the bridge for VLANs should say if they are happy with it.
I think it is acceptable for if_bridge(4) to know about the existence of
VLAN interfaces and to deal with them accordingly as a special case,
because Spanning Tree is specified differently in the case where VLANs
are present. Therefore it is not unreasonable for if_bridge(4) to be
looking at VLAN headers in the mbuf chain.
As such I think the behaviour Andrew Thompson and I were discussing off
list should be made the default: that is, the first 802.1q VLAN header
is stripped off and turned into an M_VLANTAG before being passed to
other consumers in the stack.
The presence of M_VLANTAG makes it very easy to see that a frame was
received with a VLAN header without involving vlan(4) and reduces the
amount of 802.1q specific code across Layer 2 subsystems.
Regards,
BMS
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
