I am using libpcap 1.9.1 to capture packets in combination with custom kernel (4.9.0).While googling and analyzing the strange behavior, I came to the conclusion that kernel removes (why?) 0x8100 or 0x88a8 header and than filters packets like that header never existed. When 0x9100 header is used instead of 0x88a8 - kernel recasts it to 0x8100 but filters the packets correctly.
When I try to capture UDP packets with VLAN header (EtherType 0x8100):
- PCAP filter "VLAN": nothing gets captured. (As if PCAP does not seethe header)
- PCAP filter "UDP": packets captured with all headers visible.
When I try to capture UDP packets with 802.1ad header (EtherType 0x88a8 followed by EtherType 0x8100):
- PCAP filter "VLAN && VLAN": nothing captured. (As if PCAP does not seethe 0x88a8 header)
- PCAP filter "VLAN": packets captured. (BUT - 0x9100 is now recast to 0x8100 - packets captured have EtherType 0x8100 followed by EtherType 0x8100)
- PCAP filter "UDP": nothing captured. (As if PCAP does not seethe 0x88a8 header, only 0x8100 header)
When I try to capture UDP packets with QinQ header (EtherType 0x9100 followed by EtherType 0x8100):
- PCAP filter "VLAN && VLAN": packets captured with all headers visible.
- PCAP filter "UDP": nothing captured. (As if kernel does not recognize and ignores 0x9100 EtherType and therefore not removing it - so everything appears to work correctly)
Since I am not using 0x88a8 EtherType - don't really care about that behaviour. However, I would like to be able to capture QinQ packets using filter "vlan && vlan && UDP" and VLAN packets using filters "vlan" and "vlan && UDP". I'd also like for all these packets to be filtered by using "UDP" filter only.
When I open up QinQ .pcap in wireshark and use "UDP" filter only - packets get filtered as UDP.
Reading this question: Linux: When sending Ethernet frames the ethertype is being re-written I can see that kernel indeed consumes 8100 or 88a8 tag. But I don't get when exactly. If Kernel modifies the frames (removes VLAN header) and libpcap applies filter on modified packets, how come final .pcap captured file has headers again?
E: using the code from previous question, I modified sender app a little to test Ethertype 0x9100 as well as regular 0x8100 frame and this is the output:
Received 64 bytes: Protocol: ETH_P_ALL Interface: 1 Header type: ARPHRD_LOOP: Loopback Packet type: PACKET_OUTGOING Address: 00 00 00 00 00 00 Data: ff ff ff ff ff ff 00 00 00 00 00 00 81 00 e0 02 08 00 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 38 31 20 30 30 20 65 30 20 30Received 60 bytes: Protocol: ETH_P_IP Interface: 1 Header type: ARPHRD_LOOP: Loopback Packet type: PACKET_MULTICAST Address: 00 00 00 00 00 00 Data: ff ff ff ff ff ff 00 00 00 00 00 00 08 00 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 38 31 20 30 30 20 65 30 20 30Received 64 bytes: Protocol: ETH_P_ALL Interface: 1 Header type: ARPHRD_LOOP: Loopback Packet type: PACKET_OUTGOING Address: 00 00 00 00 00 00 Data: ff ff ff ff ff ff 00 00 00 00 00 00 91 00 e0 01 81 00 e0 02 08 00 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 38 31 20 30 30 20Received 64 bytes: Protocol: 0x9100 Interface: 1 Header type: ARPHRD_LOOP: Loopback Packet type: PACKET_MULTICAST Address: 00 00 00 00 00 00 Data: ff ff ff ff ff ff 00 00 00 00 00 00 91 00 e0 01 81 00 e0 02 08 00 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 38 31 20 30 30 20Received 64 bytes: Protocol: ETH_P_ALL Interface: 1 Header type: ARPHRD_LOOP: Loopback Packet type: PACKET_OUTGOING Address: 00 00 00 00 00 00 Data: ff ff ff ff ff ff 00 00 00 00 00 00 88 a8 e0 01 81 00 e0 02 08 00 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 38 31 20 30 30 20Received 60 bytes: Protocol: ETH_P_8021Q (802.1Q VLAN) Interface: 1 Header type: ARPHRD_LOOP: Loopback Packet type: PACKET_MULTICAST Address: 00 00 00 00 00 00 Data: ff ff ff ff ff ff 00 00 00 00 00 00 81 00 e0 02 08 00 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 66 66 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 38 31 20 30 30 20
It confirms that kernel is indeed consuming 0x88a8 and 0x8100 headers while ignoring 0x9100.