<div dir="ltr"><div><div><div><div>Hi Martin,<br><br></div>Thanks. I will test the patch but I am not sure whether it can solve the issue. Because in tls.c, while building records, the value of type should be set to 0 in every invocation in the while loop which is not happening. If type is not reset to 0, it will retain its previous value, and will cause erroneous (*type == ) to be true later leading to failed negotiation. ppc64 being a stricter architecture caught this whereas x86/64 did not. <br></div><br></div>Anyway, I will test your patch and let you know.<br></div>Thanks <br>Avesh<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 8, 2015 at 5:19 AM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Avesh,<br>
<span class=""><br>
> It turns out that unintialization of record type in the while loop during<br>
> building of TLS records in tls.c is wreaking havoc on ppc64. I have come up<br>
> with a preliminary patch for upstream review<br>
<br>
</span>Thanks for your in-depth analysis and your patch. There is definitely a<br>
bug while building those records.<br>
<br>
I've tried to address this in a slightly different way. The upper layers<br>
return NEED_MORE if any record has been created. So we actually should<br>
check for that return type before querying the type output parameter.<br>
<br>
Please try the attached patch; I don't have a PPC64 architecture at<br>
hand, so your feedback is much appreciated.<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
<br>
<br>
</font></span></blockquote></div><br></div>