[Swan-dev] why does ikev1-hostpair-01 fail?

Paul Wouters paul at nohats.ca
Sat Jun 23 17:39:18 UTC 2018


On Sat, 23 Jun 2018, D. Hugh Redelmeier wrote:

> Failure to lease an address is handled in modecfg_resp():
>
> 	if (!get_internal_addresses(st, &ia, &has_lease))
> 		return STF_INTERNAL_ERROR;
>
> STF_INTERNAL_ERROR is meant to report a bug in Pluto.
> This is not an internal error, it is a resource exhaustion.  I think
> that this should be handled by a notification.  This would give the
> other side a clue about what went wrong.

Ahh I see. I had changed the test to be a pool of 1 because it was
not giving me the same IP after reconnect. Only later on did I
realise that is because of another patch that never re-uses the
lease when using authby=secret (because of group ID/PSK), so I
switched the test to use RSA. So the pool can be made bigger again,
and we can test it gets the same IP.

> Which notification error type?  Maybe some XAUTH draft spells this
> out.  Failing that, RFC 2408 specifies 26 for ADDRESS-NOTIFICATION but
> doesn't seem to suggest when it might be used or what it means.
> Googling only gets me obsolete drafts.  We don't currently generate
> it.

I guess there is INTERNAL_ADDRESS_FAILURE (36) or TEMPORARY_FAILURE (43)

Note that according to RFC 7296, the first must result in the IKE SA
being established while the second one does not.

> This is because modecfg_send_set() ignored the status result of
> modecfg_resp().  I've fixed this.

Thanks!

Paul


More information about the Swan-dev mailing list