Re: [Swan-dev] why, in ah-pluto-01, does libreswan emit an ESP proposal

2018-10-04 Thread Paul Wouters
On Thu, 4 Oct 2018, Andrew Cagney wrote: It turns out that, when phase2=ah (i.e., POLICY_AUTHENTICATE), IKEv1's defaults, since before the start of time have been: static struct db_prop_conj ah_props[] = { { AD(ah_pc) }, #ifdef SUPPORT_ESP_NULL { AD(espnull_pc) } #endif }; I see it

Re: [Swan-dev] why, in ah-pluto-01, does libreswan emit an ESP proposal

2018-10-04 Thread Andrew Cagney
It turns out that, when phase2=ah (i.e., POLICY_AUTHENTICATE), IKEv1's defaults, since before the start of time have been: static struct db_prop_conj ah_props[] = { { AD(ah_pc) }, #ifdef SUPPORT_ESP_NULL { AD(espnull_pc) } #endif }; I.e., in addition to AH, emit an ESP proposal with

Re: [Swan-dev] why, in ah-pluto-01, does libreswan emit an ESP proposal

2018-10-04 Thread Andrew Cagney
> In the current code NEXT in the first payload is patched up so the > second proposal is be visible. Am trying east:phase2=esp Yea, that went a little too well :-( I'm testing the attached to mitigate this new problem, hopefully it goes ok and can push. I think getting rid of the extra payload

[Swan-dev] why, in ah-pluto-01, does libreswan emit an ESP proposal

2018-10-04 Thread Andrew Cagney
For instance, http://testing.libreswan.org/results/testing/v3.22-1007-g86105a8-master/ah-pluto-01/ (its seemingly being doing it for a while): west.conf has: conn westnet-eastnet-ah also=west-east-base also=westnet also=eastnet phase2=ah but in west's logs I see: |