Socket ISSUES

Jono · December 18, 2009, 5:16am

I’m experiencing SOCKET issues with Wavecom Fastrack Supreme 04, running on WIP library 5.05 and on R74

This is how the bearer + socket’s are being initialized, note : I attach handler using AT+CGATT=1

Ret_Value = wip_netInit();

Ret_Open = wip_bearerOpen(&Br_Id,"GPRS",BearerHandler,NULL);

		if(Ret_Open == 0) {


			/*set the option for the bearer service */
        	    Ret_Option = wip_bearerSetOpts(Br_Id,WIP_BOPT_GPRS_APN,APN,
				           WIP_BOPT_LOGIN,APNUname,
					   WIP_BOPT_PASSWORD,APNPwd,
					   WIP_BOPT_END);

		if(Ret_Option == 0) {

			Ret_Start =wip_bearerStart(Br_Id);

In BearerHandler callback

case WIP_BEV_IP_CONNECTED:

        adl_tmrSubscribe(FALSE, 100, ADL_TMR_TYPE_100MS, pollGPRS);
	adl_atSendResponse ( ADL_AT_RSP, "opensocket\r\n");
	BearerRunning = TRUE;
	SocketOpeningTimer = adl_tmrSubscribe (FALSE, TimerValue, ADL_TMR_TYPE_100MS, OpenSocketTimer);
	break;

and in OpenSocketTimer

Channel = wip_TCPClientCreate(IpAddr,Port,ClientEventHandler,NULL);
		RetVal = wip_setOpts(Channel, WIP_COPT_NODELAY, TRUE, WIP_COPT_END);

This was the default socket creation used and during testing on my work bench, i have had no issues whatsoever.

However, when it was rolled out live, we found problems where the socket just get stuffed and throws a BUSY event randomly and fails to connect there after.

When a packet is sent using the wip_write across the created TCP channel, the modem expects an acknowledgement. If there is not acknowledgement received after a period of time, and the modem detects an existence of GPRS, it attempts to reconnect the channel by closing the socket and recreating another socket.

The software probes the state of the channel and it will show BUSY all the time, and then subsequently throws a WIP_CEV_ERROR event.

The software would not be able to create a new socket until a reset is done on the unit.

I have ran out of ideas on how this happens. I’ve tried sending the information to two different server implementation that waits for incoming connection but still does not work.

Clues anyone?

Jono · January 5, 2010, 4:18am

This is an error i’m receiving for the GPS in another location. A deployed modem.

On my work bench, and my test unit, i have failed to replicate the issue thus being able to fix it.

Any throw arounds will be appreciated

tomalex · January 5, 2010, 11:42am

Do not use the AT+CGATT=1 command. The bearerStart() function will start the bearer completly.

Do not set the WIP_COPT_NODELAY to TRUE unless there is a strong reason to do that. Please give it a try in this configuration.

Jono · January 10, 2010, 10:20pm

Gday Tom,
Just another snippet of my current code

The function that invokes AT+CGATT=1

void SetGprs (void ) {
	adl_atCmdCreate("AT+CGATT=1",FALSE, GPRSAttachHandler,"*",NULL);
	adl_atSendResponse ( ADL_AT_RSP, "set gprs\r\n");
}

The callback function

bool GPRSAttachHandler(adl_atResponse_t *Rsp) {

	s8 Ret_Open;
	s8 Ret_Option;
	s8 Ret_Start;
	s8 retVal = FALSE;
	TRACE (( IP_TRACE_LEVEL, "Inside GPRSAttachHandler" ));
	adl_atSendResponse(ADL_AT_RSP, "Inside Attach Handler\r\n");

	if(Rsp->RspID == ADL_STR_OK) {

		/*Opening the bearer service */
		adl_atSendResponse(ADL_AT_RSP, "AT+CGATT is OK\r\n");
		Ret_Open = wip_bearerOpen(&Br_Id,"GPRS",BearerHandler,NULL);

		if(Ret_Open == 0) {

			TRACE (( IP_TRACE_LEVEL, " Bearer open successful "));

			 adl_atSendResponse ( ADL_AT_RSP, "bearer ok\r\n");

			/*set the option for the bearer service */
            Ret_Option = wip_bearerSetOpts(Br_Id,WIP_BOPT_GPRS_APN,APN,
				                           WIP_BOPT_LOGIN,APNUname,
							               WIP_BOPT_PASSWORD,APNPwd,
							               WIP_BOPT_END);

			if(Ret_Option == 0)	{

				Ret_Start =wip_bearerStart(Br_Id);

				if(Ret_Start == 0){
					TRACE (( IP_TRACE_LEVEL, " Bearer connect function successful "));
					 adl_atSendResponse ( ADL_AT_RSP, "bearer success\r\n");
				}

				else if(Ret_Start == -27){
					TRACE (( IP_TRACE_LEVEL, " Connecting to the GPRS network "));
					 adl_atSendResponse ( ADL_AT_RSP, "connecting\r\n");
				}

				else {
					SendErrorInfo(ERR_START_GPRS);
					TRACE (( IP_TRACE_LEVEL,"Bearer connect function failure Value: %d", Ret_Start));
					adl_atSendResponse ( ADL_AT_RSP, "bearer not ok\r\n");
					 adl_tmrSubscribe(FALSE,50,ADL_TMR_TYPE_100MS, poll_creg1);
				}
			}
			else {
				SendErrorInfo(ERR_START_GPRS);

				CloseGPRSBearer ();
				adl_atSendResponse ( ADL_AT_RSP, "close bearer");
				adl_tmrSubscribe(FALSE,50,ADL_TMR_TYPE_100MS, poll_creg1);
				TRACE (( IP_TRACE_LEVEL,"Error setting bearer options: %d", Ret_Option));

			}
		}
		else {
			SendErrorInfo(ERR_START_GPRS);

			CloseGPRSBearer ();

			TRACE(( IP_TRACE_LEVEL,"Bearer open failure Value: %d\r\n",Ret_Open));
			adl_atSendResponse ( ADL_AT_RSP, "Bearer open failure Value\r\n");
			adl_tmrSubscribe(FALSE,50,ADL_TMR_TYPE_100MS, poll_creg1);
		}
	}
	else {
		SendErrorInfo(ERR_ATT_GPRS);

		CloseGPRSBearer ();

		adl_atSendResponse ( ADL_AT_RSP, "Error attaching to GPRS\r\n");
		adl_tmrSubscribe(FALSE, 50, ADL_TMR_TYPE_100MS, poll_creg1);

		TRACE(( IP_TRACE_LEVEL,"Error attaching to GPRS"));
	}
	return retVal;
}

So let’s say for testing purposes, it will be OK to just call the GPRSAttachHandler function without invoking AT+CGATT=1, and then call the BearerOpen, later BearerStart?

Jono · January 12, 2010, 12:14am

Somehow that didn’t work. The whole stack seemed to be stuck or something. Every time it tries to create a socket, it will return a WIP_CEV_ERROR. Before that, it keeps returning BUSY event on the state of channel.

Any clue?

Jono · January 12, 2010, 12:18am

I can’t really resolve the issue because i have difficulties replicating the problem locally on our work bench. I can run it for hours and days without any socket issues but once it is out on site, it just becomes a recurring issue. The issue may crop out within the first 10 mins, or after a few hours on site, which pretty much leaves me clueless.

Madouc · January 12, 2010, 6:41am

have you tried creating reception problems? by for example using a lesser antenna, moving the testing unit to a area in the building with bad reception or even aluminum foil?

do you have a way to make sure the power-supply is stable in the field? (although i don’t really thing that would be the problem)

awneil · January 12, 2010, 7:28am

A more repeatable method to reduce signal strength is to use an inline attenuator in the antenna connection; eg,

uk.farnell.com/jsp/search/browse … tid=286788

Madouc · January 12, 2010, 4:32pm

true (forgot about those )

awneil · January 12, 2010, 4:51pm

What they don’t give you is the kind of variable signal level - and interference - that you get in real life.

But they’re better than nothing!

I also have a coaxial relay and a couple of variable attenuators that I found on ebay - it’s well worth keeping an eye out for this kind of stuff! 8)

Jono · January 13, 2010, 12:19am

I already have an inline attenuator.
[attachment=0]IMG_0110.jpg[/attachment]

I really believe it’s something in the code that I’ve missed/put in, causing the problem.

When the BUSY event is triggered, I’ll get it consecutively until a part of my code closes the channel and re-creates a new TCP connection. When it attempts a new TCP connection, it will keep getting a WIP_CEV_ERROR immediately. I would not be able to create a new TCP connection until the modem is has done it’s resetting (switch power off, switch power on).

I’m really unsure beleaguered as to the source of the problem, and even harder is replicating it. I’ve got the modems pointing to the same server, same configurations, but still can’t replicate the issue. The only different variable here is the Sim Card which is used in the modems.

Jono · January 13, 2010, 3:30am

by sheer luck and stupidity i’ve managed to recreate partial of the problem in house. The only problem, it is not consistent and it happened only once or twice out of the 30 times I’ve tried today. I’ve got some debugging notes released from the modem.

This is what happens for a successful bearer connection -> TCP Connection

[GPRS]: open: -> DISCONNECTED
 [GPRS]: start: -> CONNECTING
Starting GPRS[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
 [GPRS]: GPRS EVENT: 27 (cid=1)
 [GPRS]: GPRS EVENT ACTIVATE OK (cid=5)
[GPRS]: GPRS: -> CONNECTED
 [WIP] new TCPCLIENT 0x180e56e8
WIP_CEV_OPEN
WIP_CEV_WRITE

Once connection is established, the modem proceeds to send GPS data through the created TCP Channel, and waits for an ACKNOWLEDGEMENT (WIP_CEV_READ event).

case WIP_CEV_READ:
retVal = wip_read (Channel, (ascii*)test, 90);
break;

PROBLEM HERE:
For some odd reasons, after a while, it didn’t receive any acknowledgement from the server. The program will firstly close the channel, and re-create a TCP connection in which then this happened

Successfully Closed
[WIP] closing TCPCLIENT 0x180e4d08
[WIP] new TCPCLIENT 0x180e5748

It basically stopped short in creating the new TCPClient (No WIP_CEV_OPEN, WIP_CEV_WRITE) event
The program checks the state of the channel and it returns

BUSY

After a minute or so, the WIP_CEV_ERROR is triggered. When the event is triggered, the program attempts to close the bearer

wip_bearerStop(Br_Id)
wip_bearerClose(Br_Id)

[WIP] closing TCPCLIENT 0x180e5748
[GPRS]: stop: stop GPRS interface
[GPRS]: stop: GPRS deactivate -> DISCONNECTING
[GPRS]: close: -> CLOSED
Bearer successfully closed

The program will attempt to connect to the bearer and TCP socket after 20 seconds. This was when i could no longer connect to the bearer until the whole unit is restarted. Following is the log received

[GPRS]: open: -> DISCONNECTED
 [GPRS]: start: -> CONNECTING
Starting GPRS[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate

after 2 mins + 

[GPRS]: GPRS EVENT SETUP/ACTIVATE KO (cid=1): -> DISCONNECTED
GPRS Conn Failed (Event WIP_BEV_CONN_FAILED: triggered)

It stopped short of creating event 27 for reasons which i do not understand at all. Like i say, no uniform pattern and it happens randomly. But seemingly more so evidently on site then my work bench. I’ve tried using wip_netExit(), no luck.

I have reached a point where I am easily tempted to put AT+CFUN=1 on parts of the code.

In order, the WIP codes i’m using.

Ret_Value = wip_netInitOpts(
                                  WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_UART1, 
                                  WIP_NET_OPT_END);

When I get ADL_SIM_STATE_FULL_INT as the state :

Wip_bearerOpen(&Br_Id, “GPRS”, BearerHandler, NULL);
wip_bearerSetOpts(Br_Id,WIP_BOPT_GPRS_APN,APN,
                                                                WIP_BOPT_LOGIN,APNUname, WIP_BOPT_PASSWORD,APNPwd,
                                                                WIP_BOPT_END);
Wip_bearerStart(Br_Id)


Bearer Open callback function BearerHandler, that’s where we check when there is an event that is returned from BearerOpen.

case WIP_BERR_GPRS_FAILED:
case WIP_BEV_CONN_FAILED:
case WIP_BEV_IP_CONNECTED:
                Channel = wip_TCPClientCreate(IpAddr,Port,ClientEventHandler,NULL);
case WIP_BEV_IP_DISCONNECTED:
case WIP_BEV_STOPPED:

gregorbader · February 15, 2010, 1:03pm

Hi -Jono-,

I have exact same problem, but it is happening every time!
After first successful connection I try to open a second Tcp connection which shows this behaviour.

My code was developed with FW6.63g and WIP 3.20.2030 where it is running as expected.
When compiled for FW7.4a and WIP 5.20.0.2040 this problems occur!
So i assume the problem lies in new WIP lib.

awneil · February 15, 2010, 1:15pm

Hmm… this is interesting: I am also having problems where WIP seems to have been “broken” between v3 and v5
see: WIP v5.10 Bug: Multiple HTTP Requests
and follow the link to: Multiple HTTP Requests - every other one fails

I’m using HTTP, but I wonder if this might be related…?

gregorbader · February 15, 2010, 3:02pm

Hi awneil!

Yes i think you are right with your assumption that WIP lib v5 is broken.
I enabled all wip traces as suggested by you:

wip_logEvents = TRUE; /* Enable all WIP Event traces */

Here are the results. 2 consecutive tries to open a Tcp channel from ground up.
wip_netInitOpts, … , wipnetExit

[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS EVENT ACTIVATE OK (cid=1)
[GPRS]: GPRS: -> CONNECTED
[WIP] new TCPCLIENT 0x180c5f1c
[WIPEV] WIP_CEV_OPEN @ TCPCLIENT 0x180c5f1c
[WIPEV] WIP_CEV_WRITE @ TCPCLIENT 0x180c5f1c (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c5f1c (0 bytes)
...
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c5f1c (0 bytes)
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180c5f1c
[WIP] closing TCPCLIENT 0x180c5f1c
[GPRS]: stop: stop GPRS interface
[GPRS]: stop: GPRS deactivate -> DISCONNECTING
[GPRS]: GPRS EVENT: 2 (cid=1)
[GPRS]: GPRS EVENT DEACTIVATE OK/KO (cid=5): -> DISCONNECTED
[GPRS]: close: -> CLOSED

10min between

[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS EVENT: 27 (cid=1)
[GPRS]: GPRS EVENT ACTIVATE OK (cid=5)
[GPRS]: GPRS: -> CONNECTED
[WIP] new TCPCLIENT 0x180c6afc
[WIPEV] WIP_CEV_ERROR @ TCPCLIENT 0x180c6afc (errno = WIP_CERR_TIMEOUT/-986)
[WIP] closing TCPCLIENT 0x180c6afc
[GPRS]: stop: stop GPRS interface
[GPRS]: stop: GPRS deactivate -> DISCONNECTING
[GPRS]: GPRS EVENT: 2 (cid=1)
[GPRS]: GPRS EVENT DEACTIVATE OK/KO (cid=5): -> DISCONNECTED
[GPRS]: close: -> CLOSED

awneil · February 15, 2010, 3:12pm

Can you give the corresponding traces from WIP v3?

gregorbader · February 16, 2010, 6:53am

Here the traces with WIP 3.20.2030:

[GPRS]: initialized.
[GSM]: initialized.
[UART1]: initialized.
[UART2]: initialized.
[]: initialized.
[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS EVENT: 27 (cid=1)
[GPRS]: GPRS EVENT ACTIVATE OK (cid=1): FCM open
[GPRS]: FCM subscribe: 1
[GPRS]: FCM EVENT FLOW OPENNED: -> CONNECTED
[WIPEV] WIP_CEV_OPEN @ TCPCLIENT 0x180d45d0
[WIPEV] WIP_CEV_WRITE @ TCPCLIENT 0x180d45d0 (5840 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (16 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (2 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (19 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180d45d0 (79 bytes)
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180d45d0
[WIP] closing TCPCLIENT 0x180d45d0
[GPRS]: stop: FCM close -> DISCONNECTING
[GPRS]: FCM unsubscribe (1)
[GPRS]: FCM EVENT FLOW CLOSED: GPRS deactivate
[GPRS]: GPRS EVENT: 2 (cid=1)
[GPRS]: GPRS EVENT DEACTIVATE OK/KO (cid=1): -> DISCONNECTED
[GPRS]: close: -> CLOSED
[]: exit.
[UART2]: exit.
[UART1]: exit.
[GSM]: exit.
[GPRS]: exit.

I post only 1 sequence as they are all the same.
You can see clearly the traces of wip_netInitOpts() & wipnetExit() which are missing in WIP v5 although its the same source !!.

A second test with WIP 5.20.0.2040 shows that it is possible to open 2 consecutive Tcp connection as long as Gprs is kept open:

[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS EVENT ACTIVATE OK (cid=1)
[GPRS]: GPRS: -> CONNECTED
[WIP] new TCPCLIENT 0x180c60dc
[WIPEV] WIP_CEV_OPEN @ TCPCLIENT 0x180c60dc
[WIPEV] WIP_CEV_WRITE @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180c60dc
[WIP] closing TCPCLIENT 0x180c60dc
[WIP] new TCPCLIENT 0x180c60dc
[WIPEV] WIP_CEV_OPEN @ TCPCLIENT 0x180c60dc
[WIPEV] WIP_CEV_WRITE @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_READ @ TCPCLIENT 0x180c60dc (0 bytes)
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180c60dc
[WIP] closing TCPCLIENT 0x180c60dc
[GPRS]: stop: stop GPRS interface
[GPRS]: stop: GPRS deactivate -> DISCONNECTING
[GPRS]: GPRS EVENT: 2 (cid=1)
[GPRS]: GPRS EVENT DEACTIVATE OK/KO (cid=5): -> DISCONNECTED
[GPRS]: close: -> CLOSED

In WIP v5 header wip_net.h you can find this:

s8 wip_netExit( void);  /* deprecated */

Why is this function deprecated? And why is this not mentioned in doc?
There were definately some major changes in initialization/exit of the lib.

gregorbader · February 16, 2010, 9:36am

Hi all!

I found my problem! I was using a Q26 Extreme module. The problem is only related to this module!
For a real comparison of the WIP libs i now used a Q2686H with same SW as with Q26 Extreme and now everything is working as expected.

regards,
Gregor

awneil · February 16, 2010, 10:21am

For the benefit of others who may have similar problems, can you expand on what the actual problem is?

ie, what is it specifically about the Q26 Extreme that causes this problem? Is there a workaround?

gregorbader · February 16, 2010, 12:32pm

The problem is, that subsequent Tcp connection fail with timeout.
It only occurs on Q26 Extreme modules, so I can’t be more specific (HW or FW).

It is definately not a problem of the WIP lib/application, because the same application runs on an Q2686H.

Topic		Replies	Views
Bearerstart problem Open AT	6	1925	March 5, 2012
TCPClientCreate problem Open AT	0	1099	April 19, 2010
Wip library and ADL Open AT	3	2335	June 6, 2007
Urgent Help about BEARER START Open AT	13	5420	November 22, 2011
Can not get connection with WIP Open AT	22	5397	October 14, 2009

Socket ISSUES

Related topics