<div dir="ltr"><div class="gmail_quote"><br><div dir="ltr">Hi, <div><br></div><div>I have patched the xframe.h and I am taking the errors below:</div><div><br></div><div><div>Oct 25 14:38:33 01[IKE] <vpntest_localne-host34_uzaknetwork|1> activating new tasks</div><div>Oct 25 14:38:33 01[IKE] <vpntest_localne-host34_uzaknetwork|1> activating QUICK_MODE task</div><div>Oct 25 14:38:33 01[CFG] <vpntest_localne-host34_uzaknetwork|1> configured proposals: ESP:3DES_CBC/HMAC_MD5_96/MODP_1024/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ</div><div>Oct 25 14:38:33 01[KNL] <vpntest_localne-host34_uzaknetwork|1> getting SPI for reqid {1}</div><div>Oct 25 14:38:33 01[KNL] <vpntest_localne-host34_uzaknetwork|1> allocating SPI failed: Invalid argument (22)</div><div>Oct 25 14:38:33 01[KNL] <vpntest_localne-host34_uzaknetwork|1> unable to get SPI for reqid {1}</div><div>Oct 25 14:38:33 01[IKE] <vpntest_localne-host34_uzaknetwork|1> allocating SPI from kernel failed</div><div>Oct 25 14:38:33 01[MGR] <vpntest_localne-host34_uzaknetwork|1> checkin and destroy IKE_SA vpntest_localne-host34_uzaknetwork[1]</div><div>Oct 25 14:38:33 01[IKE] <vpntest_localne-host34_uzaknetwork|1> IKE_SA vpntest_localne-host34_uzaknetwork[1] state change: ESTABLISHED => DESTROYING</div><div>Oct 25 14:38:33 01[MGR] check-in and destroy of IKE_SA successful</div></div><div><br></div><div>and the patch which I had done below:</div><div><br></div><div><div>--- ~/src/include/linux/xfrm.h 2014-10-25 16:27:11.000000000 +0300</div><div>+++ ~/src/include/linux/xfrm.h.mod 2014-10-25 16:26:56.000000000 +0300</div><div>@@ -355,6 +355,7 @@</div><div> __u8 mode; /* XFRM_MODE_xxx */</div><div> __u8 replay_window;</div><div> __u8 flags;</div><div>+ __u32 dummy_alligner;</div><div> #define XFRM_STATE_NOECN 1</div><div> #define XFRM_STATE_DECAP_DSCP 2</div><div> #define XFRM_STATE_NOPMTUDISC 4</div></div><div><br></div><div>what should be missing?</div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 6:31 PM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Tugrul,<br>
<br>
> > <a href="https://wiki.strongswan.org/issues/352" target="_blank">https://wiki.strongswan.org/issues/352</a><br>
<span><br>
> The ticket mentions about a specially designed xfrm.h to be replaced<br>
> when running 32bit host on 64bit kernel.<br>
<br>
</span>The problem is that one of the structures in xfrm.h does not use the<br>
same binary layout when compiled under 32bit and 64bit. This in the end<br>
breaks the ABI, as the kernel expects a 64bit layout, but receives a<br>
32bit layout from userspace.<br>
<br>
The offending struct seems to be xfrm_usersa_info:<br>
32-bit: sizeof(struct xfrm_usersa_info): 220 bytes<br>
64-bit: sizeof(struct xfrm_usersa_info): 224 bytes<br>
<br>
Fortunately the offset of all members seem to be equal, so it is more<br>
about these extra 4 bytes that must be handled.<br>
<br>
A clean fix would actually introduce a compatibility fix in the 64-bit<br>
kernel, where it takes these differences into account when it talks to a<br>
32-bit process, parsing requests or building responses accordingly.<br>
<br>
Alternatively you could detect a 64-bit kernel in 32-bit strongSwan<br>
builds, and then add four extra bytes to the xfrm_usersa_info struct.<br>
<br>
Regards<br>
<span><font color="#888888">Martin<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></div><br></div>