[Openswan dev] CK_INSTANCE for clear

Michael Richardson mcr at sandelman.ottawa.on.ca
Sun Nov 5 13:24:08 EST 2006

Hash: SHA1

>>>>> "D" == D Hugh Redelmeier <hugh at mimosa.com> writes:
    D> | Specifically the "clear-or-private" type conn has it's policy members 
    D> | set to CK_INSTANCE, which confuses things later on in decode_peer_id(),
    D> | when we find a more suitable conn from refine_host_connection().

    D> | The bug I was investigating is that we fail to create an instance
    D> | properly of the clear-or-private# conn, and use the "group"
    D> | itself, and it therefore isn't instantiated, and the remote id is
    D> | "(none)", which screwed up the DNS lookup. 

    D> Isn't this a case where the isanyaddr is true?  So why didn't it come
    D> out a CK_TEMPLATE?  Was NEVER_NEGOTIATE true?  It certainly should not
    D> be for anything named clear-or-private.

    D> | Somehow this leads to an unhash_state() eventually acting on a state
    D> | that has been modified since it was hashed, and it no longer is in the
    D> | same bucket. 

    D> Boy, that symptom is late to the party.  Failure ought to be
    D> manifest as  early as possible.

  So, with 2.4.7 everything works. I don't quite know why --- I need to
back-port some changes to ipsec whack --status to convince myself that
things were working by fluke.

  In 2.5.00 (which is now a .tar.gz), there are potentially more conns
loaded that are invalid --- i.e. can not be oriented, etc. but, in the
default situation, there shouldn't be any more than before.

  I investigated this again recently, and after making a stack of weird
changes and debugs, concluded that I'd either broken something
fundamental, or it was always broken and worked by fluke.

  In particular, I need to make the process of creating templates more
obvious, and the entire "which conn should I use now" question needs to
be placed into unit tests.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Finger me for keys


More information about the Dev mailing list