Brian Buhrow <buhrow%nfbcal.org@localhost> writes: > [lots of details] Everything you said sounds ok to me. > 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. I don't follow this. But if you have a patch, please post it. What I don't follow is that hardware vlan tagging support I think is about returning the packet as it would appear on the vlan and having the vlan tag in a control structure. So a packet which has been handled that way can't be sent to bpf_tap without reconstructing the on-the-wire representation. > 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. Yes, I did that. > 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. On netbsd-5/wm, I saw the packets on the parent, but not on the vlan. So I think there is more to it. > 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? I think you should post it for review once you think it's ok. This is pretty tricky stuff and more eyes will perhaps avoid unintended consequences.
Attachment:
pgpVwDoYBu25u.pgp
Description: PGP signature