On Thu, 7 Jan 2016, Andrew Cagney wrote:
It seems to be feeding SHA1 crud found on the stack?
I changed it to sha256 recently but yes.
For EH/ESP, there is also:
ipsec_spi_t get_ipsec_spi(ipsec_spi_t avoid, int proto, const struct
set_text_said(text_said, &sr->this.host_addr, 0, proto);
if (kernel_ops->get_spi != NULL) {
Looks like only netlink has one. So we use userland otherwise. Except
win2k, which has one but returns 0, which is very odd. I guess we should
just get rid of kernek_win2k.c :P
For IKEv2, they need to be non-zero, given the odds of that are low,
I've been using an initial hack:
Why are you looking at spi cookies at all?
I've been working on the assumption that IKEv2 will have its own SPI
generators (at least for AH/ESP / CHILD_SA).
Why does it need a different one?
And please consider going further, and s/icookie/initiator_spi/ et.al.
so that it makes reading the code from an IKEv2 much easier.
Agreed but its weird because these appear in the IKE header, so are
shared between IKEv1 and IKEv2, and IKEv1 calls it cookies not SPI
numbers.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
