interface won't be reached with packetcapture cube attached

[goldenrye]

Describe the bug

After attach a packetcapture cube to an host interface, the interface won't be reached from other hosts

To Reproduce

Steps to reproduce the behavior:

1. create packetcapture cube with the following command
   polycubectl packetcapture add pc1 capture=bidirectional
   polycubectl pc1 set filter="host 4.4.4.2" (4.4.4.2 is ip address of another host connecting to the the host polycubed is running)
   polycubectl pc1 set dump="/tmp/jpi"
2. attach the cube to one of host interface, in my case interface name is "ens9" with ip "4.4.4.12"
   polycubectl attach pc1 ens9
3. ping ens9 from host 4.4.4.2
4. ens9 is not able to reach

Expected behavior

Before attaching the cube to the interface, ens9 is reachable from other hosts; with cube enable it should be keep the same behavior

Please tell us about your environment:

1. Ubuntu 18.04.1 LTS
2. 5.2.0-050200-generic
3. polycube version information
   polycubectl:
   version: -128-NOTFOUND+ [git: (branch/commit): master/f199ac1b]
   polycubed:
   version: -128-NOTFOUND+ [git: (branch/commit): master/f199ac1b]
4. Polycube Log: Attach the log from /var/log/polycube/polycubed.log

Additional context

dumped packet information

tcpdump -r /tmp/jpi.pcap -n
12:09:22.570537 IP 4.4.4.12 > 4.4.4.2: ICMP echo reply, id 18252, seq 4, length 64
12:09:22.570582 IP 4.4.4.12 > 4.4.4.2: ICMP echo reply, id 18252, seq 1, length 64
12:09:22.570626 IP 4.4.4.12 > 4.4.4.2: ICMP echo reply, id 18252, seq 3, length 64
12:09:22.570682 IP 4.4.4.12 > 4.4.4.2: ICMP echo reply, id 18252, seq 2, length 64
12:09:22.570727 IP 4.4.4.12 > 4.4.4.2: ICMP echo reply, id 18252, seq 4, length 64
12:09:22.570771 IP 4.4.4.12 > 4.4.4.2: ICMP echo reply, id 18252, seq 1, length 64
12:09:22.570815 IP 4.4.4.12 > 4.4.4.2: ICMP echo reply, id 18252, seq 3, length 64

looks the host replies the icmp request indefinitely

[sebymiano]

I guess this is exactly the same problem that #270 was trying to solve.

[FedeParola]

The problem isn't related just to the packetcapture service, but is due to how the system exchange packets between fast and slow path is designed.
For example it is possible to replicate the same problem with the transparenthelloworld service:

sudo ip netns add ns1
sudo ip link add veth1 type veth peer name veth1_
sudo ip link set veth1_ netns ns1
sudo ip addr add 10.0.0.1/24 dev veth1
sudo ip link set veth1 up
sudo ip netns exec ns1 ip addr add 10.0.0.2/24 dev veth1_
sudo ip netns exec ns1 ip link set veth1_ up

polycubectl transparenthelloworld add th1
polycubectl attach th1 veth1
polycubectl th1 set ingress-action=slowpath

sudo ip netns exec ns1 ping 10.0.0.1 -c 1

Polycube uses a dedicated interface (pcn_tc_cp or pcn_xdp_cp) to send the packet back to the fastpath, so the host system thinks the packet comes from this interface and doesn't know how to reach the other host through it.