[Swan-dev] encrypted informational message when in state R1?
Antony Antony
antony at phenome.org
Wed Feb 18 23:18:21 EET 2015
Hugh,
I wonder if you noticed , all lievenss and delete messages arrive when the state is in R2.
.story = "R2: process INFORMATIONAL",
.state = STATE_PARENT_R2,
.next_state = STATE_PARENT_R2,
I think we need one for this. However, in current implemention the message is droped by ikev2_decrypt_msg
we could have different procssing function for the R1 -> R1
.story = "R1: process INFORMATIONAL",
.state = STATE_PARENT_R1,
.next_state = STATE_PARENT_R1,
.processor = drop_encrypted_informational_ikev2
On Wed, Feb 18, 2015 at 03:57:31PM -0500, D. Hugh Redelmeier wrote:
> | From: Andrew Cagney <andrew.cagney at gmail.com>
>
> | I'm trying to understand this:
> |
> | /* Informational Exchange */
> | { .story = "R1: process INFORMATIONAL",
> | .state = STATE_PARENT_R1,
> | .next_state = STATE_PARENT_R1,
>
> I don't understand this. Maybe I will later.
>
> Why would there be support for an informational when in
> STATE_PARENT_R1 and not when in STATE_PARENT_R2?
>
> Is this a typo?
>
> The only states that support ISAKMP_v2_INFORMATIONAL in the current
> code are STATE_PARENT_I2, STATE_PARENT_R1, and STATE_PARENT_I3, in
> that order. Sure feels like a typo.
>
>
> I continue to think that these are terrible state names.
>
> STATE_PARENT_R1 => STATE_INIT_R
> STATE_PARENT_R2 => STATE_AUTH_R
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
>
More information about the Swan-dev
mailing list