The problem with your syntax is that it's not backwards compatible, so such a change can break applications. My syntax should be backwards compatible, as the syntax "vlan <protocol>" is not supported today.
GV -----Original Message----- From: fen...@gmail.com [mailto:fen...@gmail.com] On Behalf Of Bill Fenner Sent: Monday, February 04, 2013 2:40 PM To: Gianluca Varenni Cc: Guy Harris; Michael Richardson; tcpdump-workers@lists.tcpdump.org; Francesco Ruggeri Subject: Re: [tcpdump-workers] "not vlan" filter expression broken catastrophically! On Sat, Feb 2, 2013 at 12:26 AM, Gianluca Varenni <gianluca.vare...@riverbed.com> wrote: > What I'm talking about is not having the vlan keyword that has a global > effect to the whole filters. > At the moment we write something like "vlan and ip" to capture ip packets > within vlan, and a filter like "(vlan and ip) or udp" is actually compiled > with the logic meaning "vlan and (ip or udp)". > One proposal that I have is to support a syntax like the following > > vlan ip > > This is exactly like "vlan ip" but it sticks *only* to the "ip" > keyword. So a filter like "vlan ip or udp" means "accepts ip packets > within a vlan tag, or udp packets without a vlan tag". If you want to > specify the vlan id, you use > > vlan 23 ip > > if you want to "stick" vlan to multiple filters, you use the syntax > > vlan 23 (udp or tcp) > > this is equivalent to > > vlan 23 udp or vlan 23 udp > > Finally, if you want to filter QinQ packets, you use > > vlan vlan ip (ip packets within 2 vlan encapsulations) > > > I know the syntax is not the most elegant (and I don't know how > easy/difficult it would be to parse), but I believe it solves the problem of > having the vlan keyword having a global effect during compilation. > > > What do you guys think? This sounds like my earlier suggestion: to make the vlan keyword associative. My syntax would have a few more "and"s than your examples, such as "vlan 23 and ( udp or tcp )", or "vlan and vlan and ip". Bill > > Have a nice day > GV > > -----Original Message----- > From: Guy Harris [mailto:g...@alum.mit.edu] > Sent: Friday, February 01, 2013 6:19 PM > To: Bill Fenner > Cc: Gianluca Varenni; Michael Richardson; > tcpdump-workers@lists.tcpdump.org; Francesco Ruggeri > Subject: Re: [tcpdump-workers] "not vlan" filter expression broken > catastrophically! > > > On Feb 1, 2013, at 4:49 AM, Bill Fenner <fen...@aristanetworks.com> wrote: > >> We have wanted to fix the vlan support ever since it was added. > > The "vlan" keyword serves two purposes: > > 1) matching VLAN-encapsulated packets or VLAN-encapsulated > packets on a particular VLAN; > > 2) handling the extra MAC-layer header length due to the VLAN header. > > That's also the case for "pppoed" and "mpls". > > 2), in the best of all possible worlds, would be done by having filter > programs that can, without much performance penalty, check for higher-level > protocol types in the presence of > VLAN/MPLS/PPPoE/GTP/fill-in-your-encapsulation-layering headers, so that "tcp > port 80" would find all packets on the network that are going to or from TCP > port 80, regardless of how IP is encapsulated. If you wanted only > VLAN-encapsulated packets going to or from TCP port 80, you'd do "vlan and > tcp port 80"; if you only wanted *non*-VLAN-encapsulated packets going to or > from TCP port 80, you'd do "not vlan and tcp port 80". "vlan" (and "pppoed" > and "mpls") would only handle 1) (and its equivalents). > > Unfortunately, that requires changes to the machine code language for filter > programs, so you'd have to somehow deal with systems where the kernel has a > filtering engine but it doesn't support those changes. > > _______________________________________________ > 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
