[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] [libpcap] OR'ing vlans impossible in tcpdump	filter (issue #158)
From:       Shoham Peller <shoham_peller () yahoo ! com>
Date:       2013-10-26 21:39:46
Message-ID: ws9kqt9m5kasr187ffwaq4wl.1382823162231 () email ! android ! com
[Download RAW message or body]

Thought about it, and this is not a complete solution.
It doesn't solve things like:
* (vlan 1 or vlan 2) and ip
* (vlan 1 or ether) and ip

So the solution isn't complete, but it sure does improve the current situation.
So what do you say? Should we proceed to develop this logic?

Shoham Peller <shoham_peller@yahoo.com> wrote:

>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
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[prev in list] [next in list] [prev in thread] [next in thread]