A more basic follow on question relating to vlan filtering. As of Jan 2013, vlan filtering under recent linux kernels was completely broken (background: they started striping the vlan tags on inbound packets and moving it into metadata, and the bpf emitted code didn't hand it correctly).
I haven't seen a new release since that time. Has any progress been made? On Sat, Oct 12, 2013 at 7:43 AM, 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
