Timeout exceptions on BlackBerry SUP app

[Former Member]

two of Customer's BlackBerry’sone(one a

simulator) experienced a login timeout error.  One was unable

to

connect and one was unable to register with this

error:

“com.sybase.mobile.ApplicationTimeoutException: Unable to

register

application within 150 seconds.”  We would like to know if

there is anything

that indicates why this could have

happened. 

Here is a glimpse of the error that we see in the server log:

Thread-269 [com.sybase.djc.security.SecurityManagerLog] Login Failed: user 'E60470'. Account is locked due to previous login failures. Account will be unlocked in 2,371 seconds.

2013-04-11 11:57:08.639 ERROR   Mobilink     Thread-269 [com.sybase.ml.sup.Logger] [-10052] The authenticate_parameters script returned 4000

2013-04-11 11:57:08.675 WARN    MMS          Thread-286 [com.sybase.djc.security.SecurityManagerLog] Login Failed: user 'T41661'. Account is locked due to previous login failures. Account will be unlocked in 2,403 seconds.

2013-04-11 11:57:08.685 ERROR   Mobilink     Thread-286 [com.sybase.ml.sup.Logger] [-10052] The authenticate_parameters script returned 4000

2013-04-11 11:57:08.853 WARN    MMS          Thread-268 [com.sybase.djc.security.SecurityManagerLog] Login Failed: user 'E60279'. Account is locked due to previous login failures. Account will be unlocked in 3,595 seconds.

2013-04-11 11:57:08.866 ERROR   Mobilink     Thread-268 [com.sybase.ml.sup.Logger] [-10052] The authenticate_parameters script returned 4000

2013-04-11 11:57:10.134 WARN    MMS          Thread-275 [com.sybase.djc.security.SecurityManagerLog] Login Failed: user 'E10972'. Account is locked due to previous login failures. Account will be unlocked in 2,960 seconds.

and in the mlsr log:

I. 2012-12-19 12:29:57. <67427> Subscription id 7: consolidated progress 0 and remote progress 0

W. 2012-12-19 12:30:36. <67439> [10012] The consolidated and remote databases disagree on when the last synchronization took place, the progress offsets are 35 in the consolidated database and 33 in the remote database.  The remote is being asked to send a new upload that starts at the last known synchronization point

I. 2012-12-19 12:30:36. <67439> Progress offsets for the publications that are explicitly involved in the current synchronization

I. 2012-12-19 12:30:36. <67439> Subscription id 9: consolidated progress 34 and remote progress 34

W. 2013-03-15 19:28:36. <85195> [10012] The consolidated and remote databases disagree on when the last synchronization took place, the progress offsets are 415 in the consolidated database and 409 in the remote database.  The remote is being asked to send a new upload that starts at the last known synchronization point

I. 2013-03-15 19:28:36. <85195> Progress offsets for the publications that are explicitly involved in the current synchronization

I. 2013-03-15 19:28:36. <85195> Subscription id 2: consolidated progress 415 and remote progress 409

E. 2013-03-15 19:32:26. <85186> [-10279] Connection was dropped due to lack of network activity

E. 2013-03-15 19:32:27. <85187> [-10279] Connection was dropped due to lack of network activity

E. 2013-03-15 19:32:28. <85188> [-10279] Connection was dropped due to lack of network activity

E. 2013-03-15 19:32:29. <85189> [-10279] Connection was dropped due to lack of network activity

. 2013-03-14 15:15:56. <36277> [-10052] The authenticate_parameters script returned 4000

E. 2013-03-14 15:15:58. <36286> [-10052] The authenticate_parameters script returned 4000

W. 2013-03-14 15:16:00. <36296> [10012] The consolidated and remote databases disagree on when the last synchronization took place, the progress offsets are 53 in the consolidated database and 51 in the remote database.  The remote is being asked to send a new upload that starts at the last known synchronization point

I. 2013-03-14 15:16:00. <36296> Progress offsets for the publications that are explicitly involved in the current synchronization

I. 2013-03-14 15:16:00. <36296> Subscription id 9: consolidated progress 52 and remote progress 52

I attached both logs for your analysis.

thanks

serverLog.txt.zip

mlsr_err.txt.zip

[waynesmith]

Fiston,

If the log in fails after so many attempt the user is then locked out.

The more they try the longer the lock out number will be

In SCC there is an option to change the lock out value.

Also because it a Blackberry device they need to check the configuration

on how they are configuring the Blackberry Device normaly it uses certificates

or the BES server to log in. Are they going directly to the SUP server or are they

using a BES server. That is importaint to know.

[Former Member]

Customer is using a BES server when running on a device. not sure what

you mean by using a BES server to login.  How would I check that?

On another problem, their devices were down when BES was down.  But, the

simulator was not down; the simulator does not use BES to my knowledge.

On their current problem,they had both a device

and a simulator having the

timeout error.  So not sure if the BES is part of the issue.

Fiston

[Former Member]

Wayne, please see the above diagram for more details of their configuration

[waynesmith]

Looking at the diagrame I see the Blackberry devices are connecting to a RIM Relay Server

then they are connecting to the BES server. Normaly Blackberry Phones would connect directly

to the BES server.  The BES server can be configured to server certificates to the Blackberry

phoines. BES also have the capability to handle the Push updates to the Balckberry Phones.

Now if the devices are timing out on connection you need to first look at hte Relay Server

by setting the verbose to level 5 and see what is going back and forth between the relay

server and the BES server.

Next

They need to look at the BES configuration things we don't know is how that BES server is setup

meaning is it configured to server up certificates, is it setup for PUSH.

To me it looks like the setup of BES and Relay server are backwards. I would of expectied

the BES server first and then the relay server to the SUP. have the Relay server inbetween

seems to be the issue or at least one of the issue here.

1- have then try connecting directly to the BES server

2- Set the verbose level to 5 on the relay server

3- I think they can turn on tracing on the BES server

[Former Member]

Hi Fiston,

I would like to know what kind of security configuration you have assigned to your MBO package in SCC. If it is admin please try to login with supAdmin default server username or if your following any other authentication mechanism please let me know that for further analysis.

Regards

Dinesh.

[Former Member]

Hi Rajagopal,

here is the answer to your question:

Authentication cache timeout(seconds): 5

Max number of failed

authentications: 3

Authentication lock duration(seconds): 3601

thanks,

Fiston

[Former Member]

Hi Fiston,

I am asking about security configuration for your package in SCC.

Regards

Dinesh.

[Former Member]

The assigned "Security configuration" in the

package is "admin."

[Former Member]

and under the athentication tab I see:

1)LDAPLoginModule: Provider

URL=ldap://etcnvpadc101.na.cokecce.com:3268

2)PreConfiguredUserLoginModule:

User Name=supAdmin; Roles=SUP

Administrator,SUP Domain Administrator,SUP DCN

User;

[Former Member]

Hi Fiston,

Its looks like your customer has configured the LDAP authentication to login to their application. Login request from mobile device is reaching the SUP server and authentication is getting failed tats why your account is getting locked. there could be two reasons for this issue.

     1. User is typing wrong password (But this is happening for all the user, so we can discard this reason)

     2. From your SUP server and LDAP server there will be communication problem (You can confirm this by try to do telnet from your SUP server to ldap server).

Regards

Dinesh.