On 29 Nov, 2012, at 08:23 , Greg Troxel <g...@ir.bbn.com> 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
