Bug 1283468 – keyingtries=0 is broken - meaning it is interpreted as keyingtries=1

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 1283468 - keyingtries=0 is broken - meaning it is interpreted as keyingtries=1

Summary:	keyingtries=0 is broken - meaning it is interpreted as keyingtries=1

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	libreswan (Show other bugs)
Sub Component:
Version:	7.2
Hardware:	All Linux

Priority	high Severity medium
Target Milestone:	rc
Target Release:	---
Assigned To:	Paul Wouters
QA Contact:	Ondrej Moriš
Docs Contact:	Mirek Jahoda

URL:
Whiteboard:	Regression
Keywords:	ZStream

Depends On:
Blocks:	1386666
	Show dependency tree / graph

Reported:	2015-11-18 23:05 EST by Paul Wouters
Modified:	2016-11-08 06:21 EST (History)
CC List:	6 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:	In Libreswan 3.13, 3.14, and 3.15, the "keyingtries=0" option for the "ipsec whack" command did not work properly. Consequently, the pluto IKE daemon stopped trying to establish the tunnels that were not immediately established if "keyingtries=0" was used. With this update, pluto tries to establish the tunnel with "keyingtries=0" indefinitely.
Story Points:	---
Clone Of:
Clones:	1289498 1386666 (view as bug list)
Environment:
Last Closed:	2016-11-03 17:22:02 EDT
Type:	Bug
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2016:2603	normal	SHIPPED_LIVE	Moderate: libreswan security and bug fix update	2016-11-03 08:13:02 EDT

Groups: None (edit)

Description Paul Wouters 2015-11-18 23:05:13 EST

Bug was introduced upstream in 3.15 only.

Patch is in upstream git 3c8dc46d53e3e5004b88f30b5ec3d06d5337951c

Comment 2 Ondrej Moriš 2015-11-25 09:22:30 EST

Adding a Regression keyword.

Comment 3 Ondrej Moriš 2015-11-25 09:25:23 EST

It might be good to fix this either in 7.2.z or 7.3.0. It is not really FIPS-related but I might be quite important.

Comment 5 Paul Wouters 2015-11-25 11:18:26 EST

note the effects are:

if during negotiation failure there is a temporary problem, it will not try to connect for more than one time.

If the connection is up, and the remote end sends a delete ( eg restats) the local end will not attempt to reconnect (but the remote end might)

Comment 7 Paul Wouters 2015-11-26 11:15:41 EST

the default values is 0 (keep retrying forever)

Comment 8 Ondrej Moriš 2015-11-27 09:54:38 EST

(In reply to Paul Wouters from comment #7)
> the default values is 0 (keep retrying forever)

Ah, that is correct (I was mistakenly looking into ipsec_pluto(8) where the default value is 3).

Comment 9 Paul Wouters 2015-11-27 10:36:37 EST

Fixed ipsec_pluto man page upstream :)

Comment 16 errata-xmlrpc 2016-11-03 17:22:02 EDT

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2603.html

Note You need to log in before you can comment on or make changes to this bug.