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-boun...@lists.tcpdump.org [mailto:tcpdump-workers-boun...@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_pel...@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