hello. Ok. I think I have a better understanding of what is
happening. It's important to understand that in our stack, regardless of
whether or not hardware vlan tagging is enable, the bpf engine sees all
packets with vlan tags twice: first from the ethernet driver itself and
second from vlan_input(). If a bpf listener, such as tcpdump or dhcpd is
listening to this trafic, it sees both packets. This has been true in
NetBSD for a very very long time.
In the historically common case where a chip doesn't do hardware vlan
tag extraction, or we don't use it, the packet passed to the bpf engine
from the ethernet driver contains the contents of the packet as it came in
on the wire including the vlan header and vlan type. The packet passed to
the bpf engine from vlan_input() contains the decapsulated packet without
the vlan information.
If hardware vlan extraction is enabled and the ethernet driver passes
the packet to bpf after it performs this extraction, then the packet that
gets passed to the bpf engine by the ethernet driver is a decapsulated
ethernet frame minus any tag information. Then, when vlan_input() passes
its packet to the bpf engine, it ends up sending the same packet again
because the packet has already been decapsulated by the ethernet driver.
So, it's not that dhcpd is seeing more packets under NetBSD-5 with
interfaces that have hardware vlan tagging enabled, it's that it is
recognizing the initial packets that come in from the ethernet driver as
valid ethernet frames. If dhcpd is listening to an interface which doesn't
support hardware extraction, it simply discards the tagged packets as
inappropriate traffic.
If the bpf listener is tcpdump, then if hardware extraction is
enabled, I believe you'll see two copies of tagged packets come in, but you
won't be able to distinguish them from each other because the tag
information wasn't presented to the bpf engine.
Fortunately, I believe there is an easy fix for this problem which
preserves our ability to support the vlan extraction features of modern
ethernet chips while preserving the historical behavior of the NetBSD
stack. If we move the code that sends the packet to the bpf engine to just
above the code that implements the hardware decapsulation function in each
driver, I believe historical functionality will be restored while enabling
support for new capabilities in chips.
Greg, if youre stil reading, I believe you can test much of this
theory by configuring a vlan on your vr(4) ethernet card, which doesn't
have hardware vlan tag extraction, and you'll see tagged packets on the
parent interface and untagged packets on the vlan interface when using bpf.
If you use bpf on a vlan tag capable interface such as wm(4), you'll see
untagged packets on both the parent and vlan interfaces associated with
that card.
If my tests prove this scenario is right and the change I propose
fixes the behavior, is there any reason I shouldn't commit changes to
implement it?
-thanks
-Brian
