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 " 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
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 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
