Reason for WIP_CERR_TIMEOUT


#1

I put some data using http to a web server. Everything works fine but after some time (a number of days) i get wip_cerr_timeout (-986) error. My web server works just fine. After restarting the device everything gets back to normal. What can be cause of this error?


#2

I have the exact same problem only I’m using wip_TCPClientCreate. It works great for as long as I continue to keep the socket open and passing data. But if close the socket and let it sit for maybe an hour, the next time I try to connect I get an -986 error WIP_CERR_TIMEOUT.

If I try to reconnect using a DNS instead of an IP address, I then get an -993 error WIP_CERR_DNS_FAILURE.

As soon as I restart, it all starts working again.

Can anyone tell me what I can do if I get these errors?

Eddie


#3

That’s probably the network operator timing-out your connection :question:

Obviously, they can’t afford to just leave idle sessions open indefinitely - but some are quicker to timeout than others.
It seems that Vodafone (pre-pay, at least) has the quickest timeout over here in the UK.

Repeating the wip_CreateClient should fix this.

Your application needs to tolerate this kind of thing any how, as there are obvioulsy plenty of reasons why connections could be lost due to causes both within and beyond the GPRS/GSM network…! 8)


#4

Your explanation confused me a bit. After i do post I close both channels (the one resulted from wip_HTTPClientCreateOpts and the one from wip_getFileOpts), and every time i do a post i create new channels. Are you saying that i should do the same thing with the bearer to? (or at least after a while close the bearer and create a new one?) Or create a new one after the gprs(gsm) was lost for a longer period of time?


#5

Every GPRS provider has its own quirks, and only few of them provide complete, reliable connections with no NAT or router doing weird stuff in your back. They’re likely to have timeouts both on socket idleness and on GPRS connection idleness, so if you’re going to stay asleep for long periods (say > 1 hour), it’s probably safer to close + reopen your GPRS bearer. Or simply reboot the module, if it’s good enough for your application and you don’t want to rewrite your bearer handling code.


#6

With UK Vodafone, it was significantly less than an hour! :frowning:


#7

Because I don’t want to generate an error to my external application (if possible), I decided to close and open the bearer. I’m able to close the bearer but not reopen it. what is the correct sequence in closing and reopening the bearer?

This is what I’m currently doing:
1 - wip_bearerOpen
2 - wip_bearerSetOpts
3 - wip_bearerStart
//At some point I get the error -986
4 - wip_bearerStop
5 - wip_bearerClose
//I try to reopen bearer
1 - wip_bearerOpen - fails - returns -21
2 - wip_bearerSetOpts - fails - returns -24
3 - wip_bearerStart - fails - returns -24

What I’m I doing wrong? Thanks.


#8

Where is the best place to close the bearer i have my http event handler like this

void HTTP_hdl_c(wip_event_t *event, void *context)
{
     s32 ret;
	 s32 code;
    switch(event->kind)
    {
        //response header message received
        case WIP_CEV_OPEN:

        break;
       
        //response body message received
        case WIP_CEV_READ: 
            //check http_status

            wip_getOpts(http_channel_comm, WIP_COPT_HTTP_STATUS_CODE, &code, WIP_COPT_END);
           
            if (code == 200) {

				ret=wip_close(http_channel_comm);
				TRACE((TRACE_LEVEL_HTTP, "wip_close ret: %d", ret));
				ret=wip_close(http_channel_pers);
				TRACE((TRACE_LEVEL_HTTP, "wip_close ret: %d", ret));
				gprs_bearerClose();
            } 
        break;
       
        case WIP_CEV_PEER_CLOSE:
            if (http_channel_comm){
				wip_close(http_channel_comm);
			}
			if (http_channel_pers){
				wip_close(http_channel_pers);
			}


        break;
       
        case WIP_CEV_ERROR:
            TRACE((TRACE_LEVEL_HTTP, "HTTP_hdl_c(): WIP_CEV_ERROR"));
             http_close();			            
        break;
       
        //write request body
        case WIP_CEV_WRITE:
            ret = wip_write(http_channel_comm, http_Data.data, wm_strlen(http_Data.data));
            TRACE((TRACE_LEVEL_HTTP, "wip_write ret: %d", ret));
			ret=wip_shutdown(http_channel_comm,FALSE,TRUE);
			TRACE((TRACE_LEVEL_HTTP, "wip_shutdown ret: %d", ret));
        break;

    }
}

if i do like this right after closing the http channels i get a flow like this:

HTTP] new request PUT x
[HTTP] connect to host:x
WIP_CEV_OPEN
WIP_CEV_WRITE
WIP_CEV_READ
HTTP send ok
Stoping the bearer
[GPRS]: stop: FCM close -> DISCONNECTING
[GPRS]: FCM unsubscribe (1)
[HTTP] error -989 @ 01a4a17a
[HTTP] channel closed by server
[WIP] closing HTTP_DATA 0x1a4a17a
[WIP] closing HTTP_CONTROL 0x1a49f4a
[WIP] closing TCPCLIENT 0x1a4a46a
[GPRS]: FCM EVENT FLOW CLOSED: GPRS deactivate
[GPRS]: GPRS EVENT: 2 (cid=1)
[GPRS]: GPRS EVENT DEACTIVATE OK/KO (cid=1): -> DISCONNECTED
GPRS event : 4
Bearer stoppped
[GPRS]: close: -> CLOSED

From this i understand that i call wip_close for the http channels they should be closed, but when the close bearer is called i get an error -989 = host unreachable
So something i am doing wrong, i guess i am closing the bearer to fast; so where to put the closing of the bearer?
Would wip_bopt_restart option work for a gprs connection stopped by the gsm operator? How?