[strongSwan] received netlink error: No such file or directory

[Martin Willi]

Hi Barry,

> #2  0xc0104358 in crypto_alloc_aead (alg_name=0xdd8d3b70
>     "authenc(digest_null,cbc(aes))",

>From whatever source this digest_null comes from, it is completely
wrong. I'm in doubt that it comes from the IKE daemon, as we don't even
have a string "digest_null" to select such an algorithm. And from your
log

> 13[KNL] adding SAD entry with SPI ca6f5702 and reqid {2}
> 13[KNL]   using encryption algorithm AES_CBC with key size 256
> 13[KNL]   using integrity algorithm HMAC_SHA2_256_128 with key size 256
> 13[KNL] received netlink error: No such file or directory (2)

I see that the algorithms have been negotiated correctly. You may try to
increase the "cfg" loglevel to see the proposal selection process.

> arch/powerpc/kernel/entry_32.S:268

I couldn't reproduce the problem on x86 using your proposals. Maybe this
is an architecture specific issue, but I don't have a PowerPC for
testing.

>    ike=aes256-sha2_256-modp1536,aes256-sha1-modp1536,aes128-sha2_256-modp1536,aes128-sha1-modp1536,3des-sha2_256-modp1536,3des-sha1-modp1536
>    esp=aes256-sha2_256-modp1536,aes256-sha1-modp1536,aes128-sha2_256-modp1536,aes128-sha1-modp1536,3des-sha2_256-modp1536,3des-sha1-modp1536

You probably can simplify this proposal to
    aes256-aes128-3des-sha256-sha1-modp1536

>    pfs=yes
>    pfsgroup=modp1536

PFS in IKEv2 is used if the ESP proposal contains a DH group, these
options are meaningless for IKEv2.

> Has the format of the ike/esp lines changed and I missed
> it or what?

No, the format should be the same.


I'd suggest to check if the algorithm negotiation works as expected, and
if so, if the algorithms arrive in kernel XFRM with the correct strings
before the aead wrapper gets constructed.

Regards
Martin