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

[Barry G]

On Wed, Feb 16, 2011 at 12:41 AM, Martin Willi <martin at strongswan.org> wrote:
> I couldn't find a ENOENT return value in the kernel XFRM code path for
> adding SAs, nor could I reproduce the issue here with a non-IPv6 kernel.
>
> You may try to track down that ENOENT in the XFRM code by debugging the
> kernel.

Thanks so much for taking the time to look into this.  I did
some digging today and figured out where my illusive -ENOENT
was coming from.  The stack trace looks like:
(gdb) bt
#0  crypto_alg_mod_lookup (name=<value optimized out>, type=<value
optimized out>,
    mask=<value optimized out>) at crypto/api.c:275
#1  0xc0103e3c in crypto_lookup_aead (name=<value optimized out>,
type=<value optimized out>,
    mask=<value optimized out>) at crypto/aead.c:415
#2  0xc0104358 in crypto_alloc_aead (alg_name=0xdd8d3b70
"authenc(digest_null,cbc(aes))", type=3,
    mask=15) at crypto/aead.c:462
#3  0xc02819c8 in esp_init_authenc (x=0xdf30e600) at net/ipv4/esp4.c:492
#4  esp_init_state (x=0xdf30e600) at net/ipv4/esp4.c:566
#5  0xc0294bbc in xfrm_init_state (x=0xdf30e600) at net/xfrm/xfrm_state.c:2079
#6  0xc0298be4 in xfrm_state_construct (skb=<value optimized out>,
nlh=0xdd883800,
    attrs=0xdd8d3c40) at net/xfrm/xfrm_user.c:362
#7  xfrm_add_sa (skb=<value optimized out>, nlh=0xdd883800, attrs=0xdd8d3c40)
    at net/xfrm/xfrm_user.c:408
#8  0xc0298200 in xfrm_user_rcv_msg (skb=0xdf1e49a0, nlh=0xdd883800)
at net/xfrm/xfrm_user.c:2028
#9  0xc022cf08 in netlink_rcv_skb (skb=0xdf1e49a0, cb=0xc02980f8
<xfrm_user_rcv_msg>)
    at net/netlink/af_netlink.c:1705
#10 0xc029776c in xfrm_netlink_rcv (skb=0xdf1e49a0) at net/xfrm/xfrm_user.c:2034
#11 0xc022cc40 in netlink_unicast_kernel (ssk=0xdf094000,
skb=0xdf1e49a0, pid=0,
    nonblock=<value optimized out>) at net/netlink/af_netlink.c:870
#12 netlink_unicast (ssk=0xdf094000, skb=0xdf1e49a0, pid=0,
nonblock=<value optimized out>)
    at net/netlink/af_netlink.c:894
#13 0xc022d714 in netlink_sendmsg (kiocb=<value optimized out>,
sock=0xdf5761c0, msg=0xdd8d3e50,
    len=452) at net/netlink/af_netlink.c:1293
#14 0xc01eac90 in __sock_sendmsg (sock=<value optimized out>,
msg=<value optimized out>,
    size=<value optimized out>) at net/socket.c:563
#15 sock_sendmsg (sock=<value optimized out>, msg=<value optimized out>,
    size=<value optimized out>) at net/socket.c:574
#16 0xc01eafd0 in sys_sendto (fd=<value optimized out>,
buff=0xdd8d3e6c, len=452, flags=0,
    addr=0x4d02e294, addr_len=12) at net/socket.c:1651
#17 0xc01eb8d4 in sys_socketcall (call=11, args=<value optimized out>)
at net/socket.c:2101
#18 0xc00105e0 in syscall_dotrace_cont () at arch/powerpc/kernel/entry_32.S:268


The key was figuring out that on the old strongswan (4.3.4) I get:
Breakpoint 8, crypto_alloc_aead (alg_name=0xdd80bb70
"authenc(hmac(sha256),cbc(aes))", type=0, mask=0) at crypto/aead.c:454

and with the new strongswan (4.5.1) I get:
Breakpoint 8, crypto_alloc_aead (alg_name=0xdd867b70
"authenc(digest_null,cbc(aes))", type=0, mask=0) at crypto/aead.c:454

So crypto_alg_mod_lookup can't find the digest_null stuff
and returns -ENOENT.

Can't figure out why changing from 4.3.4->4.5.1 broke the algorithm
negotiation.  I haven't changed
the ipsec.conf (maybe thats my problem :-).
I have the following in my ipsec.conf:
[snip]
conn net-net-1-2-1
   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
   mobike=no
   pfs=yes
   pfsgroup=modp1536
   leftupdown=/usr/lib/ipsec/sel_updown
   keyingtries=%forever
   dpdaction=clear
   dpddelay=60
   left=192.168.1.1
   right=192.168.1.2
   auto=add
   keyexchange=ikev2
   leftsubnet=10.201.0.0/16
   rightsubnet=192.168.2.0/24
   authby=secret

Both endpoints are symmetric in the ike/esp lines.

Today I noticed on the server:
14[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built

So it looks like I spent a long time tracing down a failed
algo negotiation!  Has the format of the ike/esp lines changed and I missed
it or what?  Since this works with the same kernel on 4.3.4 I
don't think it is a kernel crypto thing.

What obvious thing am I missing?

Thanks,

Barry