netdev - slow tcp connect when using IPsec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Mar 2011 07:41:16 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: slow tcp connect when using IPsec

I'm fighting with a strange behaviour since a some days.
When I try to send tcp data over an IPsec tunnel, the tcp connect hangs
for about 20 seconds before it finally sends out the SYN packet.
This happens just on tcp with IPsec. When I bind the connection to
a specific local port, everything works fine. After some time of 
unsuccessful debugging, I bisected this issue down to

commit 5e2b61f78411be25f0b84f97d5b5d312f184dfd1
Author: David S. Miller <davem@...emloft.net>
Date:   Fri Mar 4 21:47:09 2011 -0800

    ipv4: Remove flowi from struct rtable.

Some time and a lot of trace_printks later I found that we set up
the flow informations without source _and_ destination address in
ip_route_newports(). That is because we take the address informations
from the the rt_key_src and rt_key_dst fields of the rtable here
and they appear to be empty. If I restore the behaviour before the bisected
commit by taking the address informations from rt_src and rt_dst the issue
is gone. So now I know why it did not behave as expected, but unfortunately
I still don't know why it magically started to work after 20 seconds...

I'll send the patch that fixed the issue in replay to this mail.

Steffen

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html