Hi Gowri, > Here, this payload is of 9 bytes as payload length also mentions > correctly. But, my doubt is on notification data which is 2D. > It is always 2D even if I set notification data on sending node (say 01).
This value has nothing to do with the notification data, but with the payload type of the unsupported payload. In your case it should be 01, as can be seen here: > Sep 28 07:08:16 16[ENC] parsing (1) payload, 178 bytes left When starting to parse the unknown payload the type is just printed as number. So you are right the value (2D) is incorrect. The attached patch and [1] should fix this issue for 4.6.4 and 5.0.x, respectively. The problem was that the UNSUPPORTED_CRITICAL_PAYLOAD notify would always contain the payload type of the last payload in the message (in your case TSr) instead of the actually unsupported critical payload. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=48651d8d
diff --git a/src/libcharon/sa/ike_sa.c b/src/libcharon/sa/ike_sa.c index 07d1938..2e24571 100644 --- a/src/libcharon/sa/ike_sa.c +++ b/src/libcharon/sa/ike_sa.c @@ -1237,6 +1237,7 @@ METHOD(ike_sa_t, process_message, status_t, DBG1(DBG_ENC, "payload type %N is not supported, " "but its critical!", payload_type_names, type); status = NOT_SUPPORTED; + break; } } enumerator->destroy(enumerator);
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
