On Mon, Jul 09, 2018 at 08:42:17PM +0200, Martynas Pumputis wrote: > On 9 July 2018 at 20:12, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: [...] > >> The idea of this patch is to resolve the conflict only among packets > >> with the same mangling (= with matching tuples). The mangling happens > >> before the confirmation. Please correct me if I'm missing something. > > > > Yes, the mangling happens before confirmation, but will mangle the > > source port to make sure two makes don't get the same tuple. Hence, > > the two packets will get different source port numbers, that's why we > > need the code to undo the NAT mangling in > > 368982cd7d1bd41cd39049c794990aca3770db44. > > If two packets get different source port numbers (by > "get_unique_tuple"), then their CT tuples won't match (= "nf_ct_match" > will return false) => the conflict won't be resolved. I see, so this is just solving the conflict for a specific usecase with NAT in place, ie. get_unique_tuple() returns same tuple... But how so? With NAT in place, the packet losing race will eventually get a different tuple, given the tuple that the first packet is using would be already in use. Do you have any other out-of-tree patch on top of this? Or maybe I am missing anything? :-) -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
