On Thu, Jan 31, 2013 at 7:20 PM, Gianluca Varenni
gianluca.vare...@riverbed.com wrote:
To be totally honest, I think the whole way in which vlans are managed in the
filters is quite nonsense. The underlying problem is that normally a BPF
filter is an or or and combination of disjoint filters,
I'd like to point out that vlan filtering in general is completely
broken under Linux 3x (as discussed several times on this list).
In Linux 3x they began stripping the vlan headers off of RX packets
and setting BPF ancillary flags, but not doing the same on TX packets.
Since the vlan tags are
On Fri, Feb 1, 2013 at 3:50 PM, Paul Pearce pea...@cs.berkeley.edu wrote:
I'd like to point out that vlan filtering in general is completely
broken under Linux 3x (as discussed several times on this list).
In Linux 3x they began stripping the vlan headers off of RX packets
and setting BPF
I followed the whole discussion about vlan filtering broken in the 3.x kernel
as on observer (I never had time to fully read all the emails and understand
all the details).
In general my gut feeling (and I might be totally wrong) is that packet capture
in the linux kernel is becoming more and
In this case, I have used a tool written by Bill Fenner called
BpfExpression for Arista. Not sure if the code is GNU licensed. He's
in the mailing list and I will let him comment.
ani
On Fri, Feb 1, 2013 at 5:07 PM, Michael Richardson m...@sandelman.ca wrote:
Ani == Ani Sinha
vlan X or vlan Y
would have different behavior on RX vs TX packets because of the
pointer into the header advancing when it encounters a vlan tag
on TX, but not RX.
Well, that filter is broken anyway in the current world, since it
matches 'a packet on vlan X' or 'a double-tagged packet
On Fri, Feb 1, 2013 at 1:13 PM, Bill Fenner fen...@aristanetworks.com wrote:
On Fri, Feb 1, 2013 at 3:50 PM, Paul Pearce pea...@cs.berkeley.edu wrote:
That was my proposal to Ani, since the kernel guys seemed to insist
that asymmetry was a virtue.
yes, I think ultimately we will have to do
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
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
