That does not solve the cases I wrote below. The filters I wrote are also difficult to translate to the syntax you suggested: * (vlan 1 or vlan 2) and ip * (vlan 1 or ether) and ip
I'm hoping to be free to implement the algorithm I suggested in the near future. Once I'll get around to it, you're gonna have a pull request that solves half the problem, as I suggested. On Oct 28, 2013 12:20 AM, Gianluca Varenni <gianluca.vare...@riverbed.com> wrote: > > 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
