Re: Broadcast traffic on vlans leaks into the parent interface on NetBSD-5.1

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 29 Nov, 2012, at 08:23 , Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
> bpf is supposed to present the packet as it should have been received on
> the interface.  In the presence of hardware acceleration, that's a
> tricky concept.
> 
> When a packet arrives that has vlan tag, it makes sense to have it
> bpf_tap'd on the parent interface, but with the vlan tag in the buffer,
> so that tcpdump will see the tag.  This is explained in tcpdump(1), but
> I am not seeing it work on wm(4) on NetBSD-5.  I do see this on vr(4) on
> NetBSD-6 (didn't check 5; that's what I had handy).
> 
> To do bpf properly with hw tagging, one would have to make an mbuf that
> has the way the packet would be on the wire and call tap.  An
> alternative is to skip bpf for packets where the hw has done the tag
> processing.  Probably this should be documented in wm(4).
> 
> I just configured a vlan (usually I don't).  I also see NetBSD-5/wm fail
> to put the packet on the proper vlanif for bpf, or to respond to it.
> 
> I dimly remember an issue with hw vlan tagging being broken.   So if you
> can find that in the driver, disable it, and rebuild, that would be
> interesting.

To comment on the broader "How it should work" issue, it seems to me
that this form of hardware tag manipulation would be better compiled out
of every driver.

If you are bridging traffic from the interface it is most certainly
the case that you want to leave the VLAN tag right where it is.  Generally
you'll be sending the packet out with the same tag it came in with and
the bridge routing decision is (or can be) sensitive to the tag, which
makes it maximally convenient to leave the tag in the packet adjacent to
the other fields the route lookup is going to be examining (i.e. the MAC
addresses).  The tagged packet format is perfect for bridges the way it
is.  It would be useful for bridging to be able to tell the hardware to
add a tag to incoming untagged frames and delete it from outgoing frames,
the way switches do, but that is the opposite of the "acceleration" we're
talking about here.

That leaves the case when the hardware interface is being used
(de)multiplex L3 protocol traffic.  In this case if the VLAN tag is
in the packet it is in the middle of an L2 header which is very
likely going to be stripped from the packet in short order in any
case, so what is saved by having the hardware take the tag out is
that we only have to strip 14 bytes instead of 18, and we only have
to add 14 bytes to outgoing packets instead of 18. The former is
no saving at all, while the latter saving is very close to none,
yet this comes at the cost of having to carry around packet metadata
recalling what the tag was.  And the actual function of the VLAN
tag with respect to an L3 stack, which is to identify the logical
incoming interface, is quite conveniently done with the identifier
in the packet, just like PPPoE or Frame Relay or ATM (for the
latter the interface identification wasn't in the actual packet but
the easiest ATM chipsets to work with prepended the VPI/VCI as a
packet pseudo-header before giving it to you, analogous to Frame
Relay), or even an MPLS host implementation.  The L2-identifier-to-
logical-interface determination must be done before the packet is
given to an L3 protocol (i.e. when the L2 header needs to be
stripped) so the tag is there when you need it but goes away with
the rest of the L2 header by the time you are done with it.  There's
no apparent downside at all to having the VLAN tag in the packet,
it is in the right spot for its function.

I believe the type of hardware assist that is the topic here (remove
the tag on the way in, add it on the way out) in fact came to exist
not as a "performance" enhancement but rather as a work around for
network software implementations which didn't support VLANs, and
which hence couldn't handle reception of the slightly-too-large
Ethernet frames or deal with an Ethernet header with more than 14
bytes.  I don't think adding VLAN support to the software in a way
which explicit maintains the use of this hack (let alone penalizing
interfaces which don't do it) is useful, in fact I think the whole
point of adding VLAN tag support to the software should have been
to eliminate the need to use this hardware feature at all.  Receiving
the full frame, including the tag, is optimal.  BPF is right to want
it there, too.

I'm also trying hard, but failing, to ignore the issue which revealed
the current problem, that being having an application as important
as a DHCP client needing to use BPF to send and receive UDP packets
rather than using the host's own UDP/IP code for that.  I believe
every use of BPF by an application to send and receive protocol
traffic is a signal that something is missing in the host's network
implementation, so its use by as important an application as a DHCP
client seems like a sign that what is missing in this case is
quite important.

Dennis Ferguson