On 1 September 2015 at 18:44, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Mon, Aug 31, 2015 at 09:55:23AM +0200, Arturo Borrero Gonzalez wrote: >> On 28 August 2015 at 18:49, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: >> > >> > Are these FTP data flows? I'm asking this because the master >> > connection (control flow) may be missing in the conntrack table, thus >> > the ENOENT error. >> >> Makes sense. >> >> Would you consider accepting the patch? > > I think you can fix the problem that you're noticing by extending > timer_add(). > > Note that the general idea behind the alarm approach is to insert a > timer with a random time wait in unit from 0..M seconds. > > A quick workaround to address this is that master conntracks are > placed in the time range from 0..N/2, then you place non-master > conntrack entries in the range from N/2+1 to M. Then, unless there is > packet loss, most likely the expected conntrack will find the master > one. > > It should be just a few more extra lines away from this oneliner. I keep thinking about this, and I have a few questions: timer_add() seems to manage timers for both internal and external caches. Is it okay to include the workaround you mentioned for *both* internal and external caches? This is what I've understood: the master conntrack in the internal cache of the sending node is vanishing before the non-master conntrack, and then the non-master conntrack is being synced again to the receiving node without the associated master conntrack. Is this assumption true? Other possibility is that both master and non-master conntracks are sycned, but then the receiving node fails to somehow inject to the kernel in the required order. Could you please give me additional hints? regards. -- Arturo Borrero González -- 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
