Monday, December 17, 2012

Re: [android-developers] Mobile network idle sockets disconnected

Thanks again for the feedback Robert.

I'm sending a heartbeat package but an answer is given. Though, I'm only sending the heartbeat every 30 minutes. Well, currently I'm doing less than that, but only as a workaround for this problem. For the test in case, I'm not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but this time I'm not even making a connection. I'm just listening to the connectivity changes - I was suspecting someone else was causing this. Turns out that the same behavior occurs, so someone else is causing this?

12-17 11:50:27.951   374   374 D GSM     : [GsmDCT] cleanUpConnection: tearDown=true reason=pdpReset
12-17 11:50:27.951   374   374 D GSM     : [GsmDCT] cleanUpConnection: tearing down
12-17 11:50:27.951   374  1486 D GSM     : [GsmDC-1] DcActiveState msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951   374  1486 D GSM     : [GsmDC-1] tearDownData radio is on, call deactivateDataCall
12-17 11:50:27.951   374  1486 D RILJ    : [1903]> DEACTIVATE_DATA_CALL 1 2
12-17 11:50:27.959   374   374 D GSM     : [ApnContext] setState: DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959   374   374 D GSM     : [ApnContext] set reason as pdpReset, for type mms,current state IDLE
12-17 11:50:27.959   374   374 D GSM     : [GsmDCT] cleanUpConnection: tearDown=true reason=pdpReset
12-17 11:50:27.959   374   374 D GSM     : [ApnContext] setState: IDLE for type mms, previous state:IDLE
12-17 11:50:27.959   374   374 D GSM     : [GsmDCT] isDataPossible(mms): possible=true isDataAllowed=true apnTypePossible=true apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959   374   374 D GSM     : [GsmDCT] get active apn string for type:mms
12-17 11:50:27.959   374   374 D GSM     : [ApnContext] set reason as pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959   374   374 D GSM     : [GsmDCT] cleanUpConnection: tearDown=true reason=pdpReset
12-17 11:50:27.959   374   374 D GSM     : [ApnContext] setState: IDLE for type cbs, previous state:IDLE
12-17 11:50:27.959   374   374 D GSM     : [GsmDCT] isDataPossible(cbs): possible=true isDataAllowed=true apnTypePossible=true apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959   374   374 D GSM     : [GsmDCT] get active apn string for type:cbs
12-17 11:50:27.959   374   374 D GSM     : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006   374   374 D GSM     : [GsmDCT] handleMessage msg={ what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576   111   209 D RILClient: processUnsolicited(): resp_id (11010), len(59)
12-17 11:50:28.576   115   194 D RILClient: processUnsolicited(): resp_id (11010), len(59)
12-17 11:50:28.576   756   784 D RILS    : Executing Am broadcast -a android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576   374   496 D RILJ    : [1903]< DEACTIVATE_DATA_CALL 

Cheers

On 14 December 2012 19:58, Robert Greenwalt <rgreenwalt@google.com> wrote:
oops..  I truncated a sentence..

updateDataStallInfo logs show what's going on when a stall is detected.  In your log you can see that 21 packets have been sent since you last received a packet.


On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt <rgreenwalt@google.com> wrote:
The data stall detector is watching for outgoing packets with no corresponding return.  If it sees this for X (6 minute default) it tries a bunch of things and one of those steps is to tear down and rebuild the connection.  That's what you're seeing.  I believe UDP packets may get ignored, thus my tcp/udp question.  You can see some log lines in the radio log like "updateDataStallInfo: OUT send=..." that show what'

What are you doing in your keepalive pings?  Sending a char with no response, or echoing a response back?  That could cause the problem because there'd be outgoing traffic but no incoming traffic.  If there were NO outgoing the data stall detector shouldn't fire.  If you change your keep-alive to send both ways you should be fine.

This makes me wonder what your other test device is doing - the one that doesn't show this problem.  Are you using rooted devices?  They would allow you to use tcpdump and look at the network traffic..




On Fri, Dec 14, 2012 at 11:28 AM, Robert Greenwalt <rgreenwalt@google.com> wrote:
Interesting.

Maybe it is an android bug!

What kind of traffic are you sending?  tcp?  udp?


On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira <goncalo@minkan.net> wrote:
Got the radio logs...


This seems to be it
GSM     : [GsmDCT] onReceive: action=com.android.internal.telephony.gprs-data-stall


On 14 December 2012 18:25, Robert Greenwalt <rgreenwalt@google.com> wrote:
3319 is fine.  It's just the tethering code noting an interface is going away.

Can you get radio logs?  This is the system log - there are several log buffers.  A bugreport (adb bugreport > mybug.txt) would get them all.  Then you can match the connectivityservice dropout with what happened in the radio.

I don't think you should open a bug: this is not an android issue, but rather it's a samsung issue.

I have opened an internal issue to expand CTS to check for this - any device wanting to claim to be an android device would not be allowed to do such a thing in the future.


On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira <goncalo@minkan.net> wrote:
Robert,

Thanks again for the feedback. I traced the logs from samsung with a simple app to reproduce this behavior. Same thing, 6/7 minutes and it drops.
I posted the logs here: http://pastebin.com/FcPPbq3V
On line 3323 you can see ConnectivityService disconnecting. What I can't understand is what's causing it. Line 3319 is suspicious as I don't have tethering on, but other than that I can't really determine what causes this. Should I open a bug for this?

Cheers


On 14 December 2012 16:50, Robert Greenwalt <rgreenwalt@google.com> wrote:
Is it possible something else on the device is occasionally sending data and reseting your window?

I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on.

I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away.  Perhaps just before that there may be something explaining why.

You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier.


On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira <goncalo@minkan.net> wrote:
Hi Robert,

Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times.
I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for?

Cheers


On 14 December 2012 16:16, Robert Greenwalt <rgreenwalt@google.com> wrote:
Android is not supposed to do this, though there is no guarantee of connectivity.  It sounds like something samsung is doing, either accidentally or on purpose.

If you send a packet every 6 minutes does that keep the device from pulsing connectivity?

Can you take a bugreport - the radio log may have some indication of why it's happening.


On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira <goncalo@minkan.net> wrote:

Hi all,

Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card.

After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome.

After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections.

Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2.

Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes.


Cheers

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en



--
Gonçalo Oliveira

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en



--
Gonçalo Oliveira

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en



--
Gonçalo Oliveira

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en



--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en



--
Gonçalo Oliveira

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

No comments:

Post a Comment