On 6 September 2018 at 14:07, zrm <zrm@xxxxxxxxxxxxxxx> wrote: > On 09/06/2018 12:46 PM, André Paulsberg-Csibi (IBM Consultant) wrote: > This does actually seem to be a race condition in the firewall. There are > two packets as part of the same flow but the second gets processed > concurrent with the first without proper synchronization. I agree. While it may seem strange for glibc to be doing this for DNS, that doesn't stop other UDP protocols from sending out two back-to-back packets. The problem needs to be solved in general. > As for what to do about it, could CONNMARK work here? Suppose you queue > everything without a particular connection mark and then set that mark on > everything somewhere later in processing than where you queue it, so that > all the packets that are part of an existing flow are marked and not queued. > The question is whether there is anywhere to put the queue rule which is > after it's possible to identify that the flow has a particular connmark but > before the packet is dropped. I'll try that out and report back. In other news, I have found that kernel version 4.18 (grabbed from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18/) doesn't seem to have the problem. I suspect the following commit fixed it: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/netfilter/nf_conntrack_core.c?h=v4.18&id=368982cd7d1bd41cd39049c794990aca3770db44 I'll need to compile my own kernel with/without it to confirm, but supposing it does, do you have any suggestions on how to get that commit merged into earlier stable versions of the kernel to increase the likelihood of it being picked up by popular distributions? Or should I just take it up with the distributions themselves?
