[strongSwan] received netlink error: No such file or directory
Barry G
mr.scada at gmail.com
Thu Feb 17 22:41:41 CET 2011
Martin,
> From whatever source this digest_null comes from, it is completely
> wrong. I'm in doubt that it comes from the IKE daemon.
Correct
> 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.
Thanks for your help. I checked into the algorithm selection thing
but it hasn't
changed.
I did some playing and found the following on both client
and server with the broken (4.5.1) strongswan build:
07[KNL] Adding SAD entry with SPI c6fd223a and reqid {1}
07[KNL] using encryption algorithm AES_CBC with key size 128
07[KNL] using integrity algorithm HMAC_SHA2_256_128 with key size 256
07[KNL] sending XFRM_MSG_UPDSA: => 436 bytes @ 0x4b82f43c
07[KNL] 0: 00 00 01 B4 00 1A 00 05 00 00 00 CA 00 00 05 B6 ................
07[KNL] 16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 32: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 48: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 64: 00 00 00 00 00 00 00 00 C0 A8 01 01 00 00 00 00 ................
07[KNL] 80: 00 00 00 00 00 00 00 00 C6 FD 22 3A 32 00 00 00 ..........":2...
07[KNL] 96: C0 A8 01 02 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 112: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
07[KNL] 128: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
07[KNL] 144: 00 00 00 00 00 00 0B 95 00 00 00 00 00 00 0E 10 ................
07[KNL] 160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 176: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 192: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 208: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 224: 00 00 00 01 00 02 01 20 00 00 00 00 00 00 00 00 ....... ........
07[KNL] 240: 00 58 00 02 61 65 73 00 00 00 00 00 00 00 00 00 .X..aes.........
07[KNL] 256: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 272: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 288: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 304: 00 00 00 00 00 00 00 80 2B F2 32 E7 FD 3E F7 C7 ........+.2..>..
07[KNL] 320: 4B 28 E9 8B D3 76 70 D4 00 6C 00 14 68 6D 61 63 K(...vp..l..hmac
07[KNL] 336: 28 73 68 61 32 35 36 29 00 00 00 00 00 00 00 00 (sha256)........
07[KNL] 352: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 368: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07[KNL] 384: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 ................
07[KNL] 400: 00 00 00 80 6B E7 E3 7B C0 00 41 34 F1 97 BB 22 ....k..{..A4..."
07[KNL] 416: AF BA 85 C3 DF 44 6B D8 ED C6 EC 39 9B 44 7D C8 .....Dk....9.D}.
07[KNL] 432: D3 04 C4 84 ....
07[KNL] received netlink error: No such file or directory (2)
I tracked the problem down to the 0x14 (byte 331 (rta_type for the int_alg))
of the packet.
When strongSwan sends the struct nlmsghdr into the kernel via
the netlink socket, it either has an auth payload of xfrm_algo_auth
or xfrm_algo based on changes to kernel_netlink_ipsec.c. Unfortunately,
my old kernel doesn't know about the XFRMA_ALG_AUTH_TRUNC type. As
such, when my kernel looked up that dude it didn't find it. This
resulted in the struct nlattrs **attrs parameter to xfrm_add_sa
having a NULL value in attrs[XFRMA_ALG_AUTH]. This NULL value results
in digest_null in esp_init_authenc. Applying the following
patch "fixed" it for me:
--- strongswan/src/libhydra/plugins/kernel_netlink/kernel_netlink_ipsec.c@@/main/LATEST
2011-02-14 13:27:11.000000000 -0800
+++ strongswan/src/libhydra/plugins/kernel_netlink/kernel_netlink_ipsec.c
2011-02-17 12:59:22.000000000 -0800
@@ -1036,29 +1036,6 @@
DBG2(DBG_KNL, " using integrity algorithm %N with key size %d",
integrity_algorithm_names, int_alg, int_key.len * 8);
- if (int_alg == AUTH_HMAC_SHA2_256_128)
- {
- struct xfrm_algo_auth* algo;
-
- /* the kernel uses SHA256 with 96 bit
truncation by default,
- * use specified truncation size supported by
newer kernels */
- rthdr->rta_type = XFRMA_ALG_AUTH_TRUNC;
- rthdr->rta_len = RTA_LENGTH(sizeof(struct
xfrm_algo_auth) + int_key.len);
-
- hdr->nlmsg_len += rthdr->rta_len;
- if (hdr->nlmsg_len > sizeof(request))
- {
- return FAILED;
- }
-
- algo = (struct xfrm_algo_auth*)RTA_DATA(rthdr);
- algo->alg_key_len = int_key.len * 8;
- algo->alg_trunc_len = 128;
- strcpy(algo->alg_name, alg_name);
- memcpy(algo->alg_key, int_key.ptr, int_key.len);
- }
- else
- {
struct xfrm_algo* algo;
rthdr->rta_type = XFRMA_ALG_AUTH;
@@ -1074,7 +1051,7 @@
algo->alg_key_len = int_key.len * 8;
strcpy(algo->alg_name, alg_name);
memcpy(algo->alg_key, int_key.ptr, int_key.len);
- }
+
rthdr = XFRM_RTA_NEXT(rthdr);
}
Obviously this isn't a good fix, as new kernels will be upset. For those of us
running older kernels this is an issue. This patch allowed me to find
root cause.
Any ideas how to fix this properly?
Thanks for your help and guidance,
Barry
More information about the Users
mailing list