Re: vlan and bpf

Jason Thorpe <[email protected]> writes:

>> On Dec 15, 2023, at 9:11 AM, Greg Troxel <[email protected]> wrote:
>> 
>> --- if.c.~1.457.2.4.~   2020-09-01 19:56:43.824457852 -0400
>> +++ if.c        2023-12-15 12:10:09.503560965 -0500
>> @@ -818,7 +818,8 @@ if_percpuq_softint(void *arg)
>> 
>>        while ((m = if_percpuq_dequeue(ipq)) != NULL) {
>>                ifp->if_ipackets++;
>> -               bpf_mtap(ifp, m, BPF_D_IN);
>> +               if (!vlan_has_tag(m))
>> +                       bpf_mtap(ifp, m, BPF_D_IN);
>
> Why would not not want to be able to sniff the VLAN-encapsulated packets on their physical interface?  Seems like this change could lose a useful debugging aid...

You do want to see them, but you want to see them with ethertype vlan,
not as if they are present unwrapped.

On the physical interface, the IP packet does not exist, and instead
there is an ethernet frame of type vlan with a tag and a payload.  This
gets messier when the hardware does vlan tagging, in that a packet is
returned as if it were not encapsulated along with vlan metadata.  But
that's logically an encapsulated packet.

This would  be like having a packet of next-proto IP arrive on wm0,
destined for gif0.  What happens is that the outer packet is bpf_tapped,
with the outer IP addrs present and next-proto IP and the payload.  But
it does not extract the packet and then behave as if it arrived
unwrapped.

I agree that seeing vlan packets is useful, but I don't think it is
happening now as it should.  I am definitely not seeing anything like
'vlan 0x3' in front of the packets on wm0 tcpdump output.