Any news about this patch?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 21 2021
Jan 4 2021
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?
Dec 23 2020
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.
Dec 16 2020
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.
Nov 4 2020
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?
Nov 2 2020
Hi Kristof,