[strongSwan] IKE cookies printed in reverse order compared to ipsec statusall.

[Nanda Gopal]

Hi,

I have two targets, on which I am running strongswan 5.2.2.
A single VLAN interface is configured on each .
A any to any protect policy exists.
IKEv2 is used.

Following are the lscpu details of each targets.

*Target A*

*lscpuArchitecture:          armv7lByte Order:            Little
EndianCPU(s):                16On-line CPU(s) list:   0-15Thread(s) per
core:    1Core(s) per socket:    4Socket(s):             4Model name:
     ARMv7 Processor rev 2 (v7l)*

*Target B*

*Architecture:          mips64Byte Order:            Big EndianCPU(s):
           6On-line CPU(s) list:   0-2Off-line CPU(s) list:  3-5Thread(s)
per core:    1Core(s) per socket:    1Socket(s):             3L1d cache:
          32KL1i cache:             37KL2 cache:              2048K*

The problem here is with Target A, which is a ARMv71, Little Endian.


With Target A,Ike cookie as shown in charon logs during establishment phase
matches with captured trace as on tcpcump on target console or with packet
trace outside the target..
But looking into ipsec satusall on target console this is really confusing,
shown here in reverse order.

e.g. from attached charon logs:
2016-02-01T14:17:15.783770+00:00 [info]     charon:  11[IKE] octets =
message + nonce + prf(Sk_px, IDx') = 389 bytes @ 0xad603798
2016-02-01T14:17:15.784628+00:00 [info]     charon:  11[IKE]    0:* 3A CB
BB 0B 41 92 01 E0 E7 A1 EE DB BA 3F 2E E6*  :...A........?..


 from ipsec statusall:

conn65535_9[3]: ESTABLISHED 5 minutes ago, 10.46.167.109[CN=yyyyyyyyy,
O=zzzzzzzzzzzzz]...10.44.34.130[qwwwwwwqqwqqwqwqww]
conn65535_9[3]: IKEv2 SPIs: *e00192410bbbcb3a*_i *e62e3fbadbeea1e7*_r*,
rekeying in 23 hours

I don't see the problem with Target B, which is mips64 Big Endian.
I guess the reversing has to do with Endianess?
Is there a way I could still rectify this issue for Target A?


Note: Some details about the Targets are masked with random letters. :)

Regards
Nanda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160216/ba9f9483/attachment.html>