(RDMLX) No CIK value - randomly happening to end users

[Mark_Dale]

We investigated this and found that the problem seemed to be restricted to
1) iOS7
2) Apache on iSeries
3) SSL mode

The solution seems to be to:

Administer the HTTP server on the iSeries:

http://nnn.nnn.nnn.nnn:2001/HTTPAdmin

Change the SSL version to negotiate to: SSL Version 3.0 only

Stop and start the webserver

ENDTCPSVR SERVER(*HTTP) HTTPSVR(XXXXXXXX)
STRTCPSVR SERVER(*HTTP) HTTPSVR(XXXXXXXX)

[jimoreilly]

This CIK error has started to reappear for those end users who have upgraded their devices to iOS8.

Everything else has remained the same - Apache on iSeries with SSL turned on.

We have the Apache setting installed as requested, working for iOS7 devices.

Is there a different setting needed to handle iOS8 on the Apache side?

[MarkDuignan]

It’s possible Apple have changed their SSL algorithm negotiations again and the IBM SSL routines on your IBM i cannot properly handle that all of the time.
It’s also possible, because the “No CIK” message is a generic catch all at the end of a transaction, this is being caused by something different.
What would help us to resolve this most quickly are:
- any indication you have of a usage pattern that can trigger this issue.
- a QPJOBLOG job log from a failed server job.
- any X_ERR.log file that can be found
- a client side log ( which I understand might be impossible to collect if the problem is random)
Please send anything you can collect via support.

[jimoreilly]

Problem is repeatable with attached RDMLX part.

Program loads tables as buttons are pushed B1 thru B5 (select in order, transmission size increases with each one). With SSL on under iOS8, iSeries Apache - program fails on B4. With SSL off, program runs successfully.

[MarkDuignan]

One question – this is just iSO8 – they have not applied the now withdrawn iOS8.01 version?

This issue may be the same as last time. My understanding is that when the SSL connection is opened the iOS SSL software and the Apache SSL software negotiate about which encryption algorithm they will use. Unfortunately sometimes they agree on using an algorithm that one side does not implement correctly and so data gets randomly corrupted.

The iOS7 problem apparently happened because iOS7 supported a new set of algorithms that iOS6 never used. It was never clear whether the problem with iOS7 was based in iOS or in Apache.

It’s possible that the this has the same solution as last time – controlling which algorithm set Apache will decide to use.

We will try to reproduce.

[jimoreilly]

users are using iOS8 original without either of the two new patches.

[MarkDuignan]

What version of the operating system are you using on your IBM i server?

[jimoreilly]

IBM iSeries on V7R1M0

[MarkDuignan]

We have managed to reproduce this. It will have to be handled through LANSA support from now on.