Any news about this patch?

In D27018#620990, @kp wrote:

So given the test script above, doing a ping -c 1 198.51.100.3 produces one packet on lo0 and two on ${epair_recv}b. Is that expected?

Because the duplicated packet goes to lo0 (with a dup-to (lo0 127.0.0.1)), it will be read as a new input packet.
If the dup-to is used to get routed packet, it must be applied on the "pass out" . Otherwise, the duplicated packets will be routed to the external interface again.
If the dup-to is applied on the "pass out", this packet will be consumed/removed by this patch before being routed.

In D27018#604562, @kp wrote:

In D27018#604557, @yannis.planus_alstomgroup.com wrote:

In D27018#604255, @kp wrote:

Also, it appears to panic:
...
It looks like this happens because we enqueue an mbuf and free it later. ip_input() has an mbuf pointer to a freed mbuf here.

Oh, I missed it... I'll have a look at it, how do you produce this panic? Do you know if the mbuf pointer of ip_input() corresponds to the real one or the dupliacted one?

I've got this start of a test case and then ping -c 1 198.51.100.3 from the host machine. I also have tcpdump running in the jail, but that's not likely to be relevant.

dup_to_body()
{
        pft_init

        epair_send=$(vnet_mkepair)
        ifconfig ${epair_send}a 192.0.2.1/24 up

        epair_recv=$(vnet_mkepair)
        ifconfig ${epair_recv}a up

        vnet_mkjail alcatraz ${epair_send}b ${epair_recv}b
        jexec alcatraz ifconfig ${epair_send}b 192.0.2.2/24 up
        jexec alcatraz ifconfig ${epair_recv}b 198.51.100.2/24 up
        jexec alcatraz sysctl net.inet.ip.forwarding=1
        jexec alcatraz arp -s 198.51.100.3 00:01:02:03:04:05
        route add -net 198.51.100.0/24 192.0.2.2

        jexec alcatraz pfctl -e

        pft_set_rules alcatraz "pass in on { ${epair_send}b } dup-to (lo0 127.0.0.1)"

        sleep 3600
}

When I find time and motivation I'll see about making the test actually check to make sure we don't have extra duplications, but that has to be done manually for now.

In D27018#604255, @kp wrote:

Also, it appears to panic:
...
It looks like this happens because we enqueue an mbuf and free it later. ip_input() has an mbuf pointer to a freed mbuf here.

In D27018#604230, @kp wrote:

Do you know why we see three duplicates, as opposed to an endless loop of dupes?

Hi Kristof,