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

[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:       Gianluca Varenni <Gianluca.Varenni () riverbed ! com>
Date:       2013-10-27 22:20:23
Message-ID: 8A9226C4990BF648BD21174A6F44BDFD9A7C65FD () sfo1exc-mbxp12 ! nbttech ! com
[Download RAW message or body]

One consideration here: the behavior or the "vlan" keyword, although extremely \
confusing and honestly brain damaged, has been there for multiple years, and there \
are probably a number of tools relying on this confusing behavior. Changing it might \
mean breaking some existing applications.

Earlier this year, I proposed a different syntax for the vlan keyword that should be \
backwards compatible. You can find the conversation here:

http://article.gmane.org/gmane.network.tcpdump.devel/6177/match=varenni

What do you think?

Have a nice day
GV

-----Original Message-----
From: tcpdump-workers-bounces@lists.tcpdump.org \
                [mailto:tcpdump-workers-bounces@lists.tcpdump.org] On Behalf Of \
                Shoham Peller
Sent: Saturday, October 26, 2013 2:40 PM
To: tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] [libpcap] OR'ing vlans impossible in tcpdump filter \
(issue #158)

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
_______________________________________________
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] 