Add support for out-of-band VLAN IDs on afpacket sources.

[deadpixi]

The Linux kernel supports VLAN offloading, which will strip off VLAN headers before passing the packet data up to the capture layer. This results in the odd situation where the data presented to the capture layer is not what was actually visible on the wire.

For those who needed visibility into the VLAN layer, the afpacket.OptAddVLANHeader option was provided. When set, a synthetic VLAN header is created and copied over. While this works and provides a more accurate view of the data on the wire, it is slow (as noted in the documentation of the option, sometimes by an order of magnitude).

This commit augments the gopacket.CaptureInfo structure by adding a VLAN field that stores the VID (VLAN ID) of the packet if it was provided out-of-band by the capture mechanism. If it was not provided, this field defaults to -1 (it should not default to zero, as it is possible to have a zero VID, which is used for priority tagging).

This provides a fast mechanism to access VLAN information for those who need it while retaining the afpacket.OptAddVLANHeader mechanism for those who need it.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[deadpixi]

I signed it!

[googlebot]

CLAs look good, thanks!

[gconnell]

I'm a little leary of this, as it puts something (VLAN) that's only needed rarely (AF_PACKET-specific) in a very general (CaptureInfo) location.

Anyone else have any thoughts on this?

PS: I'll be on vacation through 6/18, so probably won't respond again until at least then. Apologies for the delay.

[deadpixi]

Perhaps it would be better to have a slice of interface{}s in the returned CaptureInfo that are "ancillary data" or something? It could be populated with, for example, afpacket.AuxDataVLAN or something that could be discovered at runtime.That would keep it generic but allow extra information should the capture layer be able to provide it.

This would be analogous to the ancillary data on UNIX domain sockets.

[gconnell]

Hey, sorry for the slow response, just coming back from a vacation.

I like the idea of ancillary data. So I'm guessing it would be something like this:

func (c *CaptureInfo) AddAncillary(a interface{}) { ... }
func (c CaptureInfo) Ancillary() []interface{} { ... }

And it would be used like this:

for _, a := range ci.Ancillary() {
  switch v := a.(type) {
    case afpacket.AncillaryVLAN:
      log.Printf("vlan ID %d", int(v))
  }
}

[deadpixi]

@gconnell I've switched to a more generic "ancillary data" mechanism now in my branch. Currently it's simply a slice of interface{} that can be appended to by the packet provider; I can switch to using accessor methods if you think that's better. Please let me know.