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

[D. Hugh Redelmeier]

I'm comparing east.pluto.log from a while ago (which didn't fail this way) 
and a run from a night or so ago.


< | 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

And then it emits a packet that looks BAD.  And it's not encrypted.

| sending 260 bytes for ModeCfg set through eth1:4500 to 192.1.2.63:4500 (using #3)
|   00 00 00 00  00 29 b7 d6  0f fd 26 63  85 6f 84 e7
|   b9 ca 19 89  08 10 06 01  08 32 89 fb  fa fa fa fa
|   0e 00 00 24  00 00 00 00  00 00 00 00  00 00 00 00
|   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
|   00 00 00 00  00 00 fa fa  03 00 00 00  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa  fa fa fa fa  fa fa fa fa  fa fa fa fa
|   fa fa fa fa

Of course road keeps retrying but failing.  And that shows up in a
diff.  But the real rot (above) is in the pluto log and so not in a
diff.

What caused this behaviour to manifest itself recently was 84a0478ae0.
It changed the size of the addresspool for east in ikev1-hostpair-01.

Still, this is a Good Thing.  I think that east's pluto was driven
into a bug.  Which we should fix.

Unfortunately historical runs give us no hint as to when this bug was
introduced.

Summary:

- it looks like a config bug that will cause this to fail until the
  addresspool is enlarged.  But perhaps pluto needs to be able to
  reassign that single address.

- bad things seem to happen when the addresspool is exhausted.
  Those bad things ought to be handled more gracefully.

- as it is, addresspool exhaustion does not show up distinctively in a
  console log and so it won't show up distinctively in a diff.