>> 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
