search

ntop / PF_RING

High-speed packet processing framework
http://www.ntop.org
GNU Lesser General Public License v2.1
2.71k stars 349 forks source link

QinQ VLAN missing in live ftflow example #476

Closed charlesboyo closed 5 years ago

charlesboyo commented 5 years ago

Hello.

I have installed PF_RING (using apt, version 7.4.0-stable:86e5e6bd3195cc2540618bea511ed4976762e9da) and am using an Intel NIC (igb driver version 5.4.0-k).

When I start ftflow (or ftflow_pcap) on the NIC (eth1), it detects double tagged (QinQ) frames but reports only the inner tag: [Packet] [00:16:3E:3F:18:9E -> FF:FF:FF:FF:FF:FF] [vlan 345] [ARP][Sender=00:16:3E:3F:18:9E/192.168.1.1][Target=00:00:00:00:00:00/192.168.1.109] [caplen=60][len=60][eth_offset=0][l3_offset=18][l4_offset=0][payload_offset=0]

However, if I capture using tcpdump to a pcap file and read that file with ftflow_pcap, both tags are reported: [Packet] [00:16:3E:3F:18:9E -> FF:FF:FF:FF:FF:FF] [vlan 301] [QinQ-vlan 345] [ARP][Sender=00:16:3E:3F:18:9E/192.168.1.1][Target=00:00:00:00:00:00/192.168.1.109] [caplen=64][len=64][eth_offset=0][l3_offset=22][l4_offset=0][payload_offset=0]

I know that the Linux networking core does VLAN untagging (that is if not already done by the NIC in HW) and that outer tag is put in skb->vlan_tci. Does that affect PF_RING and the ftflow's ability to see it in live traffic? Happening in the NIC in this case, rx-vlan-filter is "on [fixed]".

Note that with singly tagged frames, ftflow correctly reports the VLAN tag whether live or in a pcap file. So this issue is only on double tagged frames in live mode.

Charles

cardigliano commented 5 years ago

@charlesboyo I pushed a patch that should fix this, it was due to vlan untagging in case of QinQ as you guessed.. please update and let me know. Thank you.

charlesboyo commented 5 years ago

Thanks, this issue has been resolved with the patch.

charlesboyo commented 5 years ago

@cardigliano A related issue just popped up. When the inner VLAN ID is the same as the outer tag, the QinQ-vlan record is suppressed.

Both of the following are double tagged, the outer VLAN ID is 301 in both cases. The first has an inner tag of 301 while the 2nd's inner tag is 377.

[Packet] [00:16:3E:9E:13:FA -> FF:FF:FF:FF:FF:FF] [vlan 301] [IPv4][192.168.1.83:38566 -> 192.168.1.255:15600] [l3_proto=UDP][hash=2169559078] [caplen=81][len=81][eth_offset=0][l3_offset=18][l4_offset=38][payload_offset=46] [Packet] [00:16:3E:4E:32:2E -> FF:FF:FF:FF:FF:FF] [vlan 301] [QinQ-vlan 377] [IPv4][192.168.1.239:54915 -> 192.168.1.255:54915] [l3_proto=UDP][hash=2169614898] [caplen=313][len=313][eth_offset=0][l3_offset=22][l4_offset=42][payload_offset=50]

Charles

cardigliano commented 5 years ago

@charlesboyo please check latest dev code on github, I reworked the whole code, it should work with QinQ now (also when the vlan and qniq tags contain the same id). Please let me know if it works for you know.

charlesboyo commented 5 years ago

Great! It works now.

[Packet] [00:16:3E:9E:13:FA -> FF:FF:FF:FF:FF:FF] [vlan 301] [QinQ-vlan 301] [IPv4][192.168.1.83:42835 -> 192.168.1.255:15600] [l3_proto=UDP][hash=2169563347] [caplen=85][len=85][eth_offset=0][l3_offset=22][l4_offset=42][payload_offset=50] [Packet] [00:16:3E:D2:A2:2C -> 01:00:5E:00:00:FB] [vlan 301] [QinQ-vlan 170] [IPv4][192.168.1.235:5353 -> 224.0.0.251:5353] [l3_proto=UDP][hash=2695376374] [caplen=111][len=111][eth_offset=0][l3_offset=22][l4_offset=42][payload_offset=50]