The manpage on the FIFO interface is misleading and unclear, sorry to
say that.
Esp. the 'd' and 't' feature seems to have changed in subtle ways, that
are not
reflected in changes of the manpage (see cvs last changed...) or input
checks
in ui.c
from isakmpd(8):
THE FIFO USER INTERFACE
t [<phase>] <name>
Tear down the named connection, if active. For name, the
tag
specified in isakmpd.conf(5) or the IP address of the
remote host
can be used.
The IP address (e.g. as of 'peer <address>' in ipsec.conf) can NOT be
used.
Actually the (generated) tag-name MUST be used, basically
peer-1.2.3.4 for main and from-mylan-to-remotelan for quick.
Might work for main, if one uses [1.2.3.4] in isakmpd.conf; but not for
quick.
And who uses isakmpd.conf todays anyway? ;-)
Based on default settings, the needful t-commands can be gatherd by
this:
cd /var/run
echo S > isakmpd.fifo
grep -B1 ip-address-of-peer isakmpd.result | \
awk '/Phase 1/ { printf "echo t main %s > isakmpd.fifo\n", $3 }
/Phase 2/ { printf "echo t quick %s > isakmpd.fifo\n", $3}'
I gave up on writing that in short enough lines for a diff on isakmpd.8
Up to the 'd' part: even more "weird". d <cookies> <msgid> - really?
After reading ui.c and sa.c I come to the conclusion that one would
need the SA identifier (as from isakmpd.report). BUT the internal check
in ui.c:ui_delete() would hinder one from that. The following up
sa_lookup
would need the 0xABCDEF.. BUT the whatever input-check in ui.c will
tell one that this is "malformed/bad argument". *)
Try to pass a valid SA/msgid from isakmpd.report like
"Report> sa_report: 0x2054de200"
"Report> sa_report: msgid 7256fc10"
OR the values of icookie through ui.c:ui_delete / sa.c:sa_lookup
by any means (say, with or without leading 0x - good luck.
Upfront it would be "nice" to have a consistent output, e.g. every hex
is
actually prefixed with 0x (see msgid) and consequently the FIFO will
accept 0x prefixed values in a consistent matter.
I figured the part on how to deal with 't', but I am out of clue on
'd'.
Any insight appreciated.
PS: no, ipsecctl -F and restarting isakmpd/sasyncd is NOT an option.
If one runs over a handful of connections, this can be quite a pain -
esp. when it comes to rekey-time in phase 1.
