Reset task manager state when build() completes an exchange (quick mode)

[strongswan.git] / README

diff --git a/README b/README
index 9750e63..58f865d 100644 (file)
--- a/README
+++ b/README
@@ -41,7 +41,7 @@ Contents
        6.1 Loading private key files in PKCS#1 format
        6.2 Entering passphrases interactively
        6.3 Multiple private keys
        6.1 Loading private key files in PKCS#1 format
        6.2 Entering passphrases interactively
        6.3 Multiple private keys

-   7. Configuring CA properties - ipsec.\ 1onf
+   7. Configuring CA properties - ipsec.conf

    8. Smartcard support
        8.1 Configuring a smartcard-based connection
        8.2 Entering the PIN code
    8. Smartcard support
        8.1 Configuring a smartcard-based connection
        8.2 Entering the PIN code


@@ -81,7 +81,7 @@ Contents
 strongSwan is an OpenSource IPsec solution for the Linux operating system
 and currently supports the following features:
 
 strongSwan is an OpenSource IPsec solution for the Linux operating system
 and currently supports the following features:
 

-  * runs both on Linux 2.4 (KLIPS) and Linux 2.6 (native IPsec) kernels.
+  * runs on Linux 2.6 (native IPsec) kernels.

 
   * strong 3DES, AES, Serpent, Twofish, or Blowfish encryption.
 
 
   * strong 3DES, AES, Serpent, Twofish, or Blowfish encryption.
 


@@ -138,7 +138,7 @@ interoperability with the Check Point VPN-1 NG gateway.
    
 In the following examples we assume for reasons of clarity that left designates
 the local host and that right is the remote host. Certificates for users, hosts
    
 In the following examples we assume for reasons of clarity that left designates
 the local host and that right is the remote host. Certificates for users, hosts

-and gateways are issued by a ficticious strongSwan CA. How to generate private keys
+and gateways are issued by a fictitious strongSwan CA. How to generate private keys

 and certificates using OpenSSL will be explained in section 3. The CA certificate
 "strongswanCert.pem" must be present on all VPN end points in order to be able to
 authenticate the peers.
 and certificates using OpenSSL will be explained in section 3. The CA certificate
 "strongswanCert.pem" must be present on all VPN end points in order to be able to
 authenticate the peers.


@@ -1159,7 +1159,7 @@ The presence of a rightca parameter also causes the CA to be sent as
 part of the certificate request message when strongSwan is the initiator.
 A special case occurs when strongSwan responds to a roadwarrior. If several
 roadwarrior connections based on different CAs are defined then all eligible
 part of the certificate request message when strongSwan is the initiator.
 A special case occurs when strongSwan responds to a roadwarrior. If several
 roadwarrior connections based on different CAs are defined then all eligible

-CAs will be listed in Pluto\92s certificate request message.
+CAs will be listed in Pluto�s certificate request message.

 
 
 4.9 IPsec policies based on group attributes
 
 
 4.9 IPsec policies based on group attributes


@@ -1505,12 +1505,16 @@ any certificates to the other end via the IKE Main Mode protocol. Especially
 if self-signed certificates are used which wouldn't be accepted any way by
 the other side. In these cases it is recommended to add
 
 if self-signed certificates are used which wouldn't be accepted any way by
 the other side. In these cases it is recommended to add
 

-          leftsendcert=never
+    leftsendcert=never

 
 to the connection definition[s] in order to avoid the sending of the host's
 own certificate. The default value is
 
 
 to the connection definition[s] in order to avoid the sending of the host's
 own certificate. The default value is
 

-    leftsendcert=always.
+    leftsendcert=ifasked
+
+If a peer does not send a certificate request then use the setting
+
+    leftsendcert=always

 
 If a peer certificate contains a subjectAltName extension, then an alternative
 rightid type can be used, as the example "conn sun" shows. If no rightid
 
 If a peer certificate contains a subjectAltName extension, then an alternative
 rightid type can be used, as the example "conn sun" shows. If no rightid


@@ -1955,7 +1959,7 @@ and the returned result might be a decrypted 128 bit AES key
    000 8836362e030e6707c32ffaa0bdad5540
 
 The leading three characters represent the return code of the whack channel
    000 8836362e030e6707c32ffaa0bdad5540
 
 The leading three characters represent the return code of the whack channel

-with 000 signifying that no error has occured. Here is another example showing
+with 000 signifying that no error has occurred. Here is another example showing

 the use of the inbase and outbase attributes
 
    ipsec scdecrypt m/ewDnTs0k...woE= --inbase base64 --outbase text
 the use of the inbase and outbase attributes
 
    ipsec scdecrypt m/ewDnTs0k...woE= --inbase base64 --outbase text


@@ -2191,7 +2195,7 @@ The command
     ipsec listpubkeys [--utc]
 
 lists all public keys currently installed in the chained list of public
     ipsec listpubkeys [--utc]
 
 lists all public keys currently installed in the chained list of public

-keys. These keys were statically loaded from ipsec.conf or aquired either
+keys. These keys were statically loaded from ipsec.conf or acquired either

 from received certificates or retrieved from secure DNS servers using
 opportunistic mode.
 
 from received certificates or retrieved from secure DNS servers using
 opportunistic mode.
 


@@ -2652,9 +2656,6 @@ with the line
 
 and can be used when the following prerequisites are fulfilled:
 
 
 and can be used when the following prerequisites are fulfilled:
 

-  - Linux 2.4.x kernel, KLIPS IPsec stack, and arbitrary iptables version.
-    Filtering of tunneled traffic is based on ipsecN interfaces.
-

   - Linux 2.6.16 kernel or newer, native NETKEY IPsec stack, and
     iptables-1.3.5 or newer. Filtering of tunneled traffic is based on
     IPsec policy matching rules.
   - Linux 2.6.16 kernel or newer, native NETKEY IPsec stack, and
     iptables-1.3.5 or newer. Filtering of tunneled traffic is based on
     IPsec policy matching rules.


@@ -3118,7 +3119,7 @@ by the pluto/xauth.h header file.
                       Copyright (c) 2000, Kai Martius
 
                   X.509, OCSP and smartcard functionality:
                       Copyright (c) 2000, Kai Martius
 
                   X.509, OCSP and smartcard functionality:

-°
+

   Copyright (c) 2000, Andreas Hess, Patric Lichtsteiner, Roger Wegmann
   Copyright (c) 2001, Marco Bertossa, Andreas Schleiss
   Copyright (c) 2002, Uli Galizzi, Ariane Seiler, Mario Strasser
   Copyright (c) 2000, Andreas Hess, Patric Lichtsteiner, Roger Wegmann
   Copyright (c) 2001, Marco Bertossa, Andreas Schleiss
   Copyright (c) 2002, Uli Galizzi, Ariane Seiler, Mario Strasser


@@ -3147,5 +3148,3 @@ by the pluto/xauth.h header file.
   for more details.
 -----------------------------------------------------------------------------
 
   for more details.
 -----------------------------------------------------------------------------
 

-This file is RCSID $Id: README,v 1.38 2007/01/14 18:16:51 as Exp $
-