Re: "not vlan" filter expression broken catastrophically!

[Gianluca Varenni <Gianluca.Varenni () riverbed com>]

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: fenner () gmail com [mailto:fenner () 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.Varenni () 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:guy () 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 <fenner () 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