Brian Buhrow <buhrow%nfbcal.org@localhost> writes: > However, some drivers, i.e. stge(4), send the packet to the bpf engine after > step 2, above, before performing steps 3, 4 and 6. Without having tested > anything yet, this seems more correct to me. > I will try to get a test environment together with some chips capable > of doing hardware vlan tagging extraction (with this code enabled), other > chips not capable of hardware vlan tag extraction and a test with the bpf > call moved up the list of items to be completed on the receipt of a packet. > If anyone has any thoughts they'd like to share that might save me > some time in this endeavor, I'm all for hearing them. 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.
Attachment:
pgpOeT14_paTj.pgp
Description: PGP signature