Tried it. It reads well when what is being impaired is a boolean vis: if (IMPAIR(send_bogus_isakmp_flag)) { hdr.isa_flags |= ISAKMP_FLAGS_RESERVED_BIT6; }
however, think it breaks down for more complex values. For instance, this would look decidedly weird iv IMPAIR() was used. fixup->impair = (impair.v1_hash_exchange == exchange ? impair.v1_hash_payload : SEND_NORMAL); So I suspect we're left with impair.send_bogus_isakmp_flag et.al. On Wed, 1 Apr 2020 at 19:59, Paul Wouters <p...@nohats.ca> wrote: > Works for me > > Sent from my iPhone > > On Apr 1, 2020, at 19:38, Andrew Cagney <andrew.cag...@gmail.com> wrote: > > > > > On Wed, 1 Apr 2020 at 18:10, Antony Antony <ant...@phenome.org> wrote: > >> On Mon, Mar 30, 2020 at 12:07:17PM -0400, Andrew Cagney wrote: >> > I'm cleaning up the impair code. >> > >> > Internally, the old style #define names are in upper case vis: >> > #define IMPAIR_REPLAY_FORWARD ... >> > and >> > IMPAIR(REPLAY_FORWARD) >> > while the new ones (that take parameters) are in lower case vis: >> > extern enum send_impairment impair_ike_key_length_attribute >> > I've merged the two but preserved the names. >> > >> > Should the names be made consistent? >> >> that would be great. go for it. >> >> > so how about: > IMPAIR(replay_forward) > ? > > >> thanks, >> -antony >> > _______________________________________________ > Swan-dev mailing list > Swan-dev@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev > >
_______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev