| From: D. Hugh Redelmeier <[email protected]>
| < | request lease from addresspool 192.0.2.1-192.0.2.200 reference count 3
thatid '@road' that.client.addr 192.1.2.63
| > | request lease from addresspool 192.0.2.1-192.0.2.1 reference count 3
thatid '@road' that.client.addr 192.1.2.63
|
| Notice the difference in the pool size?
|
| As a result, the current one fails on its allocation:
|
| "roadnet-eastnet-ipv4-psk-ikev1"[2] 192.1.2.63 #3: lease_an_address failure
no free address in addresspool
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.
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.
If we don't want to send a notification then STF_FAIL without a
notification should be used.
| And then it emits a packet that looks BAD. And it's not encrypted.
This is because modecfg_send_set() ignored the status result of
modecfg_resp(). I've fixed this.
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
