[Openswan dev] Re: CK_INSTANCE for clear

Mon Apr 17 18:11:57 CEST 2006

-----BEGIN PGP SIGNED MESSAGE-----

| From: Michael Richardson <mcr at xelerance.com>

| At line 4613 of connecitons.c, in:
| 
| add_group_instance():
| 
|         t->kind = isanyaddr(&t->spd.that.host_addr) && !NEVER_NEGOTIATE(t->policy) 
|             ? CK_TEMPLATE : CK_INSTANCE; 
| 
| I can't understand why "CK_INSTANCE" is the right value for when
| it can be negotiated, but it isn't the any address.

I don't remember this stuff that well.

This is to do with group conn instantiation.  If the remote side is
a specific CIDR (as opposed to %any), then this is a full
instantiation.  Otherwise, it is an partial instantiation, to template.

(It might be nice if you could have "CIDR-constrained templates", i.e.
ones in which there was a wildcard that was limited to a CIDR.  But
that wasn't the case.  The added complexity might not have paid for
itself anyway.)

| Specifically the "clear-or-private" type conn has it's policy members 
| set to CK_INSTANCE, which confuses things later on in decode_peer_id(),
| when we find a more suitable conn from refine_host_connection().

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

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

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

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