[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