[Swan-commit] Changes to ref refs/heads/main
New commits: commit 19de59e092962077ba03325dfe08ac65d744ccbc Author: Andrew Cagney Date: Tue May 18 14:11:54 2021 -0400 mobike: only send a duplicate mobike response when md.sender is different Non-mobile informational requests, such as liveness probes were getting back duplicates as the message was sent to both md.sender and .st_remote_endpoint which were the same. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-dev] New Defects reported by Coverity Scan for antonyantony/libreswan
Hi,
Please find the latest report on new defect(s) introduced to
antonyantony/libreswan found with Coverity Scan.
1 new defect(s) introduced to antonyantony/libreswan found with Coverity Scan.
2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent
build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1504902: Insecure data handling (TAINTED_SCALAR)
*** CID 1504902: Insecure data handling (TAINTED_SCALAR)
/programs/pluto/rcv_whack.c: 1108 in whack_handle()
1102if (!unpack_whack_msg(, whack_logger)) {
1103/* already logged */
1104return; /* don't shutdown */
1105}
1106
1107struct show *s = alloc_show(whack_logger);
>>> CID 1504902: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "msg.nr_impairments" to "whack_process",
>>> which uses it as a loop boundary.
1108whack_process(, s);
1109free_show();
To view the defects in Coverity Scan visit,
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yq8aBKViEpsZ9KPFMeJd7kKMDjyzu82COVFw1h1aYx-2FtFrefiPxkohPqZgI7DsTRPR5L954NuJuE0J6c4ee-2B5kYZS_Z_Cir5ZFqEb-2Fpy-2FZDdTxjwNXxDWd37ZfwlkdBT1REyQ3-2FeToKyNVuxGJc5Qr6YaHdfCl-2FHWDoIfb8d4qww4weDsvyIDFvTYO82gRCo0aTy14JwgJRDIs9q3bT4Ix-2B-2BnIoRBPeUzmd1f-2F-2F8YcK7E-2BWIJB6TrE5DtTz6KcABf1e1HoqHrKrKib9k322aItXV2ipsJWq0J8XSV5EUZKMa1WtEYDYYQK7ZYO5-2FUSXEFw1-2BUZo-3D
To manage Coverity Scan email notifications for
"swan-dev@lists.libreswan.org", click
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxUzCfl-2FUi6sRJtnGH1-2FWXEIl9xkb2JliKiAkqgdujeIgWYvUCIHO1g-2Ba8I-2B0nANYHmrw9-2B13a9hJ7YOPZRdlHcEQfoMvDvjqsfrRNzFQ8lscduvXP5RLkPig71dIKudxioWAa_Cir5ZFqEb-2Fpy-2FZDdTxjwNXxDWd37ZfwlkdBT1REyQ3-2FeToKyNVuxGJc5Qr6YaHdfCl-2FHWDoIfb8d4qww4weDshPVj6mJjEIGFCLiRqrsmifxtYBtGnDhZQlYBMYevZtGCsi9p20L8PVAFjjlpopXKdYmNF3N64wunEpFcdC7dXBQy74zlkq51MRaS4qesMJ3e84QKVMPeglIliwFKbJVLFvglpWU6l49-2BNG2YNVkCjw-3D
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 1e7bed0878b27b4850ded9d224ed2338b7336052 Author: Andrew Cagney Date: Thu May 20 13:43:11 2021 -0400 ikev2: in INFORMATIONAL responder, merge/move IKE SA delete code Merge/move the IKE SA delete code so it is all before the mobike send call. Make explicit calls to send the response, update message IDs, call delete_ike_family(ike); finally return immediately with STF_SKIP_COMPLETE_STATE_TRANSITION as the IKE pointer is invalid. This fixes a bug wheren an IKE SA delete request would get two responses. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit d4910a85119201088cd9eebe9d0bd460ee65442c Author: Andrew Cagney Date: Thu May 20 18:02:19 2021 -0400 ikev2: always retry after receiving an unknown IKE_AUTH notify response The code was ignoring protected but unknown responses. I guess the hope was that the retransmit would get back a reply we liked. Sure ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 5948928a978ff565ef9fae781432d5a886c41c17 Author: Andrew Cagney Date: Thu May 20 17:21:41 2021 -0400 kvm: make the OpenBSD base domain ORDER-ONLY dependant on its inputs Suspect this is the reason why the OpenBSD base domain kept rebuilding. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 7ea6798ad1d204b152c1c6b5a11d903f420f523c Author: Andrew Cagney Date: Thu May 20 13:56:58 2021 -0400 ikev2: in INFORMATIONAL responder, record message before doing mobike switch commit 7432e78149ce716a190a21f440b54556fef372c7 Author: Andrew Cagney Date: Thu May 20 10:59:33 2021 -0400 ikev2: delete .st_pend_liveness; never read commit c5ef5a22b94d79babe4991032c8481142f9ccabe Author: Andrew Cagney Date: Thu May 20 10:20:40 2021 -0400 ikev2: v2SK_payload_t -> struct v2SK_payload ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit dcbb03acede7fd7cba150e7b3009807479c19da1 Author: Andrew Cagney Date: Thu May 20 15:28:43 2021 -0400 ikev2: blame the IKE SA for: no useful state microcode entry found for incoming packet commit 294fd8ced7270ee5d6411c1e5d5adca9fd8ef8f1 Author: Andrew Cagney Date: Thu May 20 14:25:57 2021 -0400 kvm: add ./kvm baseline diffs (assumes KVM_BASELINE=... is set) ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan] SA lifetime too short, less than configured
Gzipped log for time 00:42:14 is attached As I understand, other side (Cisco ASA) sends ISAKMP_v2_INFORMATIONAL message contains ISAKMP_NEXT_v2D payload asks to delete the #103354 SA 20.05.2021 19:33, Ivan Kuznetsov пишет: Hello Paul 17.05.2021 18:01, Paul Wouters пишет: On Mon, 17 May 2021, Ivan Kuznetsov wrote: Yes, all the bkp* has the same life times: [root@vpn3 ipsec.d]# ipsec auto --status | grep bkp | grep ike_life 000 "bkp/0x1": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3; 000 "bkp/0x2": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3; 000 "bkp/0x3": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3; 000 "bkp/0x4": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3; That's good Just over one hour is really weird. Can you run with plutodebug=all,tmi and show the log lines you see between these two messages? It can be a bit problematic as this ipsec instance handle 20+ active production connections with different peers/clients. It seems that 'ipsec whack --name bkp/0xN --debug all,tmi' does not have any logging effect. I'm afraid enable debug logging globally will slow down the connections and make a huge log. Ok, how about: ipsec status |grep STATE_ |grep bkp/ I wrote a simple script logging 'ipsec status |grep STATE_ |grep bkp/' every 10s. Here is output (non-interesting lines skipped): 18.05.2021 23:41:28 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82325s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24764s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:41:38 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82315s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24754s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:41:48 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82305s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24744s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:41:58 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82295s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24734s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:42:08 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82285s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24724s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:42:18 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 86054s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 28465s; newest IPSEC; eroute owner; isakmp#103354; idle; 18.05.2021 23:42:28 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 86044s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 28455s; newest IPSEC; eroute owner; isakmp#103354; idle; 18.05.2021 23:42:38 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 86034s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 28445s; newest IPSEC; eroute owner; isakmp#103354; idle; 18.05.2021 23:42:48 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 86024s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 28435s; newest IPSEC; eroute owner; isakmp#103354; idle; [...] 19.05.2021 00:41:14 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82518s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24929s; newest IPSEC; eroute owner; isakmp#103354; idle; 19.05.2021 00:41:24 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82508s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24919s; newest IPSEC; eroute owner; isakmp#103354; idle; 19.05.2021 00:41:34 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82498s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24909s; newest IPSEC; eroute owner; isakmp#103354; idle; 19.05.2021
Re: [Swan] SA lifetime too short, less than configured
Hello Paul 17.05.2021 18:01, Paul Wouters пишет: On Mon, 17 May 2021, Ivan Kuznetsov wrote: Yes, all the bkp* has the same life times: [root@vpn3 ipsec.d]# ipsec auto --status | grep bkp | grep ike_life 000 "bkp/0x1": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3; 000 "bkp/0x2": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3; 000 "bkp/0x3": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3; 000 "bkp/0x4": ike_life: 86400s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 300s; rekey_fuzz: 100%; keyingtries: 3; That's good Just over one hour is really weird. Can you run with plutodebug=all,tmi and show the log lines you see between these two messages? It can be a bit problematic as this ipsec instance handle 20+ active production connections with different peers/clients. It seems that 'ipsec whack --name bkp/0xN --debug all,tmi' does not have any logging effect. I'm afraid enable debug logging globally will slow down the connections and make a huge log. Ok, how about: ipsec status |grep STATE_ |grep bkp/ I wrote a simple script logging 'ipsec status |grep STATE_ |grep bkp/' every 10s. Here is output (non-interesting lines skipped): 18.05.2021 23:41:28 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82325s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24764s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:41:38 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82315s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24754s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:41:48 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82305s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24744s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:41:58 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82295s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24734s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:42:08 000 #103273: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82285s; newest ISAKMP; idle; 000 #103274: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24724s; newest IPSEC; eroute owner; isakmp#103273; idle; 18.05.2021 23:42:18 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 86054s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 28465s; newest IPSEC; eroute owner; isakmp#103354; idle; 18.05.2021 23:42:28 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 86044s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 28455s; newest IPSEC; eroute owner; isakmp#103354; idle; 18.05.2021 23:42:38 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 86034s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 28445s; newest IPSEC; eroute owner; isakmp#103354; idle; 18.05.2021 23:42:48 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 86024s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 28435s; newest IPSEC; eroute owner; isakmp#103354; idle; [...] 19.05.2021 00:41:14 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82518s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24929s; newest IPSEC; eroute owner; isakmp#103354; idle; 19.05.2021 00:41:24 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82508s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24919s; newest IPSEC; eroute owner; isakmp#103354; idle; 19.05.2021 00:41:34 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82498s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24909s; newest IPSEC; eroute owner; isakmp#103354; idle; 19.05.2021 00:41:44 000 #103354: "bkp/0x2":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REKEY in 82488s; newest ISAKMP; idle; 000 #103355: "bkp/0x2":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REKEY in 24899s; newest
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 78f693cf0f3581de34ad0f33ec9ff842d925ee87 Author: Andrew Cagney Date: Wed May 19 15:12:31 2021 -0400 whack: include the whack fd in pluto's "whack: ..." debug messages help with identifying the command that leaked whackfd commit 60fb5b9b1f10ab24af6e052179cf0b74018f9d48 Author: Andrew Cagney Date: Wed May 19 15:45:45 2021 -0400 fd: merge dup_any() and dup_any_fd() into fd_dup() pass WHERE where possible - better refcnt logs ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits:
commit ecae346ba2a789e24c682a2cc6ab7217b375a957
Author: Andrew Cagney
Date: Wed May 19 21:18:35 2021 -0400
ikev2: update v2_INFORMATIONAL's notify code
- add process_v2N_{requests,responses}()
- use md->pd[PD_v2_REDIRECT*] for redirect
- move mobike notify code to ikev2_mobike.[hc]
- ... and process_v2N_mobike_{requests,responses}()
- ... and use IKE SA, not md->v1_sa
- allow both Delete and Notify
___
Swan-commit mailing list
Swan-commit@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit d9a22ee7b307c77f45c417ad4bb96fa5f106296a Author: Andrew Cagney Date: Wed May 19 22:56:35 2021 -0400 logging: delete the global whack_log_fd all whack logging goes through a logger ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
