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

[shoham_peller () yahoo com]

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.Varenni () 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-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