On Wed, 20 Sep 2006, David Malone wrote:
With VLAN tagging we can't trust the VLAN tag.
Unlike checksums etc, the kernel must be able to determine the VLAN tag to
be able to process the packet. The problem is that it isn't where bpf
expects.
True, though BPF just expects to find the data where it should be on the
wire. It seems like it should be up to the responsibility of the code
calling bpf_*tap* to make sure it is in that format. Checksums that seem
incorrect to bpf have already caused a non-trivial number questions on the
mailing lists.
We almost need a way to indicate to BPF that there are certain ranges of
bytes that we couldn't see because they are provided by the hardware rather
than us.
As an issue of symmetry, it strikes me that the driver is most aware of what
has been removed from the packet, and so in the best position to provide
substitute data to make up for the removed data. As a matter of abstraction,
it seems likely that the link layer might provide a utility routine to help
mock up the missing data, however. I tend to agree with the observation that
we should not frob the driver level state as a result of BPF listeners -- if
nothing else, this increases the chances of hitting race conditions between
changing of card state and the descriptor rings, in which some packets in the
rings were processed with tag stripping, and some without, but the driver
treats them all as being consistent with its most recent notion of how the
flags were set. Ideally, we should frob the hardware's encapsulation/etc as
little as possible, and probably drain the send and receive descriptor rings
when that happens so there's a clean transition.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
