[Openswan dev] Re: CK_INSTANCE for clear
D. Hugh Redelmeier
hugh at mimosa.com
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:
| 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
| 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.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Dev