tcpdump mailing list archives
Re: [libpcap] OR'ing vlans impossible in tcpdump filter (issue #158)
From: Gianluca Varenni <Gianluca.Varenni () riverbed com>
Date: Sun, 27 Oct 2013 22:20:23 +0000
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
Current thread:
- Re: [libpcap] OR'ing vlans impossible in tcpdump filter (issue #158) Shoham Peller (Oct 26)
- Re: [libpcap] OR'ing vlans impossible in tcpdump filter (issue #158) Gianluca Varenni (Oct 27)