How to close a GPRS connection through WIP library

Legacy Open AT
1

Hi,
I’m Using Fastrack M1306B , firmware 6.57.

In my application I am testing GPRS connection and Tcp Client whit WIP library.

In particular I am testing the case in which the GPRS connection must be Deactive.

These are my steps:

  1. I active GPRS connection whit
    wip_bearerOpen(…);
    wip_bearerSetOpts(…);
    wip_bearerStart(b); where b is the bearer handle
    2)When I receive WIP_BEV_IP_CONNECTED I start the TCP client with:
    client = wip_TCPClientCreate(…); where client is the created chanel
    3)when I receive WIP_CEV_WRITE I start sending data to the server
    4)After the data sending I close socket with
    wip_shutdown(client,TRUE,TRUE);my server receives the closing of
    socket
  2. when I receive WIP_CEV_PEER_CLOSE:
    I close the created chanel whit wip_close(client);
    I stop the bearer whit wip_bearerStop(b);
  3. when I receive WIP_BEV_STOPPED:
    I close the bearer whit wip_bearerClose(b);

On TMT I read these trace :

From the trace it is observed that the gprs is closed.
But if after wip_bearerClose(b) I attend a minute and after I execute
adl_atCmdCreate(“AT+CGATT?”,TRUE,CGATT_0,“*”,NULL )
the answer is +CGATT: 1.
My question is:
Is wip_bearerStop(b) + wip_bearerClose(b) equal to AT+CGATT = 0??

2

Hi,

I think wip_bearerStop and wip_bearerClose will just set +CGACT to 0, but +CGATT is still 1.
I think this is not a problem of leaving +CGATT=1, should not cause any big problem.

3

I have problem opening and closeing many times in one minute the socket

wip_netInitOpts(WIP_NET_OPT_SOCK_MAX,2,WIP_NET_OPT_END);

wip_bearerOpen( &My_wip_bearer, “GPRS”, evh_bearer, NULL);
wip_bearerSetOpts( My_wip_bearer, WIP_BOPT_GPRS_APN, “My APN”,
WIP_BOPT_LOGIN,“My login” ,
WIP_BOPT_PASSWORD, “My Pwd”,
WIP_BOPT_END);

wip_bearerStart( My_wip_bearer);

Wip_current_channel = wip_TCPClientCreate( “x.x.x.x”, port, evh_tcpIp, NULL);

//socket Opens
wip_shutdown(Wip_current_channel,TRUE,TRUE);
In evh_tcp I receive WIP_CEV_PEER_CLOSE and I do wip_close(ev->channel);

Wip_current_channel = wip_TCPClientCreate( “x.x.x.x”, port, evh_tcpIp, NULL);

//socket Opens
wip_shutdown(Wip_current_channel,TRUE,TRUE);
In evh_tcp I receive WIP_CEV_PEER_CLOSE and I do wip_close(ev->channel);

Wip_current_channel = wip_TCPClientCreate( “x.x.x.x”, port, evh_tcpIp, NULL);

Wip_current_channel == NULL !!!!

if I wait for 1 minute and I do
Wip_current_channel = wip_TCPClientCreate( “x.x.x.x”, port, evh_tcpIp, NULL);

it works !!!

I do not have the controle of “x.x.x.x” but this things worked with ed_lib()

if I put
wip_netInitOpts(WIP_NET_OPT_SOCK_MAX, 10 ,WIP_NET_OPT_END);
The same thing happens after 11 wip_TCPClientCreate()

Any idea how to close the tcp socket so that I can open it as many times I would like to ???

Thanks.

4

Perhaps the socket is not closed when evh_tcp is called with prameter WIP_CEV_PEER_CLOSE.

What you can do when event WIP_CEV_PEER_CLOSE arrives is launching a timer with one ticks to be sure that the socket is closed !

Did you try it instead of launching a timer of 1 minute ?

5

Hi,

One tick timer does not change anything. One minute is OK.

Unfortunately the external application Open the next socket every 3 seconds when the last is closed, so I can not wait one minute.
I never have idle time between Close/Open more then 3 seconds.

The communication time of opend socket is 2 minutes. What I do not understand is why the first closed socket does not close since it have 2 minutes time while the second socket is running ???

No matter what I do, sooner or later I run out of Sockets …

Thanks…

6

Reading the documentation shows that wip_shutdown(sck, TRUE, TRUE) or wip_close(sck) perform the same result (just the result), except that the former variant produces WIP_CEV_PEER_CLOSE event, which by my opinion has nothing to do with peer, as it fires at the same moment, when the shutdown is executed (turn on timing option on TMT). Even more, executing wip_bearerStop(br) at the same moment fires error WIP_CER_HOST_UNREACHABLE. Reading the documentation reveals, that bearerStop() tries to abort the connection, if it is active. Your first code snippet tries to close the socket with three different simultaneous attacks!

To close a socket I opted for wip_close(), which by me is cleaner method to fully close it. Then I wait some seconds, as I can get no disconnect event. Experiment a little do get your optimal delay. At that moment I use wip_bearerStop(br) and after 1 second I get the WIP_BEV_STOPPED event and then I can use the socket again (WIP_NET_OPT_SOCK_MAX = 1).

So, use just one method to close the socket, and add some delay to let FIN packets to do their job gracefully. As in your second snippet, wip_bearerStop(br) may not be needed in most applications.

7

Yes, this is the behaviour that I am seeing!

It seems like the PEER_CLOSE event event simply indicates that WIP has initiated closing the socket - not that the closedown procedure with the Peer has been completed.

In other words, the Bearer cannot be stopped when the PEER_CLOSE event is received, because the socket is still handling the closedown protocol! :unamused:

This seems very poor to me - surely there should be some event to positively indicate when a Socket has been closed and, therefore, it is safe to close the Bearer?! :open_mouth:

8

wip_shutdown() closes the connection cleanly, but doesn’t release the resources taken by the socket. the only way to free a wip_channel_t is to call wip_close() on it. wip_shutdown() doesn’t release them.

So wip_shutdown() causes a WIP_CEV_PEER_CLOSE() (or an EOF under POSIX) on the peer socket, not locally! And actually, if you wip_close() a socket you forgot to shutdown, the shutdown will also be sent implicitly.

As for shutdown: in TCP/IP, you detect when your peer shuts down its writing channel, there’s no way to know whether it shot down its reading channel (it’s up to your applicative protocol over TCP to handle that if necessary). WIP_CEV_PEER_CLOSE signals that the peer stopped writing. What happens in many applicative protocols is that when you close your writing, the peer closes its writing in response, so you get WIP_CEV_PEER_CLOSE soon after you called wip_shutdown(); but this event is triggered by the peer.

In order to check that everything has been sent, before closing the bearer: I’m affraid there’s no event for that. However, when you receive WIP_CEV_PEER_CLOSE, it means that your peer acknowledged your own shutdown, so it should be safe to close the bearer.