[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <525DA855.1010905@daper.net>
Date: Tue, 15 Oct 2013 22:40:53 +0200
From: Damian Pietras <damianp@...er.net>
To: netdev@...r.kernel.org
Subject: "xfrm: Fix the gc threshold value for ipv4" broke my IPSec connections
I've recently upgraded from 3.4.x to 3.10.x and this broke my IPSec
setup in transport mode. The simplest test case is to setup few such
connections with few boxes like this:
spdadd 192.168.1.100 192.168.2.100 any -P out ipsec
esp/transport//require
ah/transport//require;
spdadd 192.168.2.100 192.168.1.100 any -P in ipsec
esp/transport//require
ah/transport//require;
Then set up an HTTP server on one box and run ab on the other box to
create come TCP connections:
ab -n 10000 -c 50 http://192.168.1.100/
Then the connect() call will very quickly start returning ENOBUFS. I
haven't seen anything wrong with my simple setup (just copy of
ipsec-howto.org in transport mode and pre shared keys) and started
bisecting. That way I found this commit to break my case:
703fb94ec58e0e8769380c2877a8a34aeb5b6c97
xfrm: Fix the gc threshold value for ipv4
Reverting it on 3.10.15 fixes my issue. This seems to be there from 3.7
and I don't really believe such simple case stayed broken for so long.
Em I missing something or there is really a bug?
If smeone is interested in details of this configuration and commands
I'm running, just let me know. This was reproduced with few VMs under XEN.
--
Damian Pietras
--
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
Powered by blists - more mailing lists