Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I'm currently debugging my application on the LG VX6000, and using debug mode **********2.

I notice that although the socket closes with 'X', PPP remains open '=', asleep '~' and does not close until after a significant amount of time > 5 mins. I'm concerned that this will lead to a flunk in NSTL testing.

Testing this on the emulator does not give such behaviour. The socket closes with 'X' and then becomes '#' which indications that PPP is closed.

I'm wondering if anyone has experienced this problem or knows a fix. Is this phone dependent, or Verizon/phone dependent and something to do with x1 CDMA? Thanks for any replies.

It is OK if it remains in the asleep ('~') net state. This is due to Verizon recently changing how they implement network initiated dormancy in their 1x networks. The 3.0 Simulator does handle this case.
It is not OK if the net state remains open ('=') for >30s. This may indicate a socket leak (bad), or a referenced INetMgr with a long linger time (not advisable).

It is OK if it remains in the asleep ('~') net state. This is due to Verizon recently changing how they implement network initiated dormancy in their 1x networks. The 3.0 Simulator does handle this case.
It is not OK if the net state remains open ('=') for >30s. This may indicate a socket leak (bad), or a referenced INetMgr with a long linger time (not advisable).

kurquhar, thanks for your reply! Certainly eliminated some concerns I had.
To describe in detail, I close and exit the app, and I get the following sequence: 'x', 'X' (socket closed) and then '~' (PPP asleep). If I remain in the "get it now" app manager screen, after a while, '~' will switch to '=' (PPP open). '=' appears for a short while before '~' again. This alternation happes for quite a while before I finally get '#'.
During the progress of my app, I get '~' after I close the socket. If my app needs the network again, I'll see socket messages before '~' again.
Everything is absolutely closed when i exit the app manager.
I want to be sure that this behaviour is normal, otherwise it will be back to debugging again... *sigh* Thanks in advance for any replies.

kurquhar, thanks for your reply! Certainly eliminated some concerns I had.
To describe in detail, I close and exit the app, and I get the following sequence: 'x', 'X' (socket closed) and then '~' (PPP asleep). If I remain in the "get it now" app manager screen, after a while, '~' will switch to '=' (PPP open). '=' appears for a short while before '~' again. This alternation happes for quite a while before I finally get '#'.
During the progress of my app, I get '~' after I close the socket. If my app needs the network again, I'll see socket messages before '~' again.
Everything is absolutely closed when i exit the app manager.
I want to be sure that this behaviour is normal, otherwise it will be back to debugging again... *sigh* Thanks in advance for any replies.

The occasional transition from '~' to '=' when no sockets are active can be attributed to Verizon initiating an exit from dormancy. As long as you don't see 'C', 'R', or 'W', there is not much you can do about it, nor much to be worried about.
For example, I have seen this occur when I have sent UDP packets to a server and then exited my app. Verizon initiates dormancy after about 20 seconds, but then the server sends a delayed reply. The network has to come back up to get the packet to the phone, but then the UDP stack drops it since there are no sockets active.
Another (unlikely) explanation is a background app that is also using the network (e.g. DNS queries). In this case, you will also see something besides '=' (e.g. 'C', 'R', or 'W').

The occasional transition from '~' to '=' when no sockets are active can be attributed to Verizon initiating an exit from dormancy. As long as you don't see 'C', 'R', or 'W', there is not much you can do about it, nor much to be worried about.
For example, I have seen this occur when I have sent UDP packets to a server and then exited my app. Verizon initiates dormancy after about 20 seconds, but then the server sends a delayed reply. The network has to come back up to get the packet to the phone, but then the UDP stack drops it since there are no sockets active.
Another (unlikely) explanation is a background app that is also using the network (e.g. DNS queries). In this case, you will also see something besides '=' (e.g. 'C', 'R', or 'W').

You mention (kurquhar) there that once the app closes its socket (ISOCKET_Release()) this basically stops the app's ability to receive data (naturally since the socket is gone). But that your server still attempts to send a packet back to the app and will fail.
Does your server not get notified that the socket has been destroyed?
The reason i'm asking is because I think we're experiencing something similar with the LG6000 - we close the socket on the device, but our server does not detect this until the PPP connection is killed. so in effect we have a problem during the whole linger period....
is there a workaround for this?
this seems to me like a problem with the TCP stack implementation...no?

You mention (kurquhar) there that once the app closes its socket (ISOCKET_Release()) this basically stops the app's ability to receive data (naturally since the socket is gone). But that your server still attempts to send a packet back to the app and will fail.
Does your server not get notified that the socket has been destroyed?
The reason i'm asking is because I think we're experiencing something similar with the LG6000 - we close the socket on the device, but our server does not detect this until the PPP connection is killed. so in effect we have a problem during the whole linger period....
is there a workaround for this?
this seems to me like a problem with the TCP stack implementation...no?

My example was for UDP, so there is no connection for the server to get notified about.
As to your problem, is your device dormant at the time you release the socket, or is the traffic channel up?

My example was for UDP, so there is no connection for the server to get notified about.
As to your problem, is your device dormant at the time you release the socket, or is the traffic channel up?

we took the advice of Qualcomm and basically tear down our socket after 30 secs of inactivity (always) using a timer callback. The code below is what we use to do this:
void fIpTimeoutCB(void * pUser)
{
CBREWApp * pMe = (CBREWApp*)pUser;
// close socket
if (pMe->pISocket)
{
ISOCKET_Release(pMe->pISocket);
pMe->pISocket = NULL;
}
// need to cancel connect cb if there is any
ISHELL_CancelTimer(pMe->a.m_pIShell, (PFNNOTIFY)(fConnectTimeoutCB), (void*)pUser);
}
this code kills our socket immediately (on the app's side) and the PPP connection usually stays up for an extra N number of secs (linger time i guess - default 30).
what we see is that if we send a packet from the server some time after these 30 secs pass - say after 40 secs (device connection is in '~' state), then we usually loose it since the server actually thinks the socket is still open.
It appears as though the transition state is lossy.

we took the advice of Qualcomm and basically tear down our socket after 30 secs of inactivity (always) using a timer callback. The code below is what we use to do this:
void fIpTimeoutCB(void * pUser)
{
CBREWApp * pMe = (CBREWApp*)pUser;
// close socket
if (pMe->pISocket)
{
ISOCKET_Release(pMe->pISocket);
pMe->pISocket = NULL;
}
// need to cancel connect cb if there is any
ISHELL_CancelTimer(pMe->a.m_pIShell, (PFNNOTIFY)(fConnectTimeoutCB), (void*)pUser);
}
this code kills our socket immediately (on the app's side) and the PPP connection usually stays up for an extra N number of secs (linger time i guess - default 30).
what we see is that if we send a packet from the server some time after these 30 secs pass - say after 40 secs (device connection is in '~' state), then we usually loose it since the server actually thinks the socket is still open.
It appears as though the transition state is lossy.

In your scenario, the phone's TCP stack should definitely be sending a FIN packet to your server at socket release, at which point your server should close it's end of the connection.
The best way to verify this is to run Ethereal or tcpdump on your server host and look at the TCP flow.

In your scenario, the phone's TCP stack should definitely be sending a FIN packet to your server at socket release, at which point your server should close it's end of the connection.
The best way to verify this is to run Ethereal or tcpdump on your server host and look at the TCP flow.

unfortunately - that's what i was afraid of. Will followup with VZW.

unfortunately - that's what i was afraid of. Will followup with VZW.

Quote:Originally posted by kurquhar
In your scenario, the phone's TCP stack should definitely be sending a FIN packet to your server at socket release, at which point your server should close it's end of the connection.
The best way to verify this is to run Ethereal or tcpdump on your server host and look at the TCP flow.
What I found out is that on the T720, if you use the ringer to test suspend, that perhaps 1 out of 5 times (or more) the FIN is NOT sent to the server (common). Also, about 1 out of 20 or 30 times or so, the next connect will get stuck and never completely connect to the server (this is more rare).

Quote:Originally posted by kurquhar
In your scenario, the phone's TCP stack should definitely be sending a FIN packet to your server at socket release, at which point your server should close it's end of the connection.
The best way to verify this is to run Ethereal or tcpdump on your server host and look at the TCP flow.
What I found out is that on the T720, if you use the ringer to test suspend, that perhaps 1 out of 5 times (or more) the FIN is NOT sent to the server (common). Also, about 1 out of 20 or 30 times or so, the next connect will get stuck and never completely connect to the server (this is more rare).

VZW confirmed there is a bug with the LG6000 and the T730 on this particular issue (Socket closing has latency).
We found a temporary workaround: close the socket before the PPP connection goes dormant (20 secs for example).
once you do this TCP becomes reliable again ;).

VZW confirmed there is a bug with the LG6000 and the T730 on this particular issue (Socket closing has latency).
We found a temporary workaround: close the socket before the PPP connection goes dormant (20 secs for example).
once you do this TCP becomes reliable again ;).

Quote:Originally posted by avisito
VZW confirmed there is a bug with the LG6000 and the T730 on this particular issue (Socket closing has latency).
We found a temporary workaround: close the socket before the PPP connection goes dormant (20 secs for example).
once you do this TCP becomes reliable again ;).
I am not sure what you mean by this.
I close the socket when I get a suspending message.
Are you saying that upon resuming I should open, then close, then re-open again all within 20 seconds?

Quote:Originally posted by avisito
VZW confirmed there is a bug with the LG6000 and the T730 on this particular issue (Socket closing has latency).
We found a temporary workaround: close the socket before the PPP connection goes dormant (20 secs for example).
once you do this TCP becomes reliable again ;).
I am not sure what you mean by this.
I close the socket when I get a suspending message.
Are you saying that upon resuming I should open, then close, then re-open again all within 20 seconds?

I was actually following up on the issue i posted above - not the T720 case.
my comments have to do with 1Xrtt devices (T730 and LG6000)

I was actually following up on the issue i posted above - not the T720 case.
my comments have to do with 1Xrtt devices (T730 and LG6000)

Qualcomm has confirmed the 'No FIN' scenario will always happen on BREW 2.0 1xRTT devices if the app closes the socket during the dormancy period.
keep in mind that if this happens then the PPP connection will stay up for 5 minutes (or more) in VZW's case. Users with minute plans are charged by VZW based on the PPP connection time - so they might be billed a lot.

Qualcomm has confirmed the 'No FIN' scenario will always happen on BREW 2.0 1xRTT devices if the app closes the socket during the dormancy period.
keep in mind that if this happens then the PPP connection will stay up for 5 minutes (or more) in VZW's case. Users with minute plans are charged by VZW based on the PPP connection time - so they might be billed a lot.

Hi
I am facing same problem when using IWEB.
i get x then X when its X , my app doesnt get SUSPEND event.
That means PPP is active .
It remains active for some time and then transits to # meaning PPP closed.
How can i explicitely close PPP conn ?
Is there a way around.
Bcoz then the handset is not able to handle incoming calls till I have PPP conn closed
Reply
Shantanu deo

Hi
I am facing same problem when using IWEB.
i get x then X when its X , my app doesnt get SUSPEND event.
That means PPP is active .
It remains active for some time and then transits to # meaning PPP closed.
How can i explicitely close PPP conn ?
Is there a way around.
Bcoz then the handset is not able to handle incoming calls till I have PPP conn closed
Reply
Shantanu deo

set your linger time to 0 (zero) before closing the ppp. This should do the trick.
-Vasanth

set your linger time to 0 (zero) before closing the ppp. This should do the trick.
-Vasanth

In general, setting the linger time by an app is not needed and even discouraged, as it disables BREW's network resource conservation strategy.
However, in this specific case, it sounds like this device is broken.
I would still advise trying a small linger timer (e.g. 5 seconds) as a compromise between preserving network continuity and receiving phone calls.

In general, setting the linger time by an app is not needed and even discouraged, as it disables BREW's network resource conservation strategy.
However, in this specific case, it sounds like this device is broken.
I would still advise trying a small linger timer (e.g. 5 seconds) as a compromise between preserving network continuity and receiving phone calls.

assuming we're talking about 1xrtt brew2.0 devices:
Qualcomm reccomended not setting the linger time to 0. But rather to some value less than the estimated NI dormancy period (we used 5 since less than the current 20 secs on VZW).
If you send a zero length packet from the client right before closing the socket, then you can guarantee the CDMA channel comes up and then the PPP connection will be reliably closed once you close your socket. This also causes the FIN packet (in TCP) to get delivered to your server since the channel is up.
this was the only reliable solution we found to tearing down the PPP connection and reliably receiving the FIN packet on the server.

assuming we're talking about 1xrtt brew2.0 devices:
Qualcomm reccomended not setting the linger time to 0. But rather to some value less than the estimated NI dormancy period (we used 5 since less than the current 20 secs on VZW).
If you send a zero length packet from the client right before closing the socket, then you can guarantee the CDMA channel comes up and then the PPP connection will be reliably closed once you close your socket. This also causes the FIN packet (in TCP) to get delivered to your server since the channel is up.
this was the only reliable solution we found to tearing down the PPP connection and reliably receiving the FIN packet on the server.

And How can we send zero length packet for tearing the PPP connection in BREW ?
Need help regarding that ..
I got this in RFC 1331
LCP is used to close the link through an exchange of Terminate
packets. When the link is closing, PPP informs the network-layer
protocols so that they may take appropriate action.
After the exchange of Terminate packets, the implementation SHOULD
signal the physical-layer to disconnect in order to enforce the
termination of the link, particularly in the case of an
authentication failure. The sender of the Terminate-Request SHOULD
disconnect after receiving a Terminate-Ack, or after the Restart
counter expires. The receiver of a Terminate-Request SHOULD wait for
the peer to disconnect, and MUST NOT disconnect until at least one
Restart time has passed after sending a Terminate-Ack. PPP SHOULD
proceed to the Link Dead phase.
Reply
Shantanu deo

And How can we send zero length packet for tearing the PPP connection in BREW ?
Need help regarding that ..
I got this in RFC 1331
LCP is used to close the link through an exchange of Terminate
packets. When the link is closing, PPP informs the network-layer
protocols so that they may take appropriate action.
After the exchange of Terminate packets, the implementation SHOULD
signal the physical-layer to disconnect in order to enforce the
termination of the link, particularly in the case of an
authentication failure. The sender of the Terminate-Request SHOULD
disconnect after receiving a Terminate-Ack, or after the Restart
counter expires. The receiver of a Terminate-Request SHOULD wait for
the peer to disconnect, and MUST NOT disconnect until at least one
Restart time has passed after sending a Terminate-Ack. PPP SHOULD
proceed to the Link Dead phase.
Reply
Shantanu deo

Quote:Originally posted by avisito
Qualcomm has confirmed the 'No FIN' scenario will always happen on BREW 2.0 1xRTT devices if the app closes the socket during the dormancy period.
keep in mind that if this happens then the PPP connection will stay up for 5 minutes (or more) in VZW's case. Users with minute plans are charged by VZW based on the PPP connection time - so they might be billed a lot.
I just ended up coding pings to stave off dormancy.
I really hope there is a concerted effort to work out the communication problems with future handset firmware/hardware revisions. All of these work-arounds are just ridiculous!
:mad:

Quote:Originally posted by avisito
Qualcomm has confirmed the 'No FIN' scenario will always happen on BREW 2.0 1xRTT devices if the app closes the socket during the dormancy period.
keep in mind that if this happens then the PPP connection will stay up for 5 minutes (or more) in VZW's case. Users with minute plans are charged by VZW based on the PPP connection time - so they might be billed a lot.
I just ended up coding pings to stave off dormancy.
I really hope there is a concerted effort to work out the communication problems with future handset firmware/hardware revisions. All of these work-arounds are just ridiculous!
:mad:

in case of the BREW 2.0 LG devices attempting to send 'any' number of bytes brings up the data channel. The trick is to close the socket only once the data channel is up. Zero length packet works in this case (with the brew 2.0 devices), and since our server does not have to deal with these extra packets - we used it.
there's a lot of SHOULD\MUST\COULD in RFC's - but that's not always how the stacks are implemented unfortunately, and that's where you call Qualcomm for workarounds.

in case of the BREW 2.0 LG devices attempting to send 'any' number of bytes brings up the data channel. The trick is to close the socket only once the data channel is up. Zero length packet works in this case (with the brew 2.0 devices), and since our server does not have to deal with these extra packets - we used it.
there's a lot of SHOULD\MUST\COULD in RFC's - but that's not always how the stacks are implemented unfortunately, and that's where you call Qualcomm for workarounds.

Quote:in case of the BREW 2.0 LG devices attempting to send 'any' number of bytes brings up the data channel. The trick is to close the socket only once the data channel is up. Zero length packet works in this case (with the brew 2.0 devices), and since our server does not have to deal with these extra packets - we used it.
Hi avisito
this is all OK !
But can u throw some light on how exactly u were sending zero length packets?
A small code snippet will be useful.
Thanx
Shantanu Deo

Quote:in case of the BREW 2.0 LG devices attempting to send 'any' number of bytes brings up the data channel. The trick is to close the socket only once the data channel is up. Zero length packet works in this case (with the brew 2.0 devices), and since our server does not have to deal with these extra packets - we used it.
Hi avisito
this is all OK !
But can u throw some light on how exactly u were sending zero length packets?
A small code snippet will be useful.
Thanx
Shantanu Deo

hope this helps:
void fIpTimeoutCB(void * pUser)
{
tMyApp * pMe = (tMyApp*)pUser;
byte bDummy[8];
if (pMe->pISocket)
{
INETMGR_SetLinger(pMe->pINetMgr, 5);
// dummy packet to bring up traffic channel for socket FIN (close)
ISOCKET_Write(pMe->pISocket, (byte *) bDummy, 0);
if (INETMGR_NetStatus(pMe->pINetMgr,NULL) == NET_PPP_OPEN)
{
// close socket
ISOCKET_Cancel(pMe->pISocket,0,0);
ISOCKET_Release(pMe->pISocket);
pMe->pISocket = NULL;
}
else
{
ISOCKET_Writeable(pMe->pISocket, fIpTimeoutCB, (void *)pMe);
}
}
}
// PS: once socket is closed the linger time should be set back to its original value (using 0 causes unpredictable network problems)

hope this helps:
void fIpTimeoutCB(void * pUser)
{
tMyApp * pMe = (tMyApp*)pUser;
byte bDummy[8];
if (pMe->pISocket)
{
INETMGR_SetLinger(pMe->pINetMgr, 5);
// dummy packet to bring up traffic channel for socket FIN (close)
ISOCKET_Write(pMe->pISocket, (byte *) bDummy, 0);
if (INETMGR_NetStatus(pMe->pINetMgr,NULL) == NET_PPP_OPEN)
{
// close socket
ISOCKET_Cancel(pMe->pISocket,0,0);
ISOCKET_Release(pMe->pISocket);
pMe->pISocket = NULL;
}
else
{
ISOCKET_Writeable(pMe->pISocket, fIpTimeoutCB, (void *)pMe);
}
}
}
// PS: once socket is closed the linger time should be set back to its original value (using 0 causes unpredictable network problems)

Quote:Originally posted by avisito
// dummy packet to bring up traffic channel for socket FIN (close)
ISOCKET_Write(pMe->pISocket, (byte *) bDummy, 0);
This seems like a bug in the underlying device software - a TCP write of zero bytes will generate no TCP frames and thus should not bring up PPP. Relying on this behavior seems risky, IMO.
What is the return value from ISOCKET_Write()? And does this also work on the Simulator or only your particular device?

Quote:Originally posted by avisito
// dummy packet to bring up traffic channel for socket FIN (close)
ISOCKET_Write(pMe->pISocket, (byte *) bDummy, 0);
This seems like a bug in the underlying device software - a TCP write of zero bytes will generate no TCP frames and thus should not bring up PPP. Relying on this behavior seems risky, IMO.
What is the return value from ISOCKET_Write()? And does this also work on the Simulator or only your particular device?

It returns 0. this is expected.
I agree there's some inconsistency here... No packet is actually transmitted. But the channel comes out of dormancy nevertheless.

It returns 0. this is expected.
I agree there's some inconsistency here... No packet is actually transmitted. But the channel comes out of dormancy nevertheless.

But that essentially does mean that U have to change the Linger time.
And there is no alternative to immediately close a connection.
I mean sending 0 length packets is not an alternative to Changing linger time ..
Thanx Guys
Shantanu Deo

But that essentially does mean that U have to change the Linger time.
And there is no alternative to immediately close a connection.
I mean sending 0 length packets is not an alternative to Changing linger time ..
Thanx Guys
Shantanu Deo

correct.

correct.