On Tue, 7 Feb 2017, Jeff Becker wrote:
It should not take a while. It is all instant. You might want to look at
the logs to see what happened? Look for "pluto" logs in /var/log/secure.
Could this be the problem?
#grep errno /var/log/secure
Feb 7 23:20:15 dtn1 pluto[4320]: "dtsd-tunnel"
On 02/06/2017 06:24 PM, Paul Wouters wrote:
On Sat, 4 Feb 2017, Jeff Becker wrote:
Spoke too soon. I reverted to the unlabeled tunnel to test
something, then
restarted the labeled tunnel (successfully) . Once again I couldn't
ping,
but now tracepath didn't work either. When I run ipsec
New commits:
commit 82dbff05d4e08b1458ec682b1af49d3675c7c20c
Author: Andrew Cagney
Date: Tue Feb 7 16:16:33 2017 -0500
cavp: declare header structs extern
so there is no confusion over which .c file has the definition
New commits:
commit c3f46766e724951527fd9ae82c0fb22eb43d7236
Author: Andrew Cagney
Date: Tue Feb 7 14:28:26 2017 -0500
testing: add deleting test keys to 'make kvm-purge'
___
Swan-commit mailing list
>> For the responder, when no ike=, it defaults to accepting almost
>> anything. That includes MD5, serpent, and twofish (but not cast,
>> which is ESP only).
>
>
> It should not include these three. Md5 is too weak and all md5 users
> do sha1. And serpent/twofish are weird ducks and should not
Just installed a new server with ubuntu 16.04 on board and a fresh
installation of libreswan 3.19 compiled as a deb package. Tried to
initialise the nss database with
ipsec initnss
and got the error:
/usr/sbin/ipsec: 319: /usr/sbin/ipsec: =0: not found
/usr/sbin/ipsec: 320: [: -ne:
New commits:
commit c80d64fb2acdeee6fdac21a6d9cf850ff8c1faa9
Author: Andrew Cagney
Date: Tue Feb 7 11:02:44 2017 -0500
testing: update algo-pluto-12-aes-default results for 256-bit keys
Follow up to eb707e2fef44d04fcd067d8568dcfb18602b3579
New commits:
commit 2d046b1fd325455a0bf67625a13085513b847063
Author: Andrew Cagney
Date: Wed Jan 4 12:11:01 2017 -0500
testing: prune some redundant (and not documented by 'make kvm-help') kvm
targets
___
Swan-commit mailing