> There was a release in the spring, but I don't think it solved the problem.
> I have made a note to look at this before the release next week.
Awesome. Keep me posted if you need people to test the vlan changes.
___
tcpdump-workers mailing list
tcpdump
A more basic follow on question relating to vlan filtering.
As of Jan 2013, vlan filtering under recent linux kernels was
completely broken (background: they started striping the vlan tags on
inbound packets and moving it into metadata, and the bpf emitted code
didn't hand it correctly).
I haven'
>> 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
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
>> 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 there.
> If that means turning
The original message didn't make it to the tcpdump-workers list. It follows.
-- Forwarded message --
From: Paul Pearce
Date: Mon, Jan 7, 2013 at 4:05 PM
Subject: PROBLEM: Software injected vlan tagged packets are unable to
be identified using recent BPF modifications
To
