From owner-freebsd-current@FreeBSD.ORG Sat Aug 13 05:48:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CA9216A41F; Sat, 13 Aug 2005 05:48:31 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2A6243D48; Sat, 13 Aug 2005 05:48:30 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice3.sentex.ca (pumice3.sentex.ca [64.7.153.26]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j7D5lTQt069916; Sat, 13 Aug 2005 01:47:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice3.sentex.ca (8.13.3/8.13.3) with ESMTP id j7D5mTen050498; Sat, 13 Aug 2005 01:48:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j7D5mRXx043624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2005 01:48:27 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20050813012441.061d08b0@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 13 Aug 2005 01:45:44 -0400 To: Pawel Jakub Dawidek , FreeBSD-current From: Mike Tancsa In-Reply-To: <20050812134511.GE25162@garage.freebsd.pl> References: <20050812134511.GE25162@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.26 Cc: Subject: Re: VIA/ACE PadLock integration with crypto(9). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2005 05:48:31 -0000 At 09:45 AM 12/08/2005, Pawel Jakub Dawidek wrote: >The thing which interest me the most is how it works with fast_ipsec(4). I have been trying to get it to work but I am not sure if its registering or not. I can certainly see a big different with GELI, but with the box acting as a router, iperf shows essentially identical results. FreeBSD itx-vpn.sentex.ca 6.0-BETA2 FreeBSD 6.0-BETA2 #1: Fri Aug 12 23:07:23 EDT 2005 mdtancsa@itx-vpn.sentex.ca:/usr/obj/usr/src/sys/itx i386 [itx-vpn]# kldstat Id Refs Address Size Name 1 5 0xc0400000 458ff0 kernel 2 16 0xc0859000 55ffc acpi.ko 3 1 0xc1fb8000 3000 padlock.ko [itx-vpn]# RELENG_5 box setkey -c < real memory = 467599360 (445 MB) avail memory = 448204800 (427 MB) its essentially the same I have setup RELENG_5 -FastE--- RELENG_6----FastE--clientbox clientbox hits the inside VPN interface of the RELENG_5 box via iperf going across RELENG_6 which is the via/ACE enabled box iperf -c 10.99.98.1 Point to point, I essentially get close to FastE [ 4] local 172.16.1.3 port 5001 connected with 172.16.1.4 port 57661 [ 4] 0.0-10.0 sec 112 MBytes 94.1 Mbits/sec [ 4] local 172.16.1.3 port 5001 connected with 172.16.1.4 port 57913 [ 4] 0.0-10.0 sec 111 MBytes 93.2 Mbits/sec going from clientbox across the tunnel with and without the padlock, its essentially identical which is odd without [ 4] 0.0-10.0 sec 31.2 MBytes 26.1 Mbits/sec [ 4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 62827 [ 4] 0.0-10.0 sec 30.9 MBytes 25.9 Mbits/sec [ 4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 56683 [ 4] 0.0-10.0 sec 30.8 MBytes 25.8 Mbits/sec [ 4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 58964 with padlock.ko loaded [ 4] 0.0-10.0 sec 30.7 MBytes 25.8 Mbits/sec [ 4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 62982 [ 4] 0.0-10.0 sec 31.2 MBytes 26.1 Mbits/sec [ 4] local 10.99.98.1 port 5001 connected with 192.168.43.34 port 65003 [ 4] 0.0-10.0 sec 31.3 MBytes 26.3 Mbits/sec Is there something else that needs to be done to tell crypto(4) or FAST_IPSEC to use the "hardware" in this case ? Also, I came across a small ipsec bug while testing http://www.freebsd.org/cgi/query-pr.cgi?pr=84860 ---Mike