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)"
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 he
On Fri, Feb 1, 2013 at 1:13 PM, Bill Fenner wrote:
> On Fri, Feb 1, 2013 at 3:50 PM, Paul Pearce 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 something like what Bill
suggested to me. I
>> 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-tagge
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 wrote:
>
>> "Ani" == Ani Sinha writes:
> Ani> hello
> "Ani" == Ani Sinha writes:
Ani> hello folks :
Ani> As you guys have been aware, I am hacking libpcap for a
Ani> while. Me and Bill noticed something seriously broken for any
Ani> filter expression that has a "not vlan" in it. For example,
Ani> take a look at the filter
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
On Fri, Feb 1, 2013 at 3:50 PM, Paul Pearce 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 ancillary flags, but
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 mis
The problem is that if you change the behavior of the vlan keyword, you
potentially break a lot of applications that are based on the old buggy
behavior :-(
-Original Message-
From: fen...@gmail.com [mailto:fen...@gmail.com] On Behalf Of Bill Fenner
Sent: Friday, February 01, 2013 4:49 A
On Thu, Jan 31, 2013 at 7:20 PM, Gianluca Varenni
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, so if I write
> "filt
11 matches
Mail list logo
