pfring_set_cluster with cluster_per_inner_flow_tcp_5_tuple balancing option causes eth_type to be corruped

[teoring]

Hello,

I am using PFRING 7.8.0 from 7.8.0-stable branch commit f0df19bc58f89b552198a83d7c495c25ff4ba5f0. Ubuntu 20.04.3 LTS host, x86_64 arch.

I am sniffing ERSPAN traffic, it has EthernetType: IPv4 ( 0x0800 ). When invoking pfring_set_cluster with cluster_per_inner_flow_tcp_5_tuple cluster type I noticed that after pfring_recv invocation eth header (hdr.extended_hdr.parsed_pkt.eth_type) contains some strange types 0x46, 0x806 and sometimes proper 0x800.

My pfring_open flags are PF_RING_PROMISC, PF_RING_LONG_HEADER, PF_RING_HW_TIMESTAMP.

If I specify a different balancing option, for example cluster_per_flow_tcp_5_tuple, I am constantly receiving proper eth_type 0x800.

Do you recall fixing some bug that might be related to this issue?

[cardigliano]

@teoring this does not look like a known issue. Are you able to provide some packet (pcap file) before and after the "corruption"? Thank you.

[teoring]

That might be an issue since I can't disclose the content of the capture (pcap). But it has nothing special inside, just some ERSPAN type 0x88be (GRE_P_ERSPAN) traffic.

I am using the same PCAP with the same application started few times with different cluster types and both times the same PCAP causes packets to have different eth_type.

Might be you can try to reproduce with any available ERSPAN packet on the internet?

[teoring]

I noticed another issue, that one is disconnected from pfring_set_cluster. pfring_recv on packet captured from interface doesn't parse the packet in a same manner as pfring_parse_pkt on packet loaded with libpcap from PCAP (capture). Is it explected? Should I open a separate issue?

[cardigliano]

I will try with some other ERSPAN traffic, no problem. As of the other issue, yes please open a different ticket with all the details/example.

[teoring]

Thank you.

[teoring]

Let me provide few more details.

I have multiple workers, each of them call pfring_open with flags mentioned above, pfring_set_cluster ( same cluster id ) and pfring_enable_ring.

Then they start polling in non blocking manner with pfring_poll( , 100 ) intervals ( 100 ms ).

        int ret = pfring_recv( aVars.pfringP(), aVars.currentFrameRef().dataPP(), 0,
                               &aVars.currentFrameRef().headerRef(), 0);
                               

Notice that I don't allocate buffer and pass 0 as a len for zero copy optimization.