design. develop. deploy.

SDK/J

AAA initialization issue - City Of Tacoma

Submitted by sebestyen.bart… on
Incident Properties
Product:
SDK/J
Category:
End User Issue
End User - Customer Name:
City Of Tacoma
Origin of Incident:
End User Customer Name
Application Type:
Embedded Application (SDK/J)
Application Version Number:
5.4.30824.4
Server Name(s):
ShareScan server
Server Version Number:
5.4.40521.4590
Question
Incident Question:

cccccHi,

We have a customer issue where Single-SignOn does not work using AAA between PCC 4.2.3.017 and ShareScan 5.4.30824.4. Analyzing the logs resulted in us thinking it is either a configuration issue or an issue with the AAA library itself, because the listener fails to initialize, but we've exhausted our knowledge of the common things to check, which includes suggesting to check the installation order (first PCC then ShareScan) and turning of SSL on the device.

The latest log we got from 08.09 (131_191_212_209_(MP_C4504).log) shows the following issue:

We try to start to initialize the AAA listener in the ShareScan client in line 6615 (14:44:35:008), and then it times out internally in the AAA library in line 6652 (14:45:51:244), then it retries 4 times but fails all attempts and says it will give up trying in line 6751 (14:49:36:444):

 

[14:44:35:008] [InitXletThread.run()] Initialize AAA integrated authentication

...

[14:45:51:244] [INFO] HttpMethodDirector - I/O exception (java.net.ConnectException) caught when processing request: Operation timed out

[14:45:51:245] [DEBUG] HttpMethodDirector - Operation timed out <java.net.ConnectException: Operation timed out>java.net.ConnectException: Operation timed out

                at java.net.PlainSocketImpl.socketConnect(Native Method)

                at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:382)

                at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:241)

                at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:228)

                at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:365)

                at java.net.Socket.connect(Socket.java:529)

                at java.net.Socket.connect(Socket.java:479)

                at java.net.Socket.<init>(Socket.java:375)

                at java.net.Socket.<init>(Socket.java:247)

                at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:79)

                at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:121)

                at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706)

                at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386)

                at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)

                at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)

                at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)

                at com.ricoh.auth.Authenticator.a(Authenticator.java)

                at com.ricoh.auth.Authenticator.b(Authenticator.java)

                at com.ricoh.auth.Authenticator.a(Authenticator.java)

                at com.ricoh.auth.Authenticator.add(Authenticator.java)

                at com.ecopy.ssop.ShareScanOP$InitXletThread.defendedRun(Unknown Source)

                at com.ecopy.ssop.ShareScanOP$InitXletThread.run(Unknown Source)

...

[14:48:21:373] [INFO] HttpMethodDirector - Retrying request

[14:48:21:374] [TRACE] HttpMethodDirector - Attempt number 4 to process request

[14:48:21:375] [TRACE] HttpConnection - enter HttpConnection.open()

[14:48:21:376] [DEBUG] HttpConnection - Open connection to localhost:8080

[14:49:36:428] [TRACE] HttpConnection - enter HttpConnection.closeSockedAndStreams()

[14:49:36:440] [DEBUG] HttpMethodDirector - Closing the connection.

[14:49:36:441] [TRACE] HttpConnection - enter HttpConnection.close()

[14:49:36:442] [TRACE] HttpConnection - enter HttpConnection.closeSockedAndStreams()

[14:49:36:444] [DEBUG] HttpMethodDirector - Method retry handler returned false. Automatic recovery will not be attempted

[14:49:36:445] [TRACE] HttpConnection - enter HttpConnection.releaseConnection()

[14:49:36:447] [DEBUG] HttpConnection - Releasing connection back to connection manager.

the latest log we got from 08.09 (131_191_212_209_(MP_C4504).log) you can point to the issue:

We try to start to initialize the AAA listener in the ShareScan client in line 6615 (14:44:35:008), and then it times out internally in the AAA library in line 6652 (14:45:51:244), then it retries 4 times but fails all attempts and says it will give up trying in line 6751 (14:49:36:444):

 

[14:44:35:008] [InitXletThread.run()] Initialize AAA integrated authentication

...

[14:45:51:244] [INFO] HttpMethodDirector - I/O exception (java.net.ConnectException) caught when processing request: Operation timed out

[14:45:51:245] [DEBUG] HttpMethodDirector - Operation timed out <java.net.ConnectException: Operation timed out>java.net.ConnectException: Operation timed out

                at java.net.PlainSocketImpl.socketConnect(Native Method)

                at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:382)

                at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:241)

                at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:228)

                at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:365)

                at java.net.Socket.connect(Socket.java:529)

                at java.net.Socket.connect(Socket.java:479)

                at java.net.Socket.<init>(Socket.java:375)

                at java.net.Socket.<init>(Socket.java:247)

                at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:79)

                at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:121)

                at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706)

                at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386)

                at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)

                at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)

                at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)

                at com.ricoh.auth.Authenticator.a(Authenticator.java)

                at com.ricoh.auth.Authenticator.b(Authenticator.java)

                at com.ricoh.auth.Authenticator.a(Authenticator.java)

                at com.ricoh.auth.Authenticator.add(Authenticator.java)

                at com.ecopy.ssop.ShareScanOP$InitXletThread.defendedRun(Unknown Source)

                at com.ecopy.ssop.ShareScanOP$InitXletThread.run(Unknown Source)

...

[14:48:21:373] [INFO] HttpMethodDirector - Retrying request

[14:48:21:374] [TRACE] HttpMethodDirector - Attempt number 4 to process request

[14:48:21:375] [TRACE] HttpConnection - enter HttpConnection.open()

[14:48:21:376] [DEBUG] HttpConnection - Open connection to localhost:8080

[14:49:36:428] [TRACE] HttpConnection - enter HttpConnection.closeSockedAndStreams()

[14:49:36:440] [DEBUG] HttpMethodDirector - Closing the connection.

[14:49:36:441] [TRACE] HttpConnection - enter HttpConnection.close()

[14:49:36:442] [TRACE] HttpConnection - enter HttpConnection.closeSockedAndStreams()

[14:49:36:444] [DEBUG] HttpMethodDirector - Method retry handler returned false. Automatic recovery will not be attempted

[14:49:36:445] [TRACE] HttpConnection - enter HttpConnection.releaseConnection()

[14:49:36:447] [DEBUG] HttpConnection - Releasing connection back to connection manager.

 

The issue was escalated to RCL by the Ricoh partner and we were asked to open an RiDP ticket as well. Do you have any suggestions on further configuration items that might affect the ability of AAA to initialize?

Thank you,

Sebestyen Bartha

 

 



ModelInfo for latest model 2019 Fall

Submitted by scott.walker@i… on
Incident Properties
Product:
SDK/J
Category:
End User Issue
End User - Customer Name:
Wells Fargo
Origin of Incident:
End User Customer Name
Application Type:
Embedded Application (SDK/J)
Application Version Number:
1.4.6
Application Build Number:
0
Server Name(s):
Encapture
Server Version Number:
3.14
Question
Incident Question:

Could you give me the sdkj modelinfo pdf documents for the latest models?
At least, the IM 600SR, but any released around the same time as well, would be helpful.

Thanks,
Scott

Application stops after a period of time

Submitted by fye on
Incident Properties
Product:
SDK/J
Category:
End User Issue
End User - Customer Name:
Milner Document Produts
Origin of Incident:
End User Customer Name
Application Type:
Embedded Application (SDK/J)
Application Version Number:
6.3.9a
Server Name(s):
N/A
Server Version Number:
N/A
Question
Incident Question:

We have a customer who is running PCSD on an MP 305+. After a period of time the application stops running and looking at the Extended Feature Info the applicaiton is listed with a status of Stop. Looking through the logs we don't see any errors that would indicate the application has crashed or shutdown for any reason. The logs we were able to gather have been attached to this case.

Support for MIPS cpu devices running custom firmware for TLS/AES support

Submitted by richard.shim@t… on
Incident Properties
Product:
SDK/J
Category:
Development
How would you categorize this Development request?:
Runtime Issue
Origin of Incident:
Development/Lab
Application Type:
Embedded Application (SDK/J)
Application Version Number:
7.7.5.57
Question
Incident Question:

Ricoh reported to Kofax a problem with the Kofax Ricoh Combined client when running on MIPS based devices that are running customer firmware and custom java to support more secure versions of TLS and AES encryption. When trying to gather information on this, we received the following from Ricoh in order to assist us in understanding the problem (unfortunately I don't know who the person at Ricoh was, but I can get that info).

######################################

I went over  to PTEC today and tested  a MP C3003
 
I reproduced the problem PTEC reported some months ago.   The problem occurs on MIPS Model MFP’s when using the custom System firmware and the custom Java that supports TLS/AES  encryption.    I’m pretty sure the problem is being caused from the way Ricoh is moving around the memory with the custom system firmware.    RIDP should be able to assist with this.  They may have to go back to RCL.   
 
Steps for test on MP C3003
1. installed the custom system firmware   (D1475575C_CS13737)
2. Installed custom TLS JAVA (11.39.66)  and CAC 3.2.2
3. Configured CAC ,  confirmed could login and  working properly
4. Pushed Nuance client to C3003  (ver 7.7.5.57 ) Autostore
5. Logged in with CAC and pressed the Nuance button on screen, 
6. Error occurred when pressing the Nuance button- “Failed to connect to Server:DRS”
 
Rlog of device Startup, cac login and pressing the Nuance button
Image of error message after pressing the Nuance button
Config_SMC report of tested C3003 MFP
Custom System Firmware for C3003 ,  Custom TLS Java RXOP file.
 
You questions 
 
We are told the ESA client doesn't work with the new firmware, but this is unclear. What behavior is failing with Output Manager (OM) on the new firmware?
- Is OM unable to log in?     NO
- Is OM unable to release print jobs? NO 
- Is the OM screen displaying an error message or displaying nothing?   After cac login ,  press Nuance button and error message “Failed to connect to Server:DRS”
- Can we get screen shots or a video of the issue?   Screen shot attached 
 
List of all Kofax software products (and versions) affected by this problem?    Push client to device 
- Nuance Client –  tested version 7.7.5.57   in PTEC 
 
May we get rlogs?   
                      Logs of Device startup , cac login and pressing the Nuance button       
 
Please list the changes made to the new firmware?   Custom system firmware-  Memory allocation was moved to accommodate Higher TLS /AES  Java support.  
- Were changes made in the security packages?    None
- Were changes made in the communications packages?  None
- Were other changes made not related security and communications?  no
 
Somehow backwards compatibility was broken and Ricoh software (StreamlineNX, etc.) was updated to work around the issue  n/a
- How was backwards compatibility broken   n/a
- How was it resolved in the Ricoh software? i.e. what changes were made to StreamlineNX to work around the issues with the firmware?   n/a
- We would like to try and reproduce the issue internally, if allowed   
 
How do we determine which models would be affected by the new firmware?
- How do we determine which devices are MIPS? 
MIPS  refers to the type of CPU the model MFP has. CPU types are either MIPS or x86  on Ricoh Models. 
                The MiPS models require custom system firmware to run the Higher TLS java. The x86 models do not. This problem only affects the MIPS models using the custom system firmware.
                                                                                        
May we have the firmware to install on a MIPS device?
-Yes    I have attached the firmware for the C3003  If you need any other models let me know.
################################

 

 

We do have an MP C3003 in our office to further test, but we don't know how to confirm it has a MIPS CPU. Can we assume all MP C3003 are MIPS devices?

From our review of the logs, our developer here had the following comments:

#############################

There are TLS and network errors in the logs. Given the reported custom changes to Java for TLS, these problem are perhaps not unexpected.
 
The logs for the client show it is trying to contact DRS and a TLS error is logged:
"Failed to send request (5): Ciphertext is too large in received TLS record."
This could indicate that custom TLS stack is unable to handle encrypted data over a certain size, possibly because they specified a non standard and too small max-packet size. It could also mean that they tried to mimic TLSv1.3 memory allowance, which is much lower than TLSv1.2.
 
Additionally, we saw encryption/decryption errors, which might be related:
librcprov.so CipherCore.cpp rsaCipherInit Line:284 R_CR_encrypt_init()/R_CR_decrypt_init() err. ret = [10008]
librcprov.so CipherCore.cpp Java_jp_co_ricoh_dsdk_crypto_impl_CipherCore_nativeCipherCoreInit Line:469 R_CR_encrypt/decrypt_init() err[-1].
 
 
As well as exception when trying to trying to get the device IP address, which doesn't seem related to TLS
java.net.UnknownHostException: at java.net.InetAddress.getLocalHost(InetAddress.java:1354).
This happens when we are trying to determine the IP address of the device.
 
 
In summary, given they made changes to Java around TLS memory allocation and we are seeing TLS errors about memory, Ricoh really needs to provide more information about what changes they actually made. We can help with the investigation but they need to provide more info.
###############
 
 
 
When this was originally reported to us, we were told that perhaps Ricoh's own applications, i.e. StreamlineNX, also had issues on the MIPS devices with the custom firmware and they were updated to fix or workaroud this issues. Do you know what changes were made?
 
 
Joe Gormley is aware that we would be creating this ticket, so he may have further questions for us. Please let us know.
 
Thanks,
Richard

Request for a 60-day beta signature for SafeCom Go Ricoh *06.10

Submitted by sebestyen.bart… on
Incident Properties
Product:
SDK/J
Category:
Request
How would you categorize this Request?:
Signature (Beta, Demo, Production)
Origin of Incident:
Development/Lab
Application Type:
Embedded Application (Android App)
Application Version Number:
030*06.10
Question
Incident Question:

Dear Support,

We would like to request another new 60-days beta signature for this build.

As before, although the previous beta signature has not expired yet, the partner mentioned that the customer would be confident to have a new extended beta in place before the previously signed one expires. Our build is undergoing certification at the same time, so we should be able to replace these beta builds with a released solution soon.

Attaching the previously signed beta agreement.

Thank you in advance!

Sebestyen

AAA Provider and AAAauthentication do not work on some MFPs

Submitted by ngocanh.le@tun… on
Incident Properties
Product:
SDK/J
Category:
End User Issue
Origin of Incident:
Development/Lab
Application Type:
Embedded Application (Android App)
Application Version Number:
5.0.0
Server Name(s):
KFS 4.1.1
Server Version Number:
KFS 4.1.1
Question
Incident Question:

Hello

Regarding a previous issue about SSO does not work in Kofax client + Equitrac via AAA libs. The customer has more than 100 Ricoh MFPs, and SSO does not work on some devices.

We have deployed AAASMBClientSampleXlet tool on an issue device, and downloaded device logs (attached).

After analyzed the device logs I see the problem that both Equitrac and AAASMBClientSampleXlet are refused connection when registering listener.

The log file LogTrace\G707M231231\watching\20190418_102038_1009.gz says: At 10:20:30, EQuitract cannot register AAA provider service. Anh at 10:20:42 AAASMBClientSampleXlet cannot register AAA listerner with aaa-provider, all the cause are "Connection refused"

2019-04-18T10:20:59.779+0200: [GC 18957K->15642K(65152K), 0.0034570 secs]
[stderr] java.net.ConnectException: Connection refused
[stderr]     at java.net.PlainSocketImpl.socketConnect(Native Method)
.....
[stderr]     at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1032)
[stderr]     at com.ricoh.auth.provider.AAAServiceManager.c(AAAServiceManager.java)
[stderr]     at com.ricoh.auth.provider.AAAServiceManager.registerHttpServices(AAAServiceManager.java)
[stderr]     at com.equitrac.esa.servlet.EQAppletActivator.initializeRicohAAAImpl(EQAppletActivator.java:289)
[stderr]     at com.equitrac.esa.servlet.EQAppletActivator.start(EQAppletActivator.java:172)
[stderr]     at org.knopflerfish.framework.BundleImpl$1$1.run(BundleImpl.java:358)
2019-04-18T10:21:00.324+0200: [GC 18970K->15565K(65152K), 0.0044890 secs]

18.04.2019 10:20:42 org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
INFO: Retrying request
[stdout] aaa-client could not register with authentication provider
[stderr] org.apache.commons.httpclient.HttpException: AAA: invoke("register",...) failed: Connection refused
[stderr]     at com.ricoh.auth.Authenticator.a(Authenticator.java)
[stderr]     at com.ricoh.auth.Authenticator.c(Authenticator.java)
[stderr]     at com.ricoh.auth.Authenticator.a(Authenticator.java)
[stderr]     at com.ricoh.auth.Authenticator.add(Authenticator.java)
[stderr]     at com.ricoh.auth.AAASmbFile.<init>(AAASmbFile.java)
[stderr]     at AAASMBClientSampleXlet.initXlet(AAASMBClientSampleXlet.java:328)
[stderr]     at jp.co.ricoh.dsdk.osgi.service.multiXletManager.XletManager.handleRequest(Unknown Source)
[stderr]     at jp.co.ricoh.dsdk.osgi.service.multiXletManager.XletStateQueue.dispatchEvents(Unknown Source)
[stderr]     at jp.co.ricoh.dsdk.osgi.service.multiXletManager.XletStateQueue$1.run(Unknown Source)
[stderr]     at java.lang.Thread.run(Thread.java:682)
[stderr] Caused by: java.net.ConnectException: Connection refused

 

Tthe log file LogTrace\G707M231231\watching\20190418_084543_0989.gz says Kofax client gets the same problem "Connection refused"

[stdout] [SDK_P_ACR__]new AuthContext 34080768
[stdout] aaa-client could not register with authentication provider
[stderr] org.apache.commons.httpclient.HttpException: AAA: invoke("register",...) failed: Connection refused
[stderr]     at com.ricoh.auth.Authenticator.a(Authenticator.java)
[stderr]     at com.ricoh.auth.Authenticator.c(Authenticator.java)
[stderr]     at com.ricoh.auth.Authenticator.a(Authenticator.java)
[stderr]     at com.ricoh.auth.Authenticator.add(Authenticator.java)
[stderr]     at com.kofax.des.mfp.client.ricoh.DeviceAAAListener.initInstance(DeviceAAAListener.java:33)
[stderr]     at com.kofax.des.mfp.client.ricoh.MFPClient.initXlet(MFPClient.java:222)
[stderr]     at jp.co.ricoh.dsdk.osgi.service.multiXletManager.XletManager.handleRequest(Unknown Source)
[stderr]     at jp.co.ricoh.dsdk.osgi.service.multiXletManager.XletStateQueue.dispatchEvents(Unknown Source)
[stderr]     at jp.co.ricoh.dsdk.osgi.service.multiXletManager.XletStateQueue$1.run(Unknown Source)
[stderr]     at java.lang.Thread.run(Thread.java:682)
[stderr] Caused by: java.net.ConnectException: Connection refused

 

Could you please shed some light to continue troubleshoot this?

Thank you

Ngoc

TLS and chiphers limitations of JVM of not Android Ricoh Devices

Submitted by sebestyen.bart… on
Incident Properties
Product:
SDK/J
Category:
Development
How would you categorize this Development request?:
Runtime Issue
Origin of Incident:
Development/Lab
Application Type:
Embedded Application (Android App)
Application Version Number:
6.0
Question
Incident Question:

For security reasons some users want to use strict network policies and set TLS1.2 as protocol with a restricted type of chiphers on server side. Unfortunatelly the java vm in (not  Android) Ricoh devices supports only TLS1.0 and older chiphers (listed in the attached document)
We found that only the JVM of IM C2000 from our devices supports TLS1.2

Is there any way to upgrade the criptographic part of the jvm for not Android devices?

Ricoh Maintenance Certification Request

Submitted by dhunt@opentext.com on
Incident Properties
Product:
SDK/J
Category:
Request
How would you categorize this Request?:
Maintenance Signature
Origin of Incident:
Development/Lab
Application Type:
Embedded Application (Android App)
Application Version Number:
1.0
Product ID's:
34092545
Question
Incident Question:

I've attached a zip file that contains the updated .jar file that requires maintenance signing for general release and the associated .dalp file.

 

1. List of supported platforms : SDK/J Version 10.x, 11.x, 12.x

2. Supported Display Panels: uWVGA, WVGA

3. The only modified .jar file is RightFax.jar

4. .dalp file version is 11.0.7

Overview of bug fixes: 

1. RF-24128 - Previously, ad hoc recipients that were added to the phonebook appeared in the phonebook list as well as the recipient list. This was confusing because it allowed the same recipient to be added twice. Now, phonebook contacts are removed from the list as they are added to the recipient list.

2. RF-24132 - A recent modification to the RightFax Web API caused the default coversheet to not be selected by default. The Ricoh application was modified to accomodate this change to the API.

No release notes for these fixes are included with RightFax.

SafeCom beta signature request #2

Submitted by sebestyen.bart… on
Incident Properties
Product:
SDK/J
Category:
Request
How would you categorize this Request?:
Signature (Beta, Demo, Production)
End User - Customer Name:
SCC MPDS
Origin of Incident:
End User Customer Name
Application Type:
Embedded Application (Android App)
Application Version Number:
500.3006
Question
Incident Question:

Hi,

We would like to request a new beta signature for this build.

Although the previous beta signature has not expired yet, the partner reached out to us, and mentioned that personnel responsible for installing the new beta would be out of office when the current beta expires, not being able to support the customer, so they would like to have an expiration time that falls outside this period. Also, is it possible to get a longer than 30 day period for the beta signature? If so, we'd like to have it extended to 60 days.

Please find the signed beta agreement attached.

Thank you for your help in advance,

Sebestyen Bartha

Maintenance signature request for Ricoh ESA Combined Client

Submitted by cristian.craci… on
Incident Properties
Product:
SDK/J
Category:
Request
How would you categorize this Request?:
Maintenance Signature
End User - Customer Name:
MISSION HEALTH SYSTEM INC
Origin of Incident:
End User Customer Name
Application Type:
Embedded Application (Android App)
Application Version Number:
7.7
Application Build Number:
5.57
Product ID's:
SDK/J: 4, 5, 7, 10,11,12
Question
Incident Question:

Hi,
This is a maintenance signature request for the Nuance legacy application. It needs to have all files signed.
Problem: Ricoh Aficio SP 5210SF - Previous user persists even after they log out at the panel
Customer: MISSION HEALTH SYSTEM INC
Product: Ricoh ESA Combined Client
Upon investigation we discovered that the combined client xlet on this device would fail to log out the authenticated user.
The fix simplifies the requirements checked prior to user logout.
The problem was discovered in version 7.7.5.50
The new version is 7.7.5.57

No visual elements have been changed

SDK/J: 4, 5, 7, 10,11,12
Thanks,

Subscribe to SDK/J

Main Menu