Re: "not vlan" filter expression broken catastrophically!

[Paul Pearce <pearce () cs berkeley edu>]

> > 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 with inner
> vlan Y' (or, a packet that happens to have the same bit pattern as a
> double-tagged packet with inner vlan Y).

True. But in my mind it's worse kind of broken. Presently no packets
are caught by the filter in that case. In the proposed fix, some
packets would get caught, some wouldn't. That's much harder to debug
for an end user, since they have no knowledge of this kernel asymmetry.
But regardless, you are correct, broken is broken. I like your associative
suggestion.

> In general my gut feeling (and I might be totally wrong) is that packet capture in the linux kernel is becoming more 
> and more broken or at least difficult to support. The whole idea is being able to capture the packets as they are 
> seen or transmitted by the NIC card. Vlan tag is stripped, so the capture piece in the kernel receives the vlan tag 
> as oob information. How does it work for Q-in-Q? And as you said, how does it work with the (already broken) vlan 
> support in BPF compiler. This seems like the perfect recipe for more issues in the future.

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 the kernel, libpcap, and for the enduser.

I believe the on the wire model was used by the netdev folks used up
until they removed the vlan tags on the RX path. It's not clear to me
if they made the conscious decision to change that model, or if it was
accidental. Either way more discussion is necessary. I've not
spearheaded that discussion because I have no idea what I'm doing. =)
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers