Quantcast
Channel: Active questions tagged linux-kernel - Stack Overflow
Viewing all articles
Browse latest Browse all 12332

libpcap not filtering VLAN packets correctly, ignoring VLAN (0x8100) or 802.1ad (0x88a8) headers

$
0
0

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.


Viewing all articles
Browse latest Browse all 12332

Latest Images

Trending Articles



Latest Images

<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>