WIP/RFC: add support for manual link layer offset changes

[stefan-baranoff]

This is mostly a check to see if there's interest in this kind of feature, if the approach is sane, and what all might need added if this is a feature with interest. If there's a better process for this, please let me know! The contribution guidelines are a little sparse in this area.

---

A few pcap-filter expressions implicitly change the link layer offset. There are other less common headers without their own keywords that might require skipping over some bytes in a link layer adjacent header to get to higher layer network headers. This commit adds an "offset" term that takes a + or - value to adjust the link layer offets in the same way VLAN does. This allows for something like ethertype 0x8926 and offset +6 and vlan 14 and ip host 192.0.2.14 to skip over a vntag header, process a VLAN header, and look for an IPv4 host.

[stefan-baranoff]

I couldn't think of a better way of generating a "noop" block. I tried BPF_ALU|BPF_ADD|BPF_K with a value of 0, but the optimizer turned it into an unimplemented operator with an operand of 0xffff.

This is an odd ball in pcap-filter syntax, since it doesn't "check" for anything; it's an "always true" term that controls parsing rather than checking anything. But without returning a block something like offset+6 and host 192.0.2.68 would never work, since and assumes a block on both sides (as best I can tell). Returning NULL or nothing doesn't really work.

[infrastation]

From the implementation perspective, it seems a better fit to use a C function that modifies the offsets and returns gen_true(cstate). From the syntax perspective, OFFSET et al. are unnecessary because the argument of the new keyword could be what is known as narth in the existing grammar terms, then the following would be valid syntax:

offset 4
offset +4
offset -4
offset 2 + 2
offset (len - 4)
offset link[4 * 5]

...and so on.

[stefan-baranoff]

From the implementation perspective, it seems a better fit to use a C function that modifies the offsets and returns gen_true(cstate). From the syntax perspective, OFFSET et al. are unnecessary because the argument of the new keyword could be what is known as narth in the existing grammar terms, then the following would be valid syntax:

offset 4
offset +4
offset -4
offset 2 + 2
offset (len - 4)
offset link[4 * 5]

...and so on.

For some reason I cannot reply directly to your previous comment, so adding this here:

I think I mostly follow what you're suggesting here, although offset +4 and offset 4 at the moment in my latest attempt do the same thing, which is probably okay. My original intent with +X and -X was to make it clear these were relative adjustments. I believe what I've pushed most recently works conceptually. Per the commit comments, I would be interested in feedback on:

1. Is this even worth continuing to pursue? Is there general support for it?
2. Is this the right process for pursuing this, or is there a better venue for having these discussions and getting advice on code approach/design?
3. Am I on track with what you were thinking around narth? It took a bit to figure out how that all worked, but I think I'm starting to understand it better.
4. How do you think would be best to handle allowing adjustments of multiple offsets? E.g. VLAN adjusts off_linkhdr and off_linkpl but MPLS adjusts off_nl and off_nl_nosnap. Then there are other offsets that may or may not make sense to adjust, but I'm not familiar with their purposes or the protocols they support. Is something like I proposed in the commit comment of the off-linkhdr/off-linkpl style keywords for at least those 4 fields?
5. As I'm working through this, I'm realizing pcap-filter hasn't really had "behavior control" included before. While I started this project to see if I could help a team with VNTag without hard coding it to just VNTag (who knows what they'll need next) I realized it could make the vlan X or vlan Y case behave more as expected, ish. That would be ugly and fragile as vlan X and offset -4 or vlan Y and .... The issue is, reading the code now, VLAN isn't always a jump by 4 due to all of the places it can be stashed. So, that got me wondering about that use case and if it's worth looking at a "control" word concept to do something like vlan-jump-off and vlan X or VLAN y or VLAN z) vlan-jump-on and VLAN and .... Obviously a different PR entirely if that's worth doing, but it sure doesn't look like it would be too hard and might solve that long-standing VLAN jumping issue in a backwards compatible way!

[infrastation]

It is difficult to provide a more specific answer at this time, but it certainly looks like a worthwhile direction to research, at least to be able to state exactly how far the solution space would extend. This will likely take some time, so if you have a use case and a good solution for VN tag (see also #770), it may be better to consider that first.