TCP/IP Client channel and GRPS bearer recovery

We are experiencing some GPRS failures. This is an intermittent occurrence that is difficult to reproduce. We would appreciate any assistance with this problem.

Here is a description of our program flow:
When the SIM card has been fully initialised and registered on the GSM network we start the GPRS bearer.
Upon receiving the WIP_BEV_IP_CONNECTED we start a TCP/IP Server on the unit: Our database server can communicate with the unit using this channel.
When the unit has data to send to our database server: It creates a TCP/IP client channel that connects to the server and sends the data. When no more data is available to send, the channel is closed.
If the unit is not able to connect to the server via the TCP/IP client channel, we create a ping channel that pings the DNS server. If we could ping the DNS server, it is assumed that the problem is not with GPRS. If we could not ping the server, it is assumed that there are problems with the GPRS and the bearer is stopped then closed as well as the TCP/IP server stopped. If GSM is still operational we start the bearer again.
We have a finaliser event handler for each channel (TCP/IP Server, TCP/IP Client and Ping) to ensure that the channel’s resources have been released.

The symptoms we are experiencing:
The unit can for some time (anything from 1 to 30 days or even longer) communicate via GPRS with the server.
At some stage when data is ready to be sent to the server, the TCP/IP client channel cannot be created and the WIP_CEV_ERROR: WIP_CERR_TIMEOUT: Timeout (for DNS request, TCP connection, PING response) event is received by the handler after some time (± 15 seconds)
The DNS server can successfully be pinged
The TCP/IP client channel creation is attempted again at a later stage (± 1.5 minutes later)
The WIP_CERR_TIMEOUT event is again received and this process continues until we get WIP_CEV_ERROR received: -992 (WIP_CERR_RESOURCES: No more TCP buffers available) when attempting to create a ping channel.
From there we stop and close the bearer and cannot create the bearer again as we continuously receive WIP_BEV_CONN_FAILED.
When attempting to send a GPRS AT command to the unit we receive CME Error: 536 Class locked
The unit only starts functioning correctly after a reboot which we do automatically after 1 hour of no communication with the server.

Some additional information:
In the traces we can see the channel finaliser events are being called.

Is there something wrong with the program flow?
Why do we get the WIP_CERR_RESOURCES event – seeing that all the channels are being closed? What can cause such an event?
Why can’t we get the GPRS bearer up and running again?
What is the correct way of closing all the channels and bearer and starting over with communication?

Hi,

The proper way to start and stop the bearer is :

1.Open the bearer
2.Start the bearer(WIP_BEV_IP_CONNECTED is received)
3.Create the TCP client and connect to the server.
4.close the TCP channel connection before closing the bearer
5.Stop the bearer(WIP_BEV_STOPPED is received)
6.Close the bearer.

It is possible that WIP start and stop is not hadled properly in the application.
Also make sure that once the unit is GSM connected(creg:1 OR creg :5) only then start the GPRS bearer .

To analyze the cause ,please capture the following trace levels and analyze the same :

  1. ADL: ALL
  2. ATI: 1, 2, 4, 5, 26
  3. L3RR: 3, 4
  4. L3SMG: 3, 4
  5. L3GMM : 3,4
  6. MMT: 27

Also please capture the WIP DEBUG traces :
r = wip_netInitOpts(WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_TRACE, WIP_NET_OPT_END);

Is that absolutely essential :question:

I always used to think that GSM Registration (CREG: 1or 5) was necessary for GPRS attach (CGREG: 1or 5) - but I have seen a few cases where CGREG occurs before CREG

Thank you for the information.

We are starting and stopping the bearer in the proper way as descibed. We also only start the GPRS bearer once the GSM is connected.

We have enabled the trace levels and WIP DEBUG traces. Will provide feedback once we have traces relevant to the problem.

We are experiencing exactly the same issue. I am pretty sure we are doing things properly.

I am writing this lines because we have this problem with an only device. We have five devices being tested with the same program, each device with a different provider. Some of them get public IPs and other NAT IPs. But this behaveour it only occurs with a certain provider and an special APN to get a public IP.