Project

General

Profile

Issue #352

unable to allocate SPIs from kernel when running 32 bit binaries on 64 bit Linux

Added by Daniel Albers almost 6 years ago. Updated about 1 year ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
kernel
Affected version:
5.0.4
Resolution:

Description

When using a 32 bit build on a 64 bit Linux kernel, the charon netlink communication seems to fail.

charon: 14[IKE] establishing CHILD_SA peer-c
charon: 14[KNL] getting SPI for reqid {1} 
charon: 14[KNL] sending XFRM_MSG_ALLOCSPI: => 244 bytes @ 0xf03edb9c 
charon: 14[KNL]    0: F4 00 00 00 16 00 01 00 C9 00 00 00 DD 44 00 00  .............D..
charon: 14[KNL]   16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]   32: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]   48: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]   64: 00 00 00 00 00 00 00 00 5C CD 17 E4 00 00 00 00  ........\.......
charon: 14[KNL]   80: 00 00 00 00 00 00 00 00 00 00 00 00 32 00 00 00  ............2...
charon: 14[KNL]   96: 9E FF D5 12 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]  112: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]  128: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]  144: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]  160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]  176: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]  192: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]  208: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
charon: 14[KNL]  224: 01 00 00 00 02 00 01 00 00 00 00 00 00 00 00 C0  ................
charon: 14[KNL]  240: FF FF FF CF                                      ....                      
charon: 14[KNL] allocating SPI failed: Invalid argument (22)
charon: 14[KNL] unable to get SPI for reqid {1}
charon: 14[IKE] unable to allocate SPIs from kernel

Booting a 32 bit kernel, everything works just fine.

This output is from strongSwan 5.0.4 in Linux 3.9 (Debian stock packages), but the same behavior could be observed with e. g. strongSwan 4.5.2 and Linux 3.2.0.

History

#1 Updated by Martin Willi almost 6 years ago

Hi Daniel,

Yes, this is an known issue, resulting from different alignments of a struct from xfrm.h (xfrm_selector, if I remember correctly).

I think it's a design flaw of the XFRM interface, and is actually hard to fix. We could try to detect a 64-bit kernel when running with 32-bit, and then use a specially prepared struct instead of that of xfrm.h.

Regards
Martin

#2 Updated by Daniel Albers almost 6 years ago

Thanks Martin,

Maybe at least print a hint (on debug level) about this when detecting a 32/64 bit environment to save people troubleshooting this some time?

Cheers,
Daniel

#3 Updated by Andreas Steffen almost 6 years ago

  • Status changed from New to Feedback
  • Assignee set to Martin Willi

#4 Updated by Oguz Yilmaz over 4 years ago

Dear Martin and Andreas,

Are there any update on this issue?

#5 Updated by John Comeau almost 2 years ago

just a note for those who found this via Google search and want a resolution, having found `sudo apt-get install strongswan:amd64` has no installation candidate:

instead, `sudo apt-get install libstrongswan:amd64 libssl1.1:amd64 libstrongswan-standard-plugins:amd64 strongswan-charon:amd64`

it replaced the 32-bit versions and now the ipsec tunnel works on my 64-bit kernel.

#6 Updated by Tobias Brunner about 1 year ago

  • Assignee deleted (Martin Willi)

Before the 4.1 kernel (more specifically before 74005991b7), it was possible to modify some structs in the xfrm.h header file to make 32-bit strongSwan work on 64-bit kernels. However, since then this doesn't work anymore without reverting that change in the kernel.
This problem was discussed at the 2018 Linux IPsec workshop and there might actually be a compatibility layer for XFRM in the future as this apparently is an issue on some Android platforms.

Also available in: Atom PDF