[libpcap] OR'ing vlans impossible in tcpdump filter (issue #158)

["Shoham Peller" <shoham_peller () yahoo com>]

Hi Everyone,

 

I'm happy to join the mailing list.

 

There is a prolonged issue with libpcap and vlan filtering, explained in
this ticket:

https://github.com/the-tcpdump-group/libpcap/issues/158

 

In short, filters containing ORs and one or more "VLAN" keywords, behave
unexpectedly.

 

This is explained very well in the comment in gencode.c:7857:

/*

* Check for a VLAN packet, and then change the offsets to point

* to the type and data fields within the VLAN packet.  Just

* increment the offsets, so that we can support a hierarchy, e.g.

* "vlan 300 && vlan 200" to capture VLAN 200 encapsulated within

* VLAN 100.

*

* XXX - this is a bit of a kludge.  If we were to split the

* compiler into a parser that parses an expression and

* generates an expression tree, and a code generator that

* takes an expression tree (which could come from our

* parser or from some other parser) and generates BPF code,

* we could perhaps make the offsets parameters of routines

* and, in the handler for an "AND" node, pass to subnodes

* other than the VLAN node the adjusted offsets.

*

* This would mean that "vlan" would, instead of changing the

* behavior of *all* tests after it, change only the behavior

* of tests ANDed with it.  That would change the documented

* semantics of "vlan", which might break some expressions.

* However, it would mean that "(vlan and ip) or ip" would check

* both for VLAN-encapsulated IP and IP-over-Ethernet, rather than

* checking only for VLAN-encapsulated IP, so that could still

* be considered worth doing; it wouldn't break expressions

* that are of the form "vlan and ..." or "vlan N and ...",

* which I suspect are the most common expressions involving

* "vlan".  "vlan or ..." doesn't necessarily do what the user

* would really want, now, as all the "or ..." tests would

* be done assuming a VLAN, even though the "or" could be viewed

* as meaning "or, if this isn't a VLAN packet...".

*/

 

This comment, commited by  <https://github.com/yuguy> @yuguy in 2005
explains this issue very well. yacc parsers the bpf from left to right
without saving the state, and doesn't provide a tree of some kind, which
would allow an easy solution. <https://github.com/yuguy> @yuguy says that
OR'ing vlans in the current parsing methodology is impossible.

But there might be a solution, if GCC used yacc in previous version to parse
C code, a state *can* be saved. We simply want yacc to parse parenthesis,
and using them to increment the offset, and with each 'OR' it encounters,
resetting the offset to its last state. Let me explain:

tcpdump -d 'vlan and (vlan or arp) or ip'
would mean:

1. filter vlan with the current offset (0) and increment offset ( = 4)
2. open parenthesis. push the offset in a stack
3. filter vlan with the current offset (0) and increment offset ( = 8)
4. or. reset the offset to it's state in the last parenthesis from the
offset stack ( = 4)
5. filter arp with the current offset (4)
6. close parenthesis. pop the offset's state
7. or. reset the offset to it's state in the last parenthesis from the
offset stack ( = 0)
8. filter ip with the current offset (0)

As it seems to me, this will solve the issue, and would allow OR'ing vlans.

What do you say?

Thanks in advance,

Shoham Peller

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers