[PATCH] conntrack: Support L3 protocol-filter on flush

check, the protocol comparison in ctnetlink_dump_table() has been removed. Instead, a filter is created if the GET-message triggering the dump contains an address family. ctnetlink_filter_match() is then used to compare the L3 protocols. Signed-off-by: Kristian Evensen --- net/netfilter

[PATCH] netfilter: nf_queue: Replace conntrack entry

l conntrack entry. Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- net/netfilter/nfnetlink_queue.c | 68 + 1 file changed, 68 insertions(+) diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c index c97966298..

Re: Silently dropped UDP packets on kernel 4.14

Hi Michal, Thanks for providing a nice summary of your experience when dealing with this problem. Always nice to know that I am not alone :) On Thu, May 3, 2018 at 11:42 AM, Michal Kubecek wrote: > One of the ideas I had was this: > > - keep also unconfirmed conntracks in

Re: Silently dropped UDP packets on kernel 4.14

Hi Florian, On Thu, May 3, 2018 at 7:03 AM, Florian Westphal wrote: > I'm sorry for suggesting that. > > It doesn't work, because of NAT. > NAT rewrites packet content and changes the reply tuple, but the tuples > determine the hash insertion location. > > I don't know how to

Re: Silently dropped UDP packets on kernel 4.14

Hello, On Wed, May 2, 2018 at 12:42 AM, Kristian Evensen <kristian.even...@gmail.com> wrote: > My knowledge of the conntrack/nat subsystem is not that great, and I > don't know the implications of what I am about to suggest. However, > considering that the two packets represen

Re: Silently dropped UDP packets on kernel 4.14

Hi, Thanks for your quick and detailed reply! On Wed, May 2, 2018 at 12:24 AM, Florian Westphal wrote: > I'm not sure what the best way to solve this is, we either need > to insert earlier in nfqueue case, or do conflict resolution in nfqueue > case (and perhaps also nat undo?

Re: Silently dropped UDP packets on kernel 4.14

On Tue, May 1, 2018 at 8:50 PM, Kristian Evensen <kristian.even...@gmail.com> wrote: > Does anyone have any idea of what could be wrong, where I should look > or other things I can try? I tried to space the requests out a bit in > time (I inserted a sleep 1 between them), and then t

Silently dropped UDP packets on kernel 4.14

Hello, I am currently debugging an issue where it looks like UDP packets are silently dropped. My setup is a client with a tool that sends two UDP packets (DNS requests) "simultaneously" using the same socket, and then a router running latest OpenWRT (with kernel 4.14.37). What I am seeing is