[1/1] netfilter: Fix handling simultaneous open in TCP conntrack

Dominique Martinet reported a TCP hang problem when simultaneous open was used.
The problem is that the tcp_conntracks state table is not smart enough
to handle the case. The state table could be fixed by introducing a new state,
but that would require more lines of code compared to this patch, due to the
required backward compatibility with ctnetlink.

Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Reported-by: Dominique Martinet <asmadeus@codewreck.org>
Tested-by: Dominique Martinet <asmadeus@codewreck.org>
---
 include/uapi/linux/netfilter/nf_conntrack_tcp.h |  3 +++
 net/netfilter/nf_conntrack_proto_tcp.c          | 11 +++++++++++
 2 files changed, 14 insertions(+)

On Sat, Apr 21, 2018 at 01:43:48PM +0200, Jozsef Kadlecsik wrote:
> Dominique Martinet reported a TCP hang problem when simultaneous open was used.
> The problem is that the tcp_conntracks state table is not smart enough
> to handle the case. The state table could be fixed by introducing a new state,
> but that would require more lines of code compared to this patch, due to the
> required backward compatibility with ctnetlink.

Applied, thanks Jozsef.

BTW, what is exactly the problem in ctnetlink. I think probably there
is a way to do some mapping to avoid this. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Pablo,

[Sorry for the delay.]

On Fri, 27 Apr 2018, Pablo Neira Ayuso wrote:

> On Sat, Apr 21, 2018 at 01:43:48PM +0200, Jozsef Kadlecsik wrote:
> > Dominique Martinet reported a TCP hang problem when simultaneous open 
> > was used. The problem is that the tcp_conntracks state table is not 
> > smart enough to handle the case. The state table could be fixed by 
> > introducing a new state, but that would require more lines of code 
> > compared to this patch, due to the required backward compatibility 
> > with ctnetlink.
> 
> BTW, what is exactly the problem in ctnetlink. I think probably there is 
> a way to do some mapping to avoid this. Thanks!

There's nothing wrong with ctnetlink, I was too terse.

If a new state is introduced, then there'd be a hole in several internal 
tables (tcp_conntrack_names, tcp_timeouts, tcp_conntracks state table) and 
that'd be ugly. However if the states are renumbered in order to get rid 
of the holes, then that'd broke the backward compatibility in ctnetlink - 
and userspace anyway, because the constants are exposed through 
uapi/linux/netfilter/nf_conntrack_tcp.h. Or some mapping could be used as 
you suggest but that seems to be overkill compared to the few lines of 
code in the patch.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html