[strongSwan-dev] TLS negotiation failing on power pc 64

[Avesh Agarwal]

Hi Martin,

I tested your patch on ppc64 and it works as expected. I still think that
resetting record "type" to an initial/default value before passing it to
build function in the while loop in tls.c would be better than just passing
an uninitialized or without resetting to an initial value. My suggestion
would be to have both fixes in place so that in future, if something gets
changed around this code, it does not go unnoticed or causes mysterious
failures. Just my 2 cents.

Anyway thanks for your help.
Regards
Avesh

On Thu, Jan 8, 2015 at 9:10 AM, Avesh Agarwal <avesh.ncsu at gmail.com> wrote:

> Hi Martin,
>
> 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.
>
> Anyway, I will test your patch and let you know.
> Thanks
> Avesh
>
>
> On Thu, Jan 8, 2015 at 5:19 AM, Martin Willi <martin at strongswan.org>
> wrote:
>
>> Hi Avesh,
>>
>> > It turns out that unintialization of record type in the while loop
>> during
>> > building of TLS records in tls.c is wreaking havoc on ppc64. I have
>> come up
>> > with a preliminary patch for upstream review
>>
>> Thanks for your in-depth analysis and your patch. There is definitely a
>> bug while building those records.
>>
>> I've tried to address this in a slightly different way. The upper layers
>> return NEED_MORE if any record has been created. So we actually should
>> check for that return type before querying the type output parameter.
>>
>> Please try the attached patch; I don't have a PPC64 architecture at
>> hand, so your feedback is much appreciated.
>>
>> Regards
>> Martin
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20150108/ede0a5ce/attachment.html>