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
--
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
