hello folks :
Before I go into describing the real problem, I'd like to give some
background information for the context. Please bear with me.
As you guys might be aware, the way the Linux kernel handles vlan
tagged packets have changed. Please see the following commit in
mainline Torvalds' tree
cc'ing netdev.
On Wed, Oct 31, 2012 at 2:01 PM, Michael Richardson wrote:
>
> Thanks for this email.
>
>>>>>> "Ani" == Ani Sinha writes:
> Ani> remove "inline" from vlan_core.c functions
> Ani> Signed-off-by: David S. Mi
On Wed, Oct 31, 2012 at 3:20 PM, Guy Harris wrote:
>
> On Oct 31, 2012, at 2:50 PM, Ani Sinha wrote:
>
>> pcap files that already have the tags reinsrted should work with
>> current filter code. However for live traffic, one has to get the tags
>> from CMSG() and t
On Wed, Oct 31, 2012 at 5:50 PM, Guy Harris wrote:
>
> On Oct 31, 2012, at 3:35 PM, Ani Sinha wrote:
>
>> yes but if the packet is passed to the filter within libpcap (when we
>> are not using the kernel filter) before the reinsertion,
>
> ...that would be a bug.
>
Folks,
I'm wondering if there has been any progress on this. Are there any
thoughts on what Bill wrote in his email?
Thanks
ani
On Fri, Nov 2, 2012 at 9:13 AM, Bill Fenner wrote:
> On Wed, Oct 31, 2012 at 6:20 PM, Guy Harris wrote:
> >
> > On Oct 31, 2012, at 2:50
Folks,
I'm wondering if there has been any progress on this. Are there any
thoughts on what Bill wrote in his email?
Thanks
On Tue, Nov 13, 2012 at 2:41 PM, Ani Sinha wrote:
> Folks,
>
> I'm wondering if there has been any progress on this. Are there any thoughts
> on
On Wed, Oct 31, 2012 at 5:50 PM, Guy Harris wrote:
>
> On Oct 31, 2012, at 3:35 PM, Ani Sinha wrote:
>
>> yes but if the packet is passed to the filter within libpcap (when we
>> are not using the kernel filter) before the reinsertion,
>
> ...that would be a bug.
>
On Sat, Nov 17, 2012 at 3:33 PM, Eric W. Biederman
wrote:
> the vlan header in packets as we receive them.
>
> The code is correct except for the case of packets in vlan 0. Currently
> the packet reconstruction is ambiguous. The most recent kernels have
> a TP_STATUS_VLAN_VALID flag that can be
On Thu, Dec 6, 2012 at 2:19 PM, Eric W. Biederman wrote:
> Ani Sinha writes:
>
>> On Sat, Nov 17, 2012 at 3:33 PM, Eric W. Biederman
>> wrote:
>>> the vlan header in packets as we receive them.
>>>
>>> The code is correct except for the case of
On Thu, Dec 6, 2012 at 2:19 PM, Eric W. Biederman wrote:
> Ani Sinha writes:
>>>
>>
>> May be this?
>
> Two things.
>
> - TP_STATUS_VLAN_VALID lives in the tp_status field not the tp_vlan_tci field.
> - To work on older kernels with binaries compiled with n
>
> The patch is whitespace damaged. And one of your test is using ||
> instead of &&
>
OK, using alpine now :-)
>
> The test should be && not ||.
>
aargh! I am retarded! Fixed. Hopefully 3rd time is a charm :-)
ani
pcap-linux.c | 50 +++---
1 fil
>
> The patch is whitespace damaged. And one of your test is using ||
> instead of &&
OK, using alpine now :-)
>
> The test should be && not ||.
aargh! I am retarded! Fixed. Hopefully 3rd time is a charm :-)
ani
pcap-linux.c | 50 +++---
1 files
ode
> so I
> Eric> don't care but someone else might.
Here's an updated patch. I have converted spaces to tabs consistent with
rest of the file. I have also set up github and sent a pull request
:
commit b977ebd9d9608bb8a8e4927e7a6286bdfd6b94a8
Author: Ani Sinha
Date:
>
> It is possible to test for the presence of support of the new vlan bpf
> extensions by attempting to load a filter that uses them. As only valid
> filters can be loaded, old kernels that do not support filtering of vlan
> tags will fail to load the a test filter with uses them.
Unfortunately
On Tue, Dec 11, 2012 at 3:04 PM, Eric Dumazet wrote:
> On Tue, 2012-12-11 at 14:36 -0800, Ani Sinha wrote:
>> >
>> > It is possible to test for the presence of support of the new vlan bpf
>> > extensions by attempting to load a filter that uses them. As only valid
&
On Tue, Dec 11, 2012 at 3:04 PM, Eric Dumazet wrote:
> On Tue, 2012-12-11 at 14:36 -0800, Ani Sinha wrote:
>> >
>> > It is possible to test for the presence of support of the new vlan bpf
> If you want to test ANCILLARY possible values, its already too late, as
> old
>
> unsigned int netdev_8021q_inskb = 1;
>
> ...
> {
> .ctl_name = NET_CORE_8021q_INSKB,
> .procname = "netdev_8021q_inskb",
> .data = &netdev_8021q_inskb,
> .maxlen = sizeof(int),
> .mode
+ Eric B.
On Wed, Dec 12, 2012 at 1:53 PM, Ani Sinha wrote:
>
>>
>> unsigned int netdev_8021q_inskb = 1;
>>
>> ...
>> {
>> .ctl_name = NET_CORE_8021q_INSKB,
>> .procname = "netdev_8021q_inskb",
On Thu, Dec 13, 2012 at 12:35 AM, Daniel Borkmann wrote:
> On 12/12/2012 10:53 PM, Ani Sinha wrote:
>>>
>>> unsigned int netdev_8021q_inskb = 1;
>>>
>>> ...
>>> {
>>> .ctl_name = NET_CORE_8021q_INSKB,
On Thu, Dec 13, 2012 at 1:49 PM, Daniel Borkmann
wrote:
> Well, not everyone on netdev might be following this thread (resp.
> following fully). The best way to get responses for a patch is to go
> through the normal patch submission process on netdev, and if you like
> to request for comments, t
On Mon, Dec 17, 2012 at 2:35 AM, Guy Harris wrote:
>
> On Dec 17, 2012, at 1:50 AM, "David Laight" wrote:
>
>> How are you going to tell whether a feature is present in a non-Linux
>> kernel ?
>
> The Linux memory-mapped capture mechanism is not present in a non-Linux
> kernel, so all the libpca
e
vlan tagged packets. We need to handle this in a future patch.
Signed-off-by: Ani Sinha
diff --git a/Makefile.in b/Makefile.in
index 772cc7d..c030a7e 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -82,7 +82,7 @@ YACC = @V_YACC@
@rm -f $@
$(CC) $(FULL_CFLAGS) -c $(srcdir)/$*
On Mon, Jan 7, 2013 at 4:05 PM, Paul Pearce wrote:
> Hello folks,
>
> PROBLEM:
>
> vlan tagged packets that are injected via software are not picked up
> by filters using recent (kernel commit
> f3335031b9452baebfe49b8b5e55d3fe0c4677d1)
> BPF vlan modifications. I suspect this is a problem with th
+tcpdump-workers
On Tue, Jan 8, 2013 at 10:27 PM, Eric Dumazet wrote:
> On Tue, 2013-01-08 at 22:06 -0800, Ani Sinha wrote:
>
>> The proposed patch tries to fix the issue that arose after the
>> following commit :
>>
>> commit b40863c667c16b7a73d4f034a8eab67029
>> Thats irrelevant. This only shows that user land was depending on a
>> prior undocumented behavior.
Why do you say that? The following patch from Pirko ensured that on
both RX and TX regardless whether the driver/hw supported vlan
acceleration, the outermost vlan tags will always be extracted o
On Wed, Jan 9, 2013 at 11:51 AM, Eric Dumazet wrote:
> On Wed, 2013-01-09 at 11:27 -0800, Ani Sinha wrote:
>
>> This is wrong. Accelerated or not, the kernel code was organized to
>> have the tags in the packet aux data. So I think this is how user land
>> should be cod
On Wed, Jan 9, 2013 at 12:01 PM, Ani Sinha wrote:
> On Wed, Jan 9, 2013 at 11:51 AM, Eric Dumazet wrote:
>> On Wed, 2013-01-09 at 11:27 -0800, Ani Sinha wrote:
>>
>>> This is wrong. Accelerated or not, the kernel code was organized to
>>> have the tags in the pa
hello folks :
As you guys have been aware, I am hacking libpcap for a while. Me and
Bill noticed something seriously broken for any filter expression that
has a "not vlan" in it. For example, take a look at the filter code
generated by libpcap with an expression like "not vlan and tcp port
80" :
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&q
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
On Mon, Feb 4, 2013 at 1:29 AM, David Laight wrote:
>> I agree. Honestly I think a perfectly reasonable stance to take is
>> requesting that the filters get packets *as seen on the wire/nic*. I
>> think that's the mental model everyone uses, and any deviation from
>> that model is prone to bugs in
31 matches
Mail list logo
