On Wed, 24 Feb 2016, Andrew Cagney wrote:

I've a TODO item sitting here asking that proposals always be logged
(it makes diagnosing a failing connection easier).

Yes, we should.

The current code will log the proposal if nothing is chosen (this is
still progress since the old code simply logged "no proposal chosen"
:-), however it isn't ideal.  The fix is "easy", but like the comment
says:

               /*
                * For the moment don't libreswan_log() this as it
                * gets written to the console, altering output, and
                * causing test noise.
                */

We can use libreswan_log(), but it would be best to check for
opportunistic and suppress if conn is oppo and no DBG_OPPO was set.

But wait there's more; and the real reason I put this into the
too-painful basket.  The output isn't exactly pretty:

proposals:  
IKE:AES_GCM_C(20)_256,PRF_HMAC_SHA1(2),PRF_HMAC_SHA2-256(5),AUTH_NONE(0),OAKLEY_GROUP_MODP2048(14),OAKLEY_GROUP_MODP4096(16),OAKLEY_GROUP_MODP8192(18)[first-match]
IKE:AES_GCM_A(18)_128,PRF_HMAC_SHA1(2),PRF_HMAC_SHA2-256(5),AUTH_NONE(0),OAKLEY_GROUP_MODP2048(14),OAKLEY_GROUP_MODP4096(16),OAKLEY_GROUP_MODP8192(18)
IKE:AES_CBC(12)_256,PRF_HMAC_SHA1(2),PRF_HMAC_SHA2-256(5),PRF_AES128-XCBC(4),AUTH_HMAC_SHA1_96(2),AUTH_HMAC_SHA2_256_128(12),AUTH_AES_XCBC_96(5),OAKLEY_GROUP_MODP1536(5),OAKLEY_GROUP_MODP2048(14)
IKE:AES_CBC(12)_128,PRF_HMAC_SHA1(2),PRF_HMAC_SHA2-256(5),PRF_AES128-XCBC(4),AUTH_HMAC_SHA1_96(2),AUTH_HMAC_SHA2_256_128(12),AUTH_AES_XCBC_96(5),OAKLEY_GROUP_MODP1536(5),OAKLEY_GROUP_MODP2048(14)

notice how some algorithms have OAKLEY_GROUP_ as a prefix yet others,
such as AES_GCM_C, do not.  This inconsistency stems from the enum
code and calls like:

which print what ever the enum table defines.  When the prefix isn't
desired arbitrary bits get stripped off:

       strip_prefix(enum_name(&ikev2_trans_type_names, type), "TRANS_TYPE_");

and this bubbles up to the log file.

While I can add to the hacks to fix this, I suspect it would be better
to just have the enum code handle it.

That could but only if the prefix stripped would always be the same. In
the context of PRF we could strip PRF_HMAC_, but on the lines quoted
above, we need to keep something to distinguish PRF from AUTH, so one
would likely want to strip only "_HMAC" so you see PRF_SHA2 or
AUTH_SHA2. OAKLEY_GROUP_ can always be stripped because those names
don't clash and self-explanatory even without the prefix.

Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev

Reply via email to