Hi,

Currently, We've no emails are getting pushed out to any handhelds.
The BES manager shows the SRP status as DISCONNECTED.
We're using BES 4.1.4.16

I've carried out the standard connectivity tests and they all come back ok (BBSRPTEST, NetworkAccessNode (router) Ping, Tracert, telnet on 3101 and pathping)

The last contact the BES had with any handhelds was at 12:04 today.

I found the following entry on the Dispatcher log for the same time the handhelds lost contact:

[30000] (07/08 12:04:58.619):{0xB54} SRPClient::ReceivePacket: No received bytes (0)
[50097] (07/08 12:04:58.619):{0xB58} [SRP] Dispatcher\SRP Connection dropped, Error=0
[30000] (07/08 12:04:58.619):{0x2A0} [DIAG] EVENT=Unregister_thread, THREADID=0x2A0, THREADNAME="SRPClientReceiver"
[30000] (07/08 12:04:58.619):{0xB58} [SRP] Connection lost

I found the following entry on the Router log for the same time the handhelds lost contact:

[30000] (07/08 12:04:58.619):{0xB2C} [SERVICE_RELAY_SESSION:T12305364:00b93130] Disconnect session. IP=127.0.0.1
[30000] (07/08 12:04:58.635):{0xB24} [SERVICE_MANAGER] Connection established. Session=0x003efc28
[30000] (07/08 12:04:58.635):{0xB24} [SERVICE_RELAY_SESSION:UNKNOWN:003efc28] Accept service session. IP=127.0.0.1, ServiceSession=0x003edf10
[30000] (07/08 12:04:58.635):{0x1F2C} [DIAG] EVENT=Register_thread, THREADID=0x1F2C, THREADNAME="SRPReceiverHandler"
[30000] (07/08 12:04:59.619):{0x1C84} [DIAG] EVENT=Unregister_thread, THREADID=0x1C84, THREADNAME="SRPReceiverHandler"
[30000] (07/08 12:04:59.619):{0xB2C} [SERVICE_MANAGER] Delete session. UID=T12305364, Session=0x00b93130
[30000] (07/08 12:04:59.619):{0xB2C} [SERVICE_RELAY_SESSION:T12305364:003efc28] Service claim UID. UID: T12305364 Requested SRP Version:2, IP=127.0.0.1
[30000] (07/08 12:04:59.619):{0x124C} [DIAG] EVENT=Register_thread, THREADID=0x124C, THREADNAME="Unnamed"
[30000] (07/08 12:04:59.619):{0x124C} [RELAY_SRP:UNKNOWN:00bc5d78] Connecting to relay at address "srp.ie.blackberry.net"
[30000] (07/08 12:04:59.775):{0x124C} [RELAY_SRP:UNKNOWN:00bc5d78] Connect: Found 1 addresses for host "srp.ie.blackberry.net"
[30000] (07/08 12:04:59.775):{0x124C} [RELAY_SRP:UNKNOWN:00bc5d78] Connect: Host "srp.ie.blackberry.net" @ [193.109.81.33]
[30000] (07/08 12:04:59.775):{0x124C} [RELAY_SRP:UNKNOWN:00bc5d78] Connect: Trying "srp.ie.blackberry.net" @ [193.109.81.33]
[30000] (07/08 12:04:59.822):{0x124C} [SERVICE_RELAY_SESSION:T12305364:003efc28] Connection to relay established.
[30000] (07/08 12:04:59.822):{0x124C} [DIAG] EVENT=Unregister_thread, THREADID=0x124C, THREADNAME="Unnamed"


The application event logs show numerous entries for -
Blackberry Dispatcher - 20460 - [SRP] Connection failed
Blackberry Router - 20000 - [SERVICE_RELAY_SESSION:....] Service Authentication Timed out

The server has been restarted with no change.

Can anyone please help?

Call RIM and ask them if your SRP is locked out.

And if your SRP is locked out I would watch it closely after RIM re-enables your SRP to see if it gets disconnected again. If it does then make sure youxxx8217;re not sharing the SRP with another server within your environment. If you are not then you might want to get RIM to take a look to see if they can find out why it is getting disconnected.

Thanks for that - I've check and we're currently not locked out.

however, when on the phone with support this morning, we did get the issue resolved by:

Stopping these services in this order:

Blackberry Controller
Blackberry Dispatcher
Blackberry Router

Starting the services in this Order:

Blackberry Controller
Blackberry Dispatcher
Blackberry Router

Low and behold the BB's all started talking again.

When I asked for an explanation, the engineer explained the BES had lost contact with the SRP (ISP down for 1hour+) and the BES could no longer talk to the SRP, despite the Internet link being back up for over 12 hours. BBSRPTEST's, etc, will all pass successfully, but SRP traffic will still not resume.

A server reboot and individual service restarts did not work as they must be done in a specific order (above) to reset the BES state..... Apparently, when this particular error occurs, a server reboot will only return the BES to the (poor) state it was in prior to the reboot. Nice.....

Maybe for the next relesae, Services can be made dependant on others so they always start in the right order ...

Thanks Again for your input.

That makes perfect sence. Glad the issue is resolved.

... it does? Doesn't to me at all. When I reboot a server, I expect the services to start up in the proper order.