Robert, isn't there any way to override the data stall detector behavior? or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected] >> > 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 < >>> [email protected]> 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 >>>> <[email protected]>wrote: >>>> >>>>> Got the radio logs... >>>>> >>>>> http://pastebin.com/754wJ2jd >>>>> >>>>> This seems to be it >>>>> GSM : [GsmDCT] onReceive: >>>>> action=com.android.internal.telephony.gprs-data-stall >>>>> >>>>> >>>>> On 14 December 2012 18:25, Robert Greenwalt <[email protected]>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 < >>>>>> [email protected]> 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 >>>>>>> <[email protected]>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 < >>>>>>>> [email protected]> 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 <[email protected] >>>>>>>>> > 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 < >>>>>>>>>> [email protected]> 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 >>>>>>>>>>> [email protected] >>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>> [email protected] >>>>>>>>>>> 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 >>>>>>>>>> [email protected] >>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>> [email protected] >>>>>>>>>> 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 >>>>>>>>> [email protected] >>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>> [email protected] >>>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [email protected] >>>>>>>> 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 >>>>>>> [email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> To unsubscribe from this group, send email to >>>>>> [email protected] >>>>>> 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 >>>>> [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> 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 [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en >> > > > > -- > Gonçalo Oliveira > -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
