Re: [Swan-dev] Set keyingtries to 1 for Opportunistic Encryption connections

2020-03-02 Thread Antony Antony
On Mon, Mar 02, 2020 at 09:59:58AM -0500, D. Hugh Redelmeier wrote: > | commit 21100cee5f207c24ee55ad6c612a84a6140ba583 > | Author: Paul Wouters > | Date: Sun Mar 1 21:46:17 2020 -0500 > | > | IKEv2: Set keyingtries to 1 for Opportunistic Encryption connections. > | > | We cannot h

[Swan-dev] ikev2-32-nat-rw-rekey broken by TS bug?

2020-03-02 Thread Paul Wouters
I was testing me TS changes when I noticed a broken testcase: https://testing.libreswan.org/v3.30-191-g1d77da5df1-master/ikev2-32-nat-rw-rekey/OUTPUT/road.console.diff It turns out, it is already broken without my changes. I think what is happening is that there is a mixup of traffic sele

Re: [Swan-dev] clarify ikev2_ts_r_desc length field

2020-03-02 Thread Paul Wouters
> On Mar 2, 2020, at 15:57, Andrew Cagney wrote: > >> On Mon, 2 Mar 2020 at 09:22, D. Hugh Redelmeier wrote: >> >> I don't think that the logging change is good. >> >> 1. (almost?) all lengths in IKE are the length of the whole structure. >> By changing logging for only one, you raise more

Re: [Swan-dev] clarify ikev2_ts_r_desc length field

2020-03-02 Thread Andrew Cagney
On Mon, 2 Mar 2020 at 09:22, D. Hugh Redelmeier wrote: > > I don't think that the logging change is good. > > 1. (almost?) all lengths in IKE are the length of the whole structure. >By changing logging for only one, you raise more questions than you >answer. "ft_len" means "length of the

Re: [Swan-dev] Set keyingtries to 1 for Opportunistic Encryption connections

2020-03-02 Thread Paul Wouters
On Mon, 2 Mar 2020, D. Hugh Redelmeier wrote: Why would keyingtries have been set to something other than 1? Either it has the default (0) or something explicitly set by the user (which could be 0). Indeed. The cases we encounter typically have the default. It seems to me that we should l

Re: [Swan-dev] Set keyingtries to 1 for Opportunistic Encryption connections

2020-03-02 Thread D. Hugh Redelmeier
| commit 21100cee5f207c24ee55ad6c612a84a6140ba583 | Author: Paul Wouters | Date: Sun Mar 1 21:46:17 2020 -0500 | | IKEv2: Set keyingtries to 1 for Opportunistic Encryption connections. | | We cannot have unlimited keyingtries for Opportunistic, or else we gain | infinite partia

Re: [Swan-dev] clarify ikev2_ts_r_desc length field

2020-03-02 Thread Paul Wouters
I will recheck. I thought this was one exceptional when I looked at it. If not, I will change it back. Paul Sent from my iPhone > On Mar 2, 2020, at 09:22, D. Hugh Redelmeier wrote: > > I don't think that the logging change is good. > > 1. (almost?) all lengths in IKE are the length of the w

Re: [Swan-dev] clarify ikev2_ts_r_desc length field

2020-03-02 Thread D. Hugh Redelmeier
I don't think that the logging change is good. 1. (almost?) all lengths in IKE are the length of the whole structure. By changing logging for only one, you raise more questions than you answer. "ft_len" means "length of the whole structure". 3. The result is quite wordy. I suggest that i