Suggest using journalctl (I guess) to see more details. One of the earliest log messages is about loading NSS and loading the certificate db (here a smart card).
> Apr 28 22:47:50 blah pluto[5234]: MODP3072 IKEv1: > IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh15 > Apr 28 22:47:50 blah pluto[5234]: MODP4096 IKEv1: > IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh16 > Apr 28 22:47:50 blah pluto[5234]: MODP6144 IKEv1: > IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh17 > Apr 28 22:47:50 blah pluto[5234]: MODP8192 IKEv1: > IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh18 > Apr 28 22:47:50 blah pluto[5234]: DH19 IKEv1: > IKE IKEv2: IKE ESP AH FIPS NSS(ECP) ecp_256, ecp256 > Apr 28 22:47:50 blah pluto[5234]: DH20 IKEv1: > IKE IKEv2: IKE ESP AH FIPS NSS(ECP) ecp_384, ecp384 > Apr 28 22:47:50 blah pluto[5234]: DH21 IKEv1: > IKE IKEv2: IKE ESP AH FIPS NSS(ECP) ecp_521, ecp521 > Apr 28 22:47:50 blah pluto[5234]: DH31 IKEv1: > IKE IKEv2: IKE ESP AH NSS(ECP) curve25519 > Apr 28 22:47:50 blah pluto[5234]: testing CAMELLIA_CBC: > Apr 28 22:47:50 blah pluto[5234]: Camellia: 16 bytes with 128-bit key So pluto hung? As part of its self-check pluto makes calls into the NSS library: - they always work - they never hang - they're pointless as NSS does the same checks internally except when they don't :-( Can I suggest pulling a stack dump from pluto so you can see where inside NSS (we assume) it is stuck. That might give you a starting point. Presumably the key is stuck in some weird-o state and not talking, or talking garbage. Perhaps there's a command to reset it without pulling it out. _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
