Hi Tobias,
Thank you for your reply. If the case you mentioned has been fixed in 5.2.1, the version 5.6.2 that I am running shoud have the fix. And the symptom could be reproduced 100% even only initiate 5 tunnels. What I concern about is that if there are only 5 users configured in ipsec.db, and initiate all the 5 ipsec tunnels, since the first initiator_id starts from "2", the last one with "6" stays at CONNECTING status and could not be established. If further info is needed, please let me know. ---------------------------- root@tester1:/usr/local/etc/ipsec.d# ipsec load-tester initiate 5 1000 .+.+.+.+. ^C root@tester1:/usr/local/etc/ipsec.d# ipsec statusall Status of IKE charon daemon (strongSwan 5.6.2, Linux 4.4.0-62-generic, x86_64): uptime: 29 seconds, since Feb 28 01:04:57 2018 malloc: sbrk 1986560, mmap 0, used 731008, free 1255552 worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 20 loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp curve25519 xcbc cmac hmac mysql sqlite attr load-tester kernel-netlink resolve socket-default stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-simaka-sql eap-simaka-pseudonym eap-simaka-reauth eap-radius eap-tls eap-ttls xauth-generic counters Listening IP addresses: 10.59.128.33 10.64.127.253 Connections: load-test: 192.168.0.6...0.0.0.0 IKEv1/2 load-test: local: [strongswan.org] uses pre-shared key authentication load-test: remote: [*@strongswan.org] uses EAP_AKA authentication load-test: child: 10.65.0.0/18 === dynamic TUNNEL Security Associations (4 up, 1 connecting): load-test[5]: CONNECTING, 10.64.0.5[[email protected]]...192.168.0.6[strongswan.org] load-test[5]: IKEv2 SPIs: 8b95a5331211a1c0_i* 9166956082d58c9a_r load-test[5]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 load-test[5]: Tasks active: IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME load-test[4]: ESTABLISHED 17 seconds ago, 10.64.0.4[[email protected]]...192.168.0.6[strongswan.org] load-test[4]: IKEv2 SPIs: 2c2989876540c256_i* 35538b752a34fd1b_r, rekeying in 6 hours load-test[4]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 load-test{4}: INSTALLED, TUNNEL, reqid 4, ESP SPIs: c6338cd9_i 00176075_o load-test{4}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours load-test{4}: 10.254.32.5/32 === 10.65.0.0/18 load-test[3]: ESTABLISHED 18 seconds ago, 10.64.0.3[[email protected]]...192.168.0.6[strongswan.org] load-test[3]: IKEv2 SPIs: ba3fcb0ca5895aa2_i* a7d05578351da7e6_r, rekeying in 6 hours load-test[3]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 load-test{3}: INSTALLED, TUNNEL, reqid 3, ESP SPIs: c25cd2d0_i 00118964_o load-test{3}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours load-test{3}: 10.254.32.4/32 === 10.65.0.0/18 load-test[2]: ESTABLISHED 19 seconds ago, 10.64.0.2[[email protected]]...192.168.0.6[strongswan.org] load-test[2]: IKEv2 SPIs: 94ee11eb3b5ca229_i* b0033ae63eff015c_r, rekeying in 6 hours load-test[2]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 load-test{2}: INSTALLED, TUNNEL, reqid 2, ESP SPIs: cca6d612_i 00156d18_o load-test{2}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours load-test{2}: 10.254.32.3/32 === 10.65.0.0/18 load-test[1]: ESTABLISHED 20 seconds ago, 10.64.0.1[[email protected]]...192.168.0.6[strongswan.org] load-test[1]: IKEv2 SPIs: 8321948a132ef4d6_i* f476c99ea121d1b7_r, rekeying in 6 hours load-test[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 load-test{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c113aae6_i 0013db54_o load-test{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours load-test{1}: 10.254.32.2/32 === 10.65.0.0/18 root@tester1:/usr/local/etc/ipsec.d# ------------------------ Regards, Li ________________________________ 发件人: Tobias Brunner <[email protected]> 发送时间: 2018年2月27日 9:35 收件人: 李 冠群; [email protected] 抄送: [email protected] 主题: Re: [strongSwan] "%d" of initiator_id of load-tester does not start from 1 but 2. Hi, > I am facing a problem of load-tester that "%d" of initiator_id didnot > start from 1, but from 2. Yes, that's the case since 5.2.0 (since [1] to be exact). I pushed a fix to the load-tester-id branch. Is that really a problem, though? Regards, Tobias [1] https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=2cbaa632
