slow tcp connect when using IPsec
Subsystems (3)
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 <[email protected]> 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
PATCH 1/1 route: Take the right src and dst addresses in ip_route_newports
When we set up the flow informations in ip_route_newports(), we take the address informations from the the rt_key_src and rt_key_dst fields of the rtable. They appear to be empty. So take the address informations from rt_src and rt_dst instead. This issue was introduced by commit 5e2b61f78411be25f0b84f97d5b5d312f184dfd1
--- include/net/route.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
include/net/route.h +2 -2
@@ -270,8 +270,8 @@ static inline struct rtable *ip_route_newports(struct rtable *rt,struct flowi4 fl4 = { .flowi4_oif = rt->rt_oif, .flowi4_mark = rt->rt_mark, - .daddr = rt->rt_key_dst, - .saddr = rt->rt_key_src, + .daddr = rt->rt_dst, + .saddr = rt->rt_src, .flowi4_tos = rt->rt_tos, .flowi4_proto = protocol, .fl4_sport = sport,
Signature · 1 line
1.7.0.4
Re: [PATCH] route: Take the right src and dst addresses in ip_route_newports
From: Steffen Klassert <[email protected]>
Date: Fri, 25 Mar 2011 07:42:03 +0100
Quoted 7 lines
When we set up the flow informations in
ip_route_newports(), we take the address informations from the thert_key_srcandrt_key_dstfields of the rtable. They appear to be empty. So take the address informations fromrt_srcandrt_dstinstead. This issue was introduced by commit5e2b61f78411be25f0b84f97d5b5d312f184dfd1Signed-off-by Steffen Klassert <[email protected]>
Applied, thank you.
David Miller
maintainerFrom: Steffen Klassert <[email protected]>
Date: Fri, 25 Mar 2011 07:41:16 +0100
Quoted 6 lines
commit
5e2b61f78411be25f0b84f97d5b5d312f184dfd1Author: David S. Miller <[email protected]> Date: Fri Mar 4 21:47:09 2011 -0800ipv4: Remove flowi from struct rtable.
Quoted 7 lines
Some time and a lot of
trace_printkslater I found that we set up the flow informations without source _and_ destination address inip_route_newports(). That is because we take the address informations from the thert_key_srcandrt_key_dstfields of the rtable here and they appear to be empty. If I restore the behaviour before the bisected commit by taking the address informations fromrt_srcandrt_dstthe issue is gone.
Indeed, it is wrong to use the key values, since they can be wildcards. Thanks for tracking this down.
Quoted 3 lines
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...
After some time, TCP will mark routing path as having trouble, then it will relookup the route. At this point source and dest will no longer be wildcarded in the socket, and thus neither will be the resulting route keys in the relooked-up route.
Look for the dst_negative_advice() paths to see where this happens.
Quoted 11 lines · David Miller
Quoted 4 lines
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...
After some time, TCP will mark routing path as having trouble, then it will relookup the route. At this point source and dest will no longer be wildcarded in the socket, and thus neither will be the resulting route keys in the relooked-up route.
Look for the
dst_negative_advice()paths to see where this happens.
Ok, I see. Thanks for the explanation.