Hi Tobias, On Saturday 29 September 2012 02:04 AM, Tobias Brunner wrote: > 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:
I learnt this now. >> 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. I had a look at this code now. Yes, your fix solves this problem. Thanks both of you for your attention on here. Regards, Gowri Shankar > Regards, > Tobias > > [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=48651d8d > _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users