Ani Sinha writes:
> 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. Miller
>>
>> Ani> As a result of
Michael Richardson writes:
> Thank you for this reply.
>
>>>>>> "Eric" == Eric W Biederman writes:
> Eric> I don't see any need to add any kernel code to allow checking
> Eric> if vlan tags are stripped. Vlan headers are strippe
Daniel Borkmann writes:
> Speaking of netsniff-ng where we don't reconstruct VLAN headers, users
> have reported that depending on the NIC/driver resp. ethtool setting,
> they can come in stripped or not (in the pf_packet's rx_ring buffer).
> However, I assume VLAN AUXDATA is always consistent (a
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 packets in vlan 0. Currently
>> the packet reconstruction is ambiguous. The
Ani Sinha writes:
> 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
&
Ani Sinha writes:
>>
>> 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 :
Jiri Pirko writes:
> Tue, Jan 08, 2013 at 01:05:39AM CET, pea...@cs.berkeley.edu 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 modificati
Paul Pearce writes:
>>> My opinion as a kernel developer is that the network tap is here to have
>>> a copy of the exact frame given to the _device_.
>
>> Good: as someone who spends lots of time with tcpdump doing both network
>> and protocol diagnostics, it's really important to see exactly the
