[Bug 1766] nfqueue randomly drops packets with same tuple

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1766

--- Comment #3 from Antonio Ojea <antonio.ojea.garcia at gmail.com> ---
I was tracing the packets with this tool from cilium folks ,
https://github.com/cilium/pwru/tree/main

And I think the problem is here, bear in mind 10.244.1.5 and 10.244.2.4 are the
DNATed addresses for 10.96.0.10



SKB                CPU PROCESS          NETNS      MARK/x        IFACE      
PROTO  MTU   LEN   TUPLE FUNC


0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.96.0.10:53(udp) skb_ensure_writable
0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.96.0.10:53(udp)
inet_proto_csum_replace4
0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.96.0.10:53(udp)
inet_proto_csum_replace4

SKB 0xffff9523b3207080 DNAT 10.96.0.10 to 0.244.1.5 on CPU 1


0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) udp_v4_early_demux
0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) ip_route_input_noref
0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) ip_route_input_slow
0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) fib_validate_source
0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) ip_forward
0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) nf_hook_slow
0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) ip_forward_finish
0xffff9523b3207080 1   <empty>:913286   4026533244 0         vetha5c90841:3 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) ip_output
0xffff9523b3207080 1   <empty>:913286   4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) nf_hook_slow
0xffff9523b3207080 1   <empty>:913286   4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) apparmor_ip_postroute
0xffff9523b3207080 1   <empty>:913286   4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) nf_queue
0xffff9523b3207080 1   <empty>:913286   4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) __nf_queue

SEND 0xffff9523b3207080 to the queue

0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) skb_ensure_writable

0xffff9523b3207080 is returned on CPU 16 

0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp) skb_ensure_writable
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp)
inet_proto_csum_replace4
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.1.5:53(udp)
inet_proto_csum_replace4


and DNATTED again ?? to 10.244.2.4 (we drop here 10.244.1.5)


0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) nf_reroute
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) ip_finish_output
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) __ip_finish_output
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) ip_finish_output2
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) neigh_resolve_output
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) __neigh_event_send
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) skb_clone
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) arp_solicit
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) consume_skb
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) skb_release_head_state
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) skb_release_data
0xffff9523b3207080 16  <empty>:3178406  4026533244 0         veth271ea3e0:5 
0x0800 1500  60    10.244.1.3:45957->10.244.2.4:53(udp) kfree_skbmem

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240828/a00e0fa0/attachment.html>